#ubuntu-devel 2005-02-07
<mdz> mako: sent
<mako> mdz: i'm going to finish up this kernel team thing for fabbione first
<mdz> mako: ok, I'd like a few more success reports anyway
<ogra> jdub: the wiki design contest ends on 31. jan ?
<lexhider> ogra: yes
<ogra> hm, k
<HrdwrBoB> is packages.u.o on a timeline of some sort or am I pipe dreaming
<T-Bone> Kamion: mail sent
<mdz> HrdwrBoB: it is on a timeline
<Kamion> T-Bone: thanks
<T-Bone> np
<mdz> anyone else tested the live daily yet?
<lamont> fire call
<jdub> mdz: ELITE
<mdz> jdub: works?
<jdub> very nicely
<jdub> with less interaction between keymap and desktop, it feels faster
<jdub> mdz: the packages don't seem to be utterly recent though - correct?
<mdz> jdub: they're about a day old, I think
<jdub> hmm
<jdub> i guess that makes sense
<mdz> jdub: /casper/filesystem.manifest has details
<mdz> this morning's live image build failed because desktop was uninstallable again
<jdub> gnome stuff is very recent
<jdub> oh?
<mdz> may have been a few days old, due to the same problem, in fact
<mdz> the gnomemeeting/libpw/libopenh323/whatnot thing
<mdz> just got fixed today
<jdub> oh
<jdub> yeah
<jdub> (gar gnomemeeting and pw/oh323)
<mako> mdz: ok, don't see your email...
<mdz> mako: Jan 26 15:03:22 localhost postfix/smtp[3020] : A1CAEB8704: to=<mako@canonical.com>, relay=mail.alcor.net[68.168.78.100] , delay=15, status=sent (250 Message received: 20050126230124.CKUM20444.mta13.adelphia.net@mizar.alcor.net)
* mako waits patiently
<mdz> mako: I'll just /msg
<mdz> it's short
<mako> mdz: thanks
<mako> mdz: do you think we should send this to announce?
<mdz> mako: absolutely
<mako> that's like 1 gazillion people
<mako> good
<mdz> if you think we need to wait until we have a .torrent, it will have to wait until tomorrow
<Kamion> mdz: so do you want it in /release/ now?
<opi> mako: reply-to announcement?
<mdz> I have no idea how many people will actually download it
<mdz> Kamion: so far it works for me and jdub
<mdz> Kamion: do you think you will have a chance to test it tonight?
<mako> mdz: lots.. this will goto lwn
<Kamion> mdz: very unlikely, sorry
<mdz> maybe we should wait overnight
<Kamion> the box on which I have the last iteration of the live CD is currently building kernels and generally confused
<mdz> in the morning, thom can make .torrents and you guys can send out the announcement before I get up
<mako> if i can get my frickin cd drive to work i can test it
<mdz> mako: oh, something else to include in that mail
<mdz> mako: LWN published this random email I sent to ubuntu-devel with a very very rough live CD link
<mdz> mako: so make sure we emphasize that this is a proper milestone release
<Kamion> FWIW published CD dailies and releases should now have an MD5SUMS.gpg detached signature created with the cdimage signing key
<mdz> goody
<mako> nice!
<Kamion> I meant to have that for array-3 but forgot to baz commit
<mdz> elmo: is the code for db.d.o available anywhere?
<elmo> mdz: err, I think joey randomly restored it on cvs, yah
<mdz> elmo: for some reason, I've never been able to change my 'l' attribute via the email gateway, though I can change other stuff
<elmo> 'l' ?
<mdz> the LDAP location attribute, 'l'
<ajmitch> elmo: how often do you do dam account creation for debian?
<Kamion> elmo: did you see my sync request for groff? do I need to mail that instead?
<mdz> or locality or whatever
<mdz> it's listed as one of the things supported by the mail gateway
<mdz> but it ignores me
<elmo> mdz: it's possible that got broken in the rush to use newsamosa for LDAP
<elmo> Kamion: I saw it, it's going to be my test package for the new sync stuff as I thoughnt you said it wasn't urgent
<Kamion> elmo: oh ok, no problem
<Kamion> indeed it's not urgent, just checking it didn't get lost
<elmo> ajmitch: there isn't a set timetable
<ajmitch> right
<ajmitch> just itching to get some package uploaded :)
<mdz> elmo: /debian-admin/userdir-ldap sound right?
<elmo> mdz: that looks like joey's latest crack yeah
<mdz> fuck cvs
<mdz> elmo: I can't get it via pserver, and I can't get it via ssh because CVS likes to write to things to check them out over ssh
<ogra> ajmitch: the ctypes diff.gz is still wrong in your archive, is this the diff for the source build you made ?
* T-Bone calls it a night, bye all
<ajmitch> ogra: hmm, what version?
<ajmitch> there will be other files in there
<ogra> ctypes_0.6.3-3ubuntu1.diff.gz    
* ajmitch looks
<ogra> its ot the one for ctypes_0.6.3-3ubuntu1_source.changes 
<ogra>  /ot/not/
<ajmitch> ok, I'll recopy it
<ajmitch> I'm working on 2 boxes, so some files might have got out of sync
<kent> btw, very few updates in the update-notifyer in Hoary seem to have changelogs to look at. Perhaps it takes to much time to write them for the developers? or is the notifyer just not getting them, since.. i guess changelogs are being written, it would be kind of bad if they were'nt, or?
<mako> mdz, et all: is there a download location for the cd?
<ogra> ajmitch: rather drop te binary packages in there and ony upload the source packages built with debuild -S or similar
<ajmitch> ogra: md5sum matches now 
<ajmitch> yeah, I was doing a quick job there, so I didn't really plan it :)
<mako> also, is there a location for the daily builds
<mdz> mako: not yet, I don't think
<mdz> mako: Kamion was asking whether to go ahead
<ogra> ajmitch: now the dsc is still wrong...
<mdz> if we're going to wait and send it tomorrow, we may as well wait to publish it
<ajmitch> ogra: check again
<mdz> mako, Kamion: let's wait
<mdz> tomorrow we'll have torrents, and hopefully more testing too
<mdz> I expect a lot of downloads
<ajmitch> ogra: it may be going a little slow, I'm rsyncing the daily live cd
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | Please test latest live CD: http://cdimage.ubuntu.com/daily-live/current/ (feedback to ubuntu-devel@lists.ubuntu.com)
* mode/#ubuntu-devel [+o mdz]  by ChanServ
<mako> mdz: that sounds reasonable
<mako> what should i do with this text?
<pitti> night everybody!
<mako> the announcement text?
<ogra> night pitti
<ajmitch> g'night pitti 
<mako> pitti: night
<mdz> jdub: can you add something to the topic on #ubuntu about testing the live CD?
<Kamion> mdz: is a CD image dated 2005-01-19 sanely rsyncable?
<lamont> Kamion: didn't happen until at least 1-20
<Kamion> kent: erm ... we definitely write changelogs for every new version of a package, it's a technical requirement
<Kamion> lamont: damn
<mako> mdz, Kamion: ignore the wiki text and just grab it out of the edit window
<jdub> mdz: let me know when there's a better url than http://cdimage.ubuntu.com/daily-live/current/
<mako> http://www.ubuntulinux.org/wiki/LiveCDAnnouncement
<jdub> rockin
<ajmitch> hegdehodge?
* mako is happy to send that out whenever.. but otherwise anyone can if you can find jdub/me to moderate it
<kent> Kamion, yes, i assumed that. But the update notifyer dont seem to show many of them. For example, just recently i upgraded some packages when the update notifyer showed me there was some new packages. None of them had a changelog to view. (there is an option to show changelog in the update-notif..)
<Kamion> jdub: sounds like mdz prefers me to wait until tomorrow to move to /releases/
<mako> ajmitch: fixed
<Kamion> kent: you'd want to ask mvo about that, or just file a bug
<nicedreams> what is the serial module called to mount serial drives?
<nicedreams> is it loaded by default?
<jdub> Kamion: then it'll have torrent love?
<Kamion> jdub: only once thom applies love, but yeah
<jdub> ok
<jdub> already getting questions
<ajmitch> other errors on the page..
<Kamion> if you want it now, I should move it to releases now; don't want to torrent dailies
<Kamion> mdz: ?
* ajmitch hunts for wiki password
<mdz> Kamion: 2005-01-19?
<jdub> oh man
<Kamion> mdz: that question is obsolete :-)
<lamont> mdz: he got his answer
<ajmitch> mako: 'will touch', or 'will not touch'?
<mdz> Kamion: what's the new question?
<Kamion> 00:23 < Kamion> if you want it now, I should move it to releases now; don't want to torrent dailies
* jdub did not realise that page was so crack before changing the topic url
<ajmitch> heh
<mdz> <mdz> mako, Kamion: let's wait
<mdz> <mdz> tomorrow we'll have torrents, and hopefully more testing too
<mdz> jdub: gah, I didn't mean to link to the announcement
<mdz> jdub: that announcement is unannounced
<mdz> jdub: I want pre-announcement testing
<Kamion> yes but you won't have torrents until I move it to releases and therefore people testing tonight can't bittorrent
<jdub> heh
<mdz> Kamion: that's fine
<mdz> I just want torrents before it goes to ubuntu-announce
<Kamion> although ... bleh, thom went to bed so it doesn't matter anyway
<jdub> switched back
<mdz> right
<mdz> jdub: thanks
<mako> mdz: the announcement is not only announced.. it's also unfinished
<mdz> jdub: can you add me to the chanserv access list for #ubuntu?
<mako> mdz: there are big holes where permentant urls should be  :)
<mdz> if I'm going to be an IRC weenie, I may as well be able to do stuff
<mako> ajmitch: will not touch
<mdz> Kamion: please disable the daily-live cron job for tomorrow
<Kamion> you're not linking people to /current/ are you?
<jdub> mdz: do have a sane/usual hostmask atm?
<mdz> Kamion: I am in the topic
<mdz> I suppose i could change it
<Kamion> that's crack, link to a date :)
<mdz> jdub: not really, but I have that nickserv authentication mojo
<ogra> ajmitch: you have the wrong distribution in your changelog file in ctypes....(there is no unstable in ubuntu)
<Kamion> mdz: disabled anyway
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | Please test latest live CD: http://cdimage.ubuntu.com/daily-live/20050126.2/ (feedback to ubuntu-devel@lists.ubuntu.com)
<jdub> ok, sorted
<Kamion> mako: I've filled in one of those URLs
<Kamion> mdz: (you know you don't need operator privileges to change the topic in #ubuntu-devel, right?)
<mdz> Kamion: yeah, that was me cut-and-pasting thom's example
<ajmitch> ogra: curses, that's my emacs habits coming to haunt me :)
<ajmitch> ogra: they'll all be like that then
<mdz> Kamion: you mentioned that it required some extra foo to get a copy of /casper/filesystem.manifest next to the iso
<mdz> that would be very useful to have
<ogra> ajmitch: please cokerrect it.....i'll have to go to bed soon, so take your time and dont worry, i made the same mistake ;)
<ogra> heh -ke
<mdz> otherwise I can't confirm what's in the images on little
<ajmitch> ogra: sure, I'll try & work on them today 
<lamont> mdz: is the rootfs manifest already there?
<mdz> lamont: yeah, Colin gets it from you already
<mdz> it just isn't published in the dir with the isos, but it's included inside the iso
<lamont> ok.
<mdz> but since I can't loop-mount it on little...
<lamont> would be nice if it was published too...
<lamont> or is that casper.manifest?
* lamont was thinking udeb list
<mdz> casper.manifest == cloop contents
<mdz> hoary-live-$ARCH.list == iso contents
<lamont> ok
<mdz> and initrd.list == udeb list
<mdz> casper.manifest and initrd.list are only inside the iso at present
<mdz> though for initrd.list, I think debian-cd records the version of d-i it used, so you can look it up indirectly
<Mithrandir> elmo: why is the elf_x86_64 search path for binutils /usr/lib and not /usr/lib64 (and friends) (on i386)?
<elmo> no idea?
<Mithrandir> don't you maintain it? :)
<elmo> yeah?  doesn't mean I use it on amd64
<Mithrandir> it's on i386.
<elmo> for amd64
<Mithrandir> true.
<Mithrandir> but you might know why it was that way.
<Mithrandir> I'll whack it and get it to change, then
<elmo> I doubt there's a good reason
<elmo> amd64 was enabled the same way all the other targets are
<elmo> all the other !host targets are for binutils-proper (non-multiarch)
<elmo> and by the previous maintainer or an NMUer
<Mithrandir> hm, ok.  I should probably look at what eg sparc64 is doing.
<jdub> fabbione: new inotify is in -mm
<lamont> hoary-live-powerpc.iso
<lamont>      2275303   0%    1.05kB/s  164:22:23
<lamont> hrm... :-(
<lamont> maybe I'll run into town tonight
<ajmitch> still dowloading at 12k/sec here
<elmo> for once, it's not the servers
<mdz>    622643200 100%    4.08MB/s    0:02:25  (3, 100.0% of 3)
<Mithrandir>   115500672  20%   13.51MB/s    0:00:32
<Mithrandir> ah
<Mithrandir> life is good
<Kamion> mdz: manifest> ok, I'll try to do that tomorrow
<Kamion> mdz: you can use isoinfo to extract individual files from an ISO image; you don't have to loop-mount it
<Kamion> mdz: try isoinfo -R -i foo.iso -x /casper/filesystem.manifest
<mdz> Kamion: oh, nice
<mdz> sent 15864860 bytes  received 505347 bytes  58153.49 bytes/sec
<mdz> seems like my uplink is the bottleneck there
<mdz> I wonder if -z helps at all
<Mithrandir> sent 166454 bytes  received 10360603 bytes  107969.82 bytes/sec
<mdz> I don't imagine checksums compress too well
<mdz> oh, wrong rsync, never mind ;-)
<mdz> sent 330970 bytes  received 14919096 bytes  44787.27 bytes/sec
<mdz> that makes more sense
<elmo> gar, why does debsign insist on they're being a .dsc?  horrible broken thing
<mdz> isn't that the whole point of debsign?
<mdz> I guess it does it in-place too
<elmo> yeah
<elmo> would having the origin of the sync in the From field be useful?
<elmo> i.e. I could make the maintainer be "Sync From Debian Unstable <sync@ubuntu.com>"
<elmo> or is that just tacky?
<elmo> I'm going to put an Origin-URL: and Origin-Suite: in the .changes too
<mdz> doesn't much matter
<dholbach> re
<jdub> what's an example of a package that generates a dummy .pem file during install?
<Mithrandir> dovecot-imapd, probably.
<Mithrandir> apache2 too
<Kamion> do we care if generating a kickstart file for Ubuntu requires a current Ubuntu system?
<Kamion> i.e. if the graphical application to do so needs bits of current Ubuntu, like, er, xserver-xorg
<Mithrandir> Kamion: it would be nice to avoid, certainly, but not a requirement, IMHO.
<Kamion> I guess depending on xserver-xorg is slightly crack, but it would be nice to be able to pull out its debconf templates
<Mithrandir> heh
<Mithrandir> grab it from somewhere and run apt-extracttemplates on the .deb?
<Kamion> ew
<jdub> Mithrandir: thanks, nice example in dovecot-common.postinst
* lamont heads to town to fetch images
<Kamion> hm, except that that won't work anyway since xserver-xorg substitutes in choices for xserver-xorg/config/inputdevice/mouse/protocol programmatically
<Mithrandir> jdub: you might want to look at ssl-cert, though
<dholbach> isnt there a evolution-data-server-1.2 process any more?
<jdub> Mithrandir: handy!
<Mithrandir> jdub: it needs a bit of love, but I hope we can make that happen
<jdub> $ apt-cache rdepends ssl-cert
<jdub> ssl-cert
<jdub> Reverse Depends:
<jdub>   schooltool
<jdub>   schoolbell
<jdub>   apache-ssl
<jdub>   apache2-common
<jdub> 
<jdub> :-) :-)
<Mithrandir> :)
<jdub> though it seems to be commented out in apache2-common's postinst
<Kamion> SteveA would have a heartattack at some of the python code in system-config-kickstart
<Kamion> it has TABS in it
<Kamion> RANDOMLY
<Kamion> and wildly inconsistent indentation and style otherwise
<daniels> tabs are love
<Kamion> hey, I use them happily in C code, but
<lamont_r> morning fabbione 
<elmo> ping reconnect
<lamont_r> figures
* lamont_r watches the ppc livecd arrive...  grumble. 23%
<toresbe> Kamion: tabs are best used to confuse whoever dare touch your code ;)
<lamont_r> tabs are your friend.  changing tabstop values is evil.
<lamont_r> of course, if you're evil enough to change tabstops, then that should be documented at the top of every file, and consistantly violated across the entire source tree...
<lamont_r> cdrom on my laptop is throwing errors and won't eject... bummer.
<Kamion> fabbione: the bug was introduced between 2.6.9-bk1 and 2.6.9-bk2. Given the weird way that grub's Unix shell works, I think I'm going to bet on http://linux.bkbits.net:8080/linux-2.6/gnupatch@41752e4eX1Y99rE-GhfPoRzKlwh85g as my favourite candidate.
<Kamion> i.e. non-exec stack broke grub's nested functions ...
<elmo> wouldn't the kernel be broken on modern p4's if that were the case?
<elmo> s/the kernel/grub/
<Kamion> you'd think so, but maybe something else is broken in the ia32 emulation code that means personality flags don't get emulated properly, or something like that
<elmo> does booting with noexec=off fix it??
<elmo> s/?$//
<Kamion> good question, I'll try that in the morning - well past bedtime now
<Kamion> if so that would be a fun workaround for our CDs
<Kamion> fun in the sense of "piss everyone off"
<lamont_r> Kamion: where's your sense of humor, eh?
<lamont_r> 50% sigh
<stuNNed> hi, thanks, will beagle be in hoary at all or is it just too new?
<jdub> stuNNed: it will probably turn up in universe
<jdub> daniels: ping
<stuNNed> jdub: thanks man, have a good one
<lamont_r> well, time to head home.
<daniels> jdub: represent
<tseng> daniels: h to the izz-eh
<jdub> daniels: libdbus-cil?
<daniels> jdub: building now
<daniels> jdub: it's a pain though
<jdub> elmo: ping
<tseng> daniels++
<mdz> gah
<mdz> jdub: LWN has some misinformation about the live CD that needs correcting
<mdz> don't have time to write them right now though
<tseng> hiya ogra 
<daniels> mono, how I hate thee
<tseng> daniels: hm dbus-cil builds for me from source, i have working bins
<tseng> daniels: whats broke?
<daniels> tseng: just dealing with the /usr/lib/mono clusterfuck
<tseng> oh, that craptastical
<sivang> mdz: what do we need to write them?
<sivang> Morning all!
<tseng> hey, sivang 
<sivang> hey tseng , what's cooking?
<tseng> nm duder, playing with muine cvs again
<lamont> mdz: just a tad bit wrong, isn't it...
<daniels> tseng: (also, doing the merge in to 0.23)
<tseng> daniels: when youre done, you can be my hero
<ajmitch> daniels: hmm, it used to be /usr/share/mono, interesting to see they changed it to /usr/lib
<tseng> ajmitch: http://wiki.debian.net/?MonoConventions < you used to be able to read this
<ajmitch> yes, I helped with some of that initially
<sivang> does anybody know if the screen resolution changer in gnome is part of g-s-t ?
<ajmitch> tseng: I package pnet, the other clr :)
<tseng> sivang: 
<tseng> brandon@lappy:~/work/muine $ dpkg-query -S `which gnome-display-properties`
<tseng> capplets: /usr/bin/gnome-display-properties
<sivang> tseng: k, tnx :)
<tseng> np
<daniels> tseng: yeah, I think I'm done now -- just building Beagle to test
* tseng needs to find/work on an evo-sharp package
* ajmitch needs to work on pnet's assembly loading so it finds all these packages in the right place
<ajmitch> apart from the fact that nearly all these -cil packages depend on mono-jit | mono-mint
<tseng> -nearly
<ajmitch> I was hoping there'd still be a few that depended on cli-virtual-machine
<ajmitch> not that it matters yet, since I've got to get pnet patched properly
* daniels feels the Beagle love, uploads dbus and dbus-mono.
<tseng> :D
<tseng> daniels: any feelings on libgtk-cil2?
<daniels> tseng: on the what now?
<tseng> gtk-sharp-1.9.x
<tseng> its parallel install dealy
<jdub> mdz: ok, will mail
<tseng> muine uses it so far, f-spot was using it and went back.. its gtk 2.4 bindings
<daniels> tseng: no idea, sorry
<tseng> ok.
<daniels> jdub: enjoy
<tseng> the muine maintainer has source up that works
<jdub> daniels: uploaded?
<tseng> ill poke at it later
<daniels> jdub: fo'sho
<jdub> rawk
<fabbione> morning
<daniels> ciao bella
<fabbione> ahah
* daniels frowns at dbus-mono.
<fabbione> daniels: may i assign you a FTBFS on cyrus-sasl?
<fabbione> daniels: cyrus B-D on libtool1.4, that isn't in main
<fabbione> point is that it might need some libcrap love to be fixed
<daniels> fabbione: sure
<fabbione> and i think germinate didn't catch it properly
<jdub> mdz: sent, cc'ed
<lamont> fabbione: you were looking for me many hours ago?
<fabbione> lamont: hmmmm not that i remember...
<lamont> ok
<fabbione> it must have been < wishlist
<fabbione> otherwise i would :-))
<lamont> heh
<lamont> fwiw, -11lamont1 built fine, with just that one change (and rename both 00-list files, of course)
<lamont> s/rename/copy/
<fabbione> lamont
<fabbione> i have it fixed in my local tree for -12 already
<lamont> fabbione: right.  was just confirming to you that there is no additional fix required
<fabbione> # arch   version  flavour       installedname        suffix build-depends
<fabbione> hppa     2.6.10-2    hppa32            2.6.10-2-hppa32           y 
<fabbione> hppa     2.6.10-2    hppa64            2.6.10-2-hppa64           y
<fabbione> lamont: cooll
<fabbione> daniels: 5924
<daniels> fabbione: thanks
<fabbione> jdub: i think the main reason why d-i failed is because of the udebs in the archive..
<daniels> Maintainer: Warty/i386 Build Daemon <buildd@rockhopper.buildd>
<daniels> lamont: surely that should be Ubuntu/i386?
<fabbione> jdub: but i will see to stop the buildd after the new d-i and do a test install
<lamont> daniels: sigh.  that'll change sometime soon
<lamont> daniels: changed locally, I'll push a new buildd-config sometime soon
<daniels> lamont: cheers
<lamont> daniels: it's only been that way since day one.
* lamont goes to bed.
<fabbione> ah lamont
<fabbione> i just remembered
<fabbione> oh well good night :-)
<jdub> fabbione: you rolling a new kernel soon?
<fabbione> jdub: no, i am still bug hunting
<jdub> ok
<fabbione> what do you need?
<jdub> would like inotify 0.18 -> file a bug?
<fabbione> or better.. do you have a fix for inotify?
<fabbione> ok. nah i will just do it
<fabbione> no need for a bug
<jdub> ok
<fabbione> will that possibly fix 5431?
<jdub> http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/0.18/
<jdub> should do
<jdub> let me know; i have a gamin to upload as soon as that's ready
<fabbione> -9.patch is ok?
<fabbione> or do you want me to grab 2.6.11 ?
<jdub> -9 please
<fabbione> ok
<lamont> fabbione: what?  still trying to get to bed, you see...
<jdub> fabbione: thanks :)
<fabbione> lamont: the PAS file you ship in the package is obsoleted..
<fabbione> lamont: elmo had to give me one from the DC
<fabbione> lamont: and you never told me if the gcc-opt patch i gave to you, make any sense
<fabbione> i didn't deploy it yet...
<lamont> new gcc-opt in the repository, implements something similar to your patch.. I streamlined it a bit
<lamont> which PaS file... /me looks around
<fabbione> lamont: elmo gave me one that is on people.u.c/~james
<lamont> fabbione: I don't see a PaS file in any of the packages there...
<fabbione> that is different from the one in the packages
<lamont> which package?
<fabbione> it should be shipped in quinn-diff?
* lamont did not intentionally include a PaS file
<lamont> ah, quinn-diff is stock debian, and yeah - that PaS file wouldn't have any relation to the real one - maintained in cvs
<fabbione> ahhh
<jdub> argh, why do people attempt to run random things as root when stuff doesn't work?
<lamont> jdub: because they _think_ they know what they're doing, of course
<lamont> anyway, sleep for real now
<jdub> night
<fabbione> night lamont
<fabbione> jdub: inotify updated.
<jdub> thanks! :)
<fabbione> *cough*beeeer*cough*
<daniels> fabbione: you'll get a coopers
<fabbione> daniels: until it's not that retarted aussie beer....
<daniels> dude, coopers is love
<daniels> unlike php4's build system
<daniels> which is COMPLETE ARSE
<daniels> *ahem*
<fabbione> ehhe
<sivang> whee, ubuntu shipps Gnoppix now
<sivang> ?
<jdub> gnoppix is based on ubuntu
<jdub> daniels: hey, just doing gmime now :)
<daniels> jdub: phat
<sivang> jdub: since when did they start to use it? I knew they were using debian (the project exists for a couple of years now ,no?)
<jdub> around the beginning of the hoary cycle
<jdub> amu is mr. gnoppix.
<jdub> amu is also mrs. kubuntu.
<sivang> heheh
<jdub> (haggai wears the pants.)
<sivang> amu: nice to know that :)
<sivang> hehe
<sivang> well, those children have good parent :)
<sivang> jdub: regarding -il list, would you prefer I bugged smurifx with that rather then you?
<sivang> ;-)
<jdub> nup
<jdub> doing list admin stuff atm
<jdub> also, it was delayed for loco team/leader confirmations
<sivang> jdub: ah ok, I have to run for a couple of hours (chors, errands) could you mail me the details?
<sivang> chores even
<jdub> yes
<sivang> jdub: I will be the list admin right?
* sivang is out for some icky stuff he needs to do, be back later.
<sivang> ah, am here for a couple'o minutes
<jdub> unfortunately, there's no hebrew translation of mailman
<jdub> but please make the description and summary hebrew if it accepts it :)
<bob2> is there a Plan for handling hardware that needs weirdshit software installed to make it useful? e.g you can't modify the screen brightness on vaio;s unless spicctrl is installed.
<jdub> not an all-embracing amazing plan, no
<jdub> but i imagine that PowerManager will start sucking up some of that
<jdub> pulling the code into a common location, etc.
<bob2> hm, I think I mean more getting the stuff installed
<sivang> jdub: I will for sure, thanks, although I am not sure hebrw is going to be used as the main lang on it ;-) Some of us also prefer to use english for technical terms and technical discussion :)
<jdub> english is for the weak
<jdub> bob2: seems cruddy to install all sorts of deeply specific crap
<aj> "I don't know why, but until now I'd gotten the impression that Ubuntu was a Mac-only distro."
<fabbione> lol
<fabbione> aj: where did you read that?
<zenrox> ya
<aj> local LUG list
<zenrox> lol
<zenrox> welp thay are wrong
<zenrox> x86 here
<jdub> aj: bizarre ;)
<fabbione> jdub: it must be another aussie fucks up.. like foster
<fabbione> :)
<daniels> fosters is made in the uk
<fabbione> what's the name of au fucked up beer than?
<aj> hey, it's the rest of the world that buys fosters not .au
<fabbione> aj: ahha i know :-)
<daniels> fabbione: the fucked up beer is fosters
<fabbione> it's like Peroni for Italy 
<daniels> fabbione: but the only people that buy it are the english, like thom
<daniels> so they brew it in the uk, for the english market
<fabbione> daniels: clearly
<jdub> "export quality" means quite a different thing in .au
<jdub> neighbours, home and away, fosters...
<jdub> (this actually came up on lugradio interview this morning)
<aj> what about kylie!?!
<infinity> aj : Foster's is the second or third most popular beer in .au, I'm sorry to report.
<infinity> Beaten by VB nearly everywhere, and FourX in QLD.
<infinity> No accounting for taste, I guess.
<infinity> Americans drink Bud and Coors, so it's not like they can talk.
* fabbione tests the new installer on sparc
<Clint> the British drink Bud and Coors, so it's not like they can talk.
<daniels> infinity: Er, I hardly ever see Fosters.
<aj> infinity: that's only meaningful if people drink the same beer though; having 90% of beer being 500 different brands means you only need 6% market share to be most popular, eg. no idea what the actual stats are
<daniels> jdub: they interviewed you?
<infinity> daniels : And you're luckier for it.  I'm merely quoting some shit statistic I found somewhre. ;)
<daniels> #@O$*I@#$#$OUPI@#$L:K@#$
<daniels> daniels@nanasawa:~/canonical/php4% dpkg-deb -c php4-imap_4.3.10-2ubuntu1_i386.deb | grep imap.so
<daniels> -rw-r--r-- root/root     88912 2005-01-27 17:58:03 ./usr/lib/php4/20020429/imap.so
<infinity> aj : Oh, well, yes.  Of course.
<daniels> SUCCESS
<daniels> HA HA HA PHP4
<infinity> aj : Same goes for Canadian beers, AFAICT.  Molson Canadian is by far, "#1" but that doesn't mean much.
* daniels does a victory lap.
<jdub> daniels: yeah, at 8am this morning
<daniels> jdub: nice
<infinity> daniels : ?
<jdub> daniels: almost
<infinity> daniels : Is poor php giving you issues?
<daniels> infinity: libc-client-dev is in universe (for very good reason), so I had to make php4-imap into a separate source package
<daniels> infinity: which meant conquering php's build system
<daniels> AGH
<infinity> daniels : cp -a ext/imap ../foo ; cd ../foo ; phpize
<infinity> daniels : Was it really any harder than that?
<daniels> infinity: hmph, didn't know about phpize
<daniels> and both the php docs and google were staggeringly unhelpful on this front
<infinity> daniels : Live and learn, I guess. :)
<daniels> ohw ell
<daniels> heh
<infinity> daniels : I need to get some sort of README.extension.packaging or something in php4-dev, I guess.
<fabbione> ram0: rw=0, want=16666, limit=16384
<fabbione> argh
<fabbione> does anybody remember if the OBP on sparc can pass args to the kernel booting via net?
<fabbione> yeah it works :-)
<fabbione> jdub: where did you say ubuntu6 was looping?
<jdub> initialising the fb
<jdub> and starting the menu system
<fabbione> ubuntu7 seems to work here
<fabbione> but again.. i am headless
<fabbione> so perhaps the fb fails more cleanly
<fabbione> anyway as soon as elmo is awake can bless d-i properly
<fabbione> boot net ramdisk_size=18000 DEBCONF_PRIORITY=low
<fabbione> i need to go and check the defaults for sparc d-i for ubuntu8
<fabbione> otherwise it is a royal pain to install
<fabbione> AH AHHHH
<fabbione> silo wasn't installed.. 
<jdub> daniels: gmime is up
<fabbione> Ubuntu Configuration                                                            
<fabbione>  .. Welcome to your new Ubuntu system!                                        .. 
* fabbione grins
<fabbione> jdub: i am running hoary on sparc
<fabbione> and i fixed the serial console problem :-)
<jdub> heh
<jdub> rad :)
<fabbione> yes.. there are still problems in d-i that needs fix
<pitti> Moin moin
<mvo_> moin pitti 
<Kamion> fabbione: nailed down the kernel problem quite a bit ... it was a change between 2.6.9-bk1 and 2.6.9-bk2 that enabled noexec stack by default
<Kamion> fabbione: /sbin/grub does have a PT_GNU_STACK section with the 'x' bit set, though, which should bypass the noexec stack; I think there's something wrong with noexec handling in the ia32 emulation code
<jdub> feh, gotta package a bunch of other stuff for optimal beagle action
<whiprush> jdub: do you mean beagle-friendly gmime?
<whiprush> bah. dreams. crushed.
<jdub> heh
<jdub> yeah ;)
<jdub> but dude
<jdub> there's no:
<jdub> evolution-sharp
<jdub> gsf-sharp
<jdub> gst-sharp
<jdub> and i have to talk to thom about beagle.xpi for firefox
<whiprush> yeah but those are optional. 
<whiprush> just a small taste would be pimp.
<whiprush> even without those it's still pretty damn good. I'm finding porn I thought I lost years ago.
<jdub> evo, gsf and firefox at least are optional but insane to not ship
<whiprush> right
<whiprush> I was thinking kneejerk short term.
<jdub> we're pretty much sorted for kneejerk short term now
<whiprush> the tbird option built for me also
<whiprush> although the --enable-network one blew up in my face.
<jdub> oh, that's not listed on the wiki (tbird)
<whiprush> I don't know if that's to index smb shares or whatever.
<whiprush> yeah it's in the .5 release notes.
<pitti> sivang: ping
<whiprush> although, I've had it indexing for a good 6 hours and it's still only doing the evo local folder stuff.
<whiprush> dunno what the deal is with that
<jdub> haha
<jdub> yeah, what is the network one?
<whiprush> no idea
<whiprush> it searches my smb mounts wether I specify it or not, same with the blogs.
<jdub> yeah, network beagled stuff
<pitti> Hi seb128!
<fabbione> hi guys
<seb128_> hey pitti & fabbione 
<seb128_> hate hate hate evolution
<pitti> seb128_: right, it doesn't support vim :-) (SCNR)
<seb128_> the damned new version doesn't allow to add new accounts, the "next" button in the wizard doesn't work
<seb128_> pitti: no every single version is fucked, that's the most GNOME software ever
<seb128_> most *bugged*
<Kamion> amd64 live CD works fine for me
<fabbione> hey Kamion 
<Kamion> hi
<fabbione> Kamion: did you succeed to find the kernel change that blocks amd64?
<fabbione> (btw i just managed another hoary installation on sparc... preparing a patch for d-i, but i will need some hint on a few details)
<Kamion> fabbione: scroll up
<fabbione> (only when you have time)
<fabbione> i did ping time out
<Kamion> oh
<fabbione> the server kicked me out
<Kamion> fabbione: nailed down the kernel problem quite a bit ... it was a change between 2.6.9-bk1 and 2.6.9-bk2 that enabled noexec stack by default
<fabbione> sorry
<fabbione> :(
<Kamion> fabbione: /sbin/grub does have a PT_GNU_STACK section with the 'x' bit set, though, which should bypass the noexec stack; I think there's something wrong with noexec handling in the ia32 emulation code
<fabbione> Kamion: ahhhh.... interesting
<Kamion> fabbione: the exact patch that introduced the problem is http://linux.bkbits.net:8080/linux-2.6/gnupatch@41752e4eX1Y99rE-GhfPoRzKlwh85g, but it shouldn't just be backed out or anything
<fabbione> did anybody send a mail to upstream?
<Kamion> fabbione: haven't yet but I will do
<Kamion> I'm going to see if I can come up with a patch first
<Kamion> jdub: shall I tag the live CD as a release now, do you think?
<jdub> looking good to me
<dholbach> hai
<fabbione> Kamion: ok. that sounds cool.
<Kamion> fabbione: I'm a *lot* further on than I was yesterday, at any rate
<fabbione> sounds even more cool :-)
<fabbione> but i think if you mail upstream they wil give you a patch pretty fast
<Kamion> I don't intend to hack at it too long without help
<Kamion> fabbione: who's the relevant upstream? just LKML?
<fabbione> yes that would be more than enough
<Kamion> oh, booting with noexec=off is a workaround (but crappy)
<fabbione> i agree.. it should be fixed upstream...
<jdub> pitti: around?
<pitti> jdub: yes
* fabbione runs another kernel build orgy
<jdub> pitti: have you looked at fuse much?
<pitti> jdub: enough to like it :-)
<jdub> heh
<pitti> jdub: however, I was told that there were some serious design issues with ti
<jdub> okay, perfect
<pitti> jdub: so it probably won't go upstream
<jdub> hmm; it has been added to -mm, so i had the impression those were sorted to an extent?
<pitti> jdub: but in general I think that level makes more sense than gnome-vfs /kioslave / etc
<pitti> jdub: really? cool!
<jdub> i'm trying not to hold a strong opinion either way ;-)
<jdub> so, my question;
<pitti> jdub: the advantage to gvfs is that you can use that stuff everywhere
<pitti> at the shell level
<jdub> yeah, i grok the differences ;)
<jdub> so have you thought about the interaction between pmount and fuse?
<pitti> jdub: what do you mean in particular?
<pitti> jdub: you can already mount fuse stuff as normal user
<jdub> eh?
<jdub> perhaps i have not looked at fuse recently enoguh...
<jdub> oh
<jdub> oh
<jdub> i'm confusing the way it works with a different crackful solution
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion and support on #ubuntu | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | Please test latest live CD: http://cdimage.ubuntu.com/releases/hoary/array-3.5-live/ (feedback to ubuntu-devel@lists.ubuntu.com)
<Kamion> jdub: URL in topic is the release
<jdub> heh
<jdub> 3.5 ;)
<jdub> heh:
<jdub> http://www.beaglewiki.org/index.php/Starting%20a%20D-BUS%20Session%20Bus
<jdub> summary: blahblahblhalhbhalhsalhalhbalabhba "ubuntu is set up with a session bus by default" bhlkalhalbalhablahblhablhablhablahblahba
<pitti> jdub: just read the kernel changelog. craaaack!
<pitti> jdub: a friend of mine told me that some guy wrote a kioslave plugin for fuse
<jdub> yeah
<pitti> jdub: imagine: gnome-vfs gets a fuse backend
<jdub> someone's already written one :)
<pitti> jdub: then you can do gvfs -> fuse -> kioslave -> shell
<jdub> heh
<pitti> sjoerd: ping
<fabbione> jdub: can you try to boot with people.u.c/~fabbione/mini.iso ?
<fabbione> jdub: it should fix the initrd problem
<fabbione> Kamion: can you kindly queue up http://people.ubuntulinux.org/~fabbione/d-i-silo.diff for next d-i release?
<Kamion> fabbione: sure; I'd prefer to handle it via ${RAMDISK_SIZE} though, I'll do that
<Kamion> fabbione: only matters for the mini.iso as far as I can tell? we'd need to check debian-cd as well
<fabbione> Kamion: yes. so do i, but it is not done upstream either
<fabbione> Kamion: yes.. that was one of the next questions..
<Kamion> I'd change it upstream except I can't test it
<fabbione> mdz asked (kinda kidding) for sparc images...
<fabbione> Kamion: i am not sure about all the logic behind it and looking at the other .cfg i got a bit scared..
<fabbione> but i know that right now we cannot provide images yet (due to pyopengl FTBFS)
<fabbione> Kamion: remember when i was talking about the "Continue without bootloader"?
<fabbione> i found why, but i need a hint for the fix...
<fabbione> basically silo doesn't get installed
<fabbione> what package do i need to look at?=
<Kamion> no, it's because silo-installer isn't installed
<Kamion> or not configured successfully or whatever
<Kamion> if you don't see any errors before "Continue without bootloader", it's simply that silo-installer isn't installed
<fabbione> after i install silo in /target the option "Install bootloader" is there
<Kamion> oh, THAT'S why I said silo-installer was brain-dead
<Kamion> it doesn't apt-install silo
<Kamion> I'll fix that, I know how
<fabbione> Kamion: ok that would rock!
<fabbione> thanks
<Kamion> but if I forget please try to remember the word "apt-install" :)
<fabbione> ahah ok.. i can just check myself if you are too busy.. don't worry
<Kamion> fabbione: could you try this in place of the line in config/sparc/miniiso.cfg that installs silo.conf into $(TEMP_CD_TREE)/boot?
<Kamion>         ./ramdisk-size-subst $(BASE_TMP)miniiso/initrd.gz < boot/sparc/silo.conf > $(TEMP_CD_TREE)/boot/silo.conf
<Kamion>         chmod 644 $(TEMP_CD_TREE)/boot/silo.conf
<Kamion> oh, and put ${RAMDISK_SIZE} in the right places in silo.conf
<fabbione> sure....
<fabbione> Kamion: would that be enough to apply the changes to tftpboot too i guess
<Kamion> tftpboot.sh doesn't look like it depends on the initrd size at all
<fabbione> eh it does...
<fabbione> somehow...
<fabbione> i did test the netboot with and without the silo changes
<fabbione> and i got the expected results
<Kamion> ok, it's not at all obvious how though
<Kamion> the string 'silo' isn't mentioned anywhere other than miniiso.cfg
<fabbione> yeah.. i am building now..
<fabbione> Kamion: next.. i have a design issue...
<fabbione> basically choose-mirror with DEBCONF_PRIORITY=high
<fabbione> doesn't ask for the mirror
<Kamion> we fucked that up
<fabbione> that means that it will loop with errors
<Kamion> we should just revert most of that to Debian IMHO
<fabbione> well that was sabdfl demand not to ask for the mirror
<Kamion> in other words it *should* ask for a mirror, so everyone doesn't have to come to archive.ubuntu.com
<Kamion> we have to persuade him otherwise; it's not sane as it is
<fabbione> Kamion: and be able to use unofficial repos
<Kamion> indeed
<fabbione> because i was thinking about 2 possible solutions to keep Mark happy
<Kamion> mind you, when sabdfl asked that IIRC archive.ubuntu.com wasn't in the list and you had to enter it manually
<fabbione> we can:
<daniels> mdz: ping
<fabbione> a) build the list of mirrors and have a check for official/unofficial arches
<fabbione> b) introduce somekind of boot option (DI_UNOFFICIAL)
<fabbione> the latter will force to ask for the mirror
<fabbione> since the arch might not be in the official repos
<Kamion> the mirror question is valuable - essential even! - for official architectures too
<Kamion> the way it is at the moment, I waste huge amounts of bandwidth every time I test netboot
<daniels> Kamion: you know the solution to that, right
<Kamion> daniels: I suppose I could move to Australia and have no bandwidth at all
<fabbione> Kamion: i agree.. do you want me to revert the choose-mirror changes?
<Kamion> fabbione: how about I talk to Mark?
<daniels> iptables -t nat -A PREROUTING -m mac --mac <whatever> -d archive.ubuntu.com -J DNAT --to-dest local.mirror
<Kamion> daniels: bit crap when I actually *want* to check what's on archive.ubuntu.com :P
<fabbione> Kamion: sure.
<Kamion> tho' cool hack
<daniels> Kamion: well, just enable it for that machine when you netboot
* jdub smacks Kamion 
<Kamion> so wrong, so wrong
<Kamion> the unofficial arch thing might be useful for defaults, but really there isn't a single sane default for the mirror on netboot installs
<Kamion> we can get away with not asking on CD installs because CD installs don't require installing anything from the network, and after the install has completed you can change the mirror in synaptic
<Kamion> but a 500MB download for every box you netboot is just totally so far beyond acceptable it isn't funny
<fabbione> Kamion: you can also use DNS zone views
<fabbione> where the same zone resolvs differently given who is asking
<fabbione> and point archive to the local mirror only from a certain ip
<fabbione> and to the real one if using another ip
<fabbione> that's more fun than using NAT ;)
<Mithrandir> can't it be set as a boot parameter?
<haggai> what do I do with a bug that is effectively an ITP that has been assigned to my package?
<haggai> uh, RFP
<Kamion> Mithrandir: yes, but that only makes sense for stuff only some people need to set; for netboot I think most people want to pick a local mirror
<Kamion> and therefore it should be asked
* thom yawns
<thom> are livecds ready to be torrented?
<Mithrandir> Kamion: a hack is to set a parameter which tells choose-mirror what priority the mirror question should be asked at, and having that set by the build scripts depending on netboot or not.
<Kamion> thom: oh, I need to create the metafiles, one sec
<Kamion> Mithrandir: choose-mirror isn't used in CD installs at all
<fabbione> Kamion: that change seems to work.. let me rediff :-)
<Kamion> so it doesn't matter ... every image containing choose-mirror wants to ask the question
<Mithrandir> Kamion: ok, so the priority of the question in choose-mirror should just be bumped, then?
<fabbione> that would be enough
<Kamion> right, but it was lowered because sabdfl told us to lower it
<fabbione> with default to a.u.c
<sjoerd> pitti: pong
<Mithrandir> Kamion: then we should whack sabdfl until he agrees it should be raised. :)
<Kamion> right
<pitti> sjoerd: I upgraded to hal 0.4.7 an hour ago. afterwards I started h-d-m and suddenly my system had a permanent cpu usage of 100%
<Kamion> thom: .torrents should be on mirrors or syncing to them now
<pitti> sjoerd: however, this remained even after killing hald, and after reboot everything was alright again
<pitti> sjoerd: did this ever happen to you?
<sjoerd> nope, never seen that behaviour
<pitti> sjoerd: hmm, I try that upgrade again, if it works, then the error was something else
<pitti> thanks
<daniels> thom: counsel?
<fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/d-i-silo.diff
<thom> daniels: eh?
<fabbione> Kamion: your change works fine and the other bit to change in silo.conf
<daniels> thom: as in, can I borrow your
<Kamion> fabbione: ok, got it
<fabbione> Kamion: cool thanks
<thom> daniels: certainly. sup?
<Kamion> fabbione: the chmod should be in there though, otherwise it's umask-dependent
<Kamion> anyway, in my tree
<daniels> thom: php4-imap is a separate source package in universe, and declares a dependency on php4-common (= ${Source-Version})
<daniels> thom: do I a) loosen it, or b) take the hit and ensure it's never out of sync, although that falls apart at the first security update to Hoary since php4-imap won't get updated when php4-common does?
<thom> daniels: do as python modules do, depend on the exact upstream version
<thom> that shouldn't be too onerous or break too hard
<jdub> thom: so i uploaded gmime built against mono
<daniels> coo
<daniels> cheers
<jdub> thom: which means we have everything we need for beagle
<jdub> thom: but there are optional things that i wouldn't really regard as optional...
<thom> jdub: mozilla extension?
<jdub> thom: gsf-sharp (ms docs), ephy plugin (need to support 1.6), firefox plugin (xpi, how?), evolution-sharp, etc.
<jdub> thom: i think whiprush and arslinux dudes are going to try out some of the other mono packages
<thom> jdub: right
<thom> i think we can just ship the firefox extension in firefox; don't think that's too onerous
<jdub> perhaps put a reference to beagle in the copyright or something
<thom> yeah
<jdub> all the source is there, so it's reasonable
<jdub> thom: hrm, actually, why don't we ship it in beagle as a system-installed xpi?
<jdub> thom: does it have to be registered or something?
<fabbione> Kamion: ok.. do you want me to check adding the chmod ?
<Kamion> no need
<fabbione> ok
<jdub> thom: (given that firefox is in main and beagle is in universe)
<fabbione> if ! apt-install silo ; then
<fabbione>         info "Calling 'apt-install silo' failed"
<fabbione> fi
<fabbione> Kamion: i guess that's what you mean by apt-install ;)
<thom> jdub: could do, actually
<thom> Kamion: so it's array-3.5-live, right?
<seb128> elmo: planner sync please
<dholbach> timidity is not installable at the moment (new version in debian fixes it (now uses libflac6))
<jdub> dholbach: cool, to request a sync:
<jdub> - build and test the sources from unstable
<jdub> - mail ubuntu-devel proposing to sync the version you tested
<jdub>   (saying that you tested it :)
<jdub> - mdz or myself will confirm and request that elmo do the sync
<dholbach> jdub: ok, i'm at it
<fabbione> food time
<ajmitch> morning
<Kamion> thom: right
<Kamion> fabbione: yeah, it's done upstream, just needs backporting
<thom> Kamion: they're up
<Kamion> thom: cool
* sivang is back
<Kamion> jdub: updated announcement with URLs
<jdub> Kamion: cool!
<fabbione> Kamion: i couldn't find the upstream repo for silo-installer...
<sivang> jdub: err, mailmain won't display the hebrew letters in the list's name correctly, could you tell me how you see the text?
<fabbione> Kamion: i think i am blind :-)
<jdub> sivang: yeah, totally broken; don't worry about it then :)
<sivang> jdub: ok, I am writing  an english decriptin, I know that in messages hebrew passes corretly, but I'll give it another couple of tests.
<daniels> thom: ping
<thom> daniels: ack
<Kamion> fabbione: /packages/arch/sparc/silo-installer/ in d-i; we should take the upstream fix because it includes full translations of error messages and stuff
<Kamion> and correct error handling, which the above isn't :)
<daniels> thom: i have no idea what I just pinged you about
<thom> you suck
<thom> as much as JD
<daniels> hm, maybe that was it
<fabbione> Kamion: cool..
<jdub> thom: oof, beagle with firefox extension is *sweet*
<thom> heh
* netjoined: irc.freenode.net -> kornbluth.freenode.net
* fabbione wonders if UVF applies to an unrelease package in an unreleased arch....
<jdub> thom, daniels: did you guys ever make a basic beagle package?
<jdub> thom, daniels: i'm tempted to just run with it and make one
<daniels> jdub: never tried, sorry
<daniels> i've only ever run it twice, for about 30sec each
<jdub> ok
<sivang> hey ogra 
<ogra> hey sivang...
<fabbione> new kernel on the way
<ogra> sivang: i still miss you there: http://www.ubuntulinux.org/wiki/CommunityCouncilAgenda
<ogra> :)
<Kamion> fabbione: mdz said I could do what I thought was sensible with the installer anyway
<fabbione> Kamion: eheh :-)
<fabbione> Kamion: i was thinking to uplaod the SVN version as 0.99
<fabbione> and give it a spin
<fabbione> joshk can't actually test it
<fabbione> we can only both benefit from it
<fabbione> food is ready.. bbl
<Kamion> fabbione: let me talk to joshk; I'd rather upload it as 1.00 to experimental, there's no real point being shy with version numbers
<Kamion> joshk can't test it?
<edd> fabbione: rock (re bluetooth)
<sivang> ogra: an already a member :)
<ogra> sivang: no MOTU yet ;)
<ogra> sivang: MOTU is a requirement for maintainer...you know this i thought...
<sivang> ogra: yeah, I am working on this :) 
<ogra> great, we need more people....urgently...
<ogra> ...so it would be nice to see you approved as a MOTU in the next meeting....
<fabbione> edd: welcome :-)
<fabbione> Kamion: actually .. i can just build it locally and stick it in the localudebs, can't i?
<fabbione> Kamion: my issue with upload was just to get it in the archive to be able to test ti
<fabbione> s/ti/it
<principerobo1> hi
<principerobo1> I have a problem with the battery status monitor
<principerobo1> Can someone help me?
<moyogo> which modern input method is ubuntu planning to use: XIM, IIIMF, SCIM, UIM?
<thom> principerobo1: #ubuntu for users questions, please
<principerobo1> Hi, there is a bug in my Ubuntu kernel. The ACPI don't detect my battery
<fabbione> principerobo1: did you check bugzilla already?
<fabbione> and please -> #ubuntu
<principerobo1> yes
<fabbione> bug number?
<fwiffo> #5861
<fwiffo> :o)
<fwiffo> i have the same issue
<principerobo1> :-)
<fabbione> ok please move to #ubuntu now
<fwiffo> rgr
<fabbione> principerobo1: i don't provide personal service. ask in #ubuntu and wait for somebody to answer.. not everybody is always awake at this time
<fabbione> bah they should REALLY stop asking me stuff in private
<fabbione> Kamion: there was a big netsplit (again)... 
<seb128> lamont: kick the gedit build please
<fabbione> if i put silo udeb in d-i/localudebs would that work?
<fabbione> (at least for testing it)
<Kamion> fabbione: silo-installer? yes, should do I think
<Kamion> fabbione: or just wget it at run-time and install it with 'udpkg -i'
<Kamion> (though any new debconf templates won't be properly installed that way - bug somewhere, probably cdebconf)
<fabbione> Kamion: ok.. can i install it at anytime or there is a particualr time slice i should do it?
<fabbione> do it/use
<Kamion> after other installer components have been retriever
<Kamion> retrieved
<fabbione> ok
* fabbione tests
<Kamion> you won't need the new templates unless apt-install silo fails so it should be ok
<Kamion> but if it does fail the postinst will probably fall over entertainingly
<fabbione> i just builded the entire package...
<fabbione> abelli: ping
<abelli> fabbione: dong
<fabbione> abelli: you are still the leader for the italian community right?
<abelli> yes
<abelli> or supposed to
<abelli> be
<fabbione> ok
<Kamion> has smurfix approved that?
<fabbione> smurfix: ?
<abelli> Kamion: im sorry yes
<Kamion> ok
<Kamion> just checking, smurfix is country team god
<smurfix> Just check the table in the wiki.  ;-)  If last-edit is by me, it's authoritative.
<seb128> elmo: could you do the gazpacho sync so ?
<ogra> smurfix: wow, we get a jamaican team ? col
<ogra> cool
<elmo> seb128: yeah, I'm doing my daily archive grudge work atm
<seb128> elmo: cool, thanks
<elmo> hmm, for entirely NEW packages, I guess we don't want the entire changelog do we
<seb128> we don't care I think :)
<seb128> elmo: libart-lgpl gnome-mime-data libgail-gnome syncs too please
<elmo> seb128: you'd care when we import something with a 1Mb changelog :-P
<seb128> :)
<daniels> elmo: php4-imap?
<fabbione> Kamion:      |                    SILO installation successful                    |     
<fabbione> looks good to me...
<fabbione> i will tell you soon how much it broke...
<elmo> daniels: dude, you need to get your "are we there yet" under control
<elmo> I'd processed it about 30 mins before you asked and it's pretty bloodly clearly non-urgent anyway
<infinity> Anything depending on c-client should probably have its own archive section anyway.
<infinity> dontusethisitscrap, or something.
<thom> youllburninthefiresofhellforthis
<Kamion> elmo: is "Auto-Sync" the right name?
<Kamion> seeing as it's, er, kinda manual at the moment
<elmo> I asked about this last night and got a big "\/\/hatever" type resonse
<Kamion> "disable building against internal mozilla"
<Kamion> the idea of having an internal mozilla is just too scary
<elmo> it's right in the sense that it's an unmodified automated sync from Debian; it's only choice of packages to sync that isn't
<Kamion> ah right
<elmo> I dunno, better name suggestions are welcome
<elmo> in any event groff was clearly a bad test package, as the .dsc is already signed by a ubunut.. meh.. now I don't know whether to replace the .dsc signature with the automatic one, or to keep it and modify jennifer to not check the .dsc signature for imported packages
<Kamion> seems better to have a valid .dsc I'd've thought, since it ends up in the archive
<elmo> how do you mean valid?
<Kamion> verifiable signature
<elmo> well it is.. just with the Debian keyring ;)
<Kamion> oh, I thought you were adding fields to the .dsc, like you do with the .changes
<elmo> that's option 3/c/iii/whatever of course, is modify jennifer to validate the signature against the union of debian and ubuntu keyrings
<Kamion> that's kind of semantically correct, given that our source is the union of what Debian and Ubuntu do
<elmo> Kamion: I generate the .changes - there's no where public to pull them from (or they don't exist for !Debian) - everything else is unmodified
<Kamion> of course I suppose you could argue that we sign everything that we pull from Debian to confirm that we meant to pull it
<fabbione> Kamion: i think we are almost there... :-) 2 things left to get a 100% success installation
<fabbione> Kamion: something is not handling inittab properly.. debian does.. and one package missing from main :P
<fabbione> but i will dig in them tomorrow.. i am getting too much headacke today
<fabbione> thanks for the help :)
<elmo> oh, meh, I'll have to sign it if it's one of the fun unsigned repo's we pull from
<Kamion> fabbione: prebaseconfig.d/90prepare-base-config is the place to start investigating the inittab problem, probably
<Kamion> don't see anything particularly Debian-specific in there though
<fabbione> Kamion: what happens i think is between base-config and login
<fabbione> there is a temporary inittab to run base-config
<fabbione> that gets replaced by a inittab.real
<fabbione> in debian the inittab.real is correct, the one on ubuntu no
<fabbione> this is a very specific case for the fact that i am headless and sparc wants a console on ttyS0
<Kamion> have you got a current base-config?
<fabbione> while from Ubuntu i get tty1 = console freeze
<fabbione> Kamion: the one that's in the archive...
<Kamion> < 2.61ubuntu5 would be broken
<Kamion> ok
<fabbione> i am synced with the buildd
<Kamion> I know about the temporary inittab
<fabbione> ./archive/pool/main/b/base-config/base-config_2.61ubuntu14_all.deb
<Kamion> that's what prebaseconfig.d/90prepare-base-config sets up
<Kamion> which is why I pointed you there as a first resort
<fabbione> i will look at it.
<fabbione> but not today
<fabbione> i need to stop soon..
<Kamion> sure ...
<fabbione> i couldn't sleep very good this night and my head is winning against me 1 - 0
<Kamion> $ LANG=de_DE.UTF-8 gettext -d console-data mac-usb-uk; echo
<Kamion> Englisch (Britisch)
<Kamion> mmm
<daniels> elmo: you need to get your rage under control :) i was asking if php4-imap was your huge-changelog-for-NEW case
<elmo> daniels: don't be disingenuous
<elmo> round-robining really doesn't distribute load evenly at all
<daniels> elmo: huh?
<lamont> seb128: kicked
<seb128> lamont: thanks
* lamont takes kids to school. back in a bit
* sivang back later, ESHOPPING
<zul> hey
<tritium> nice use of the d-i for the new live CD
<opi> is anyone working on Thunderbird patch for Reply-To-List?
<Treenaks> opi: list-reply.. probably..
<opi> yes, yes
<opi> but we're not sure?
<aj> that supports mail-followup-to:?
<aj> god, please let it be so
<opi> a new guy subscribed to ubuntu-pl, and asked for programmers tasks
<opi> I've pointed him to our CC meeting and point, that we need to fix Thunderbird
<opi> we'll see if he'll be intrested
<Treenaks> https://bugzilla.mozilla.org/show_bug.cgi?id=45715
<opi> oh, ok
<opi> thanks Treenaks 
<opi> so we need to wait for a patch, since it's assigned
<Treenaks> opi: https://bugzilla.mozilla.org/show_bug.cgi?id=233417 ?
<opi> Treenaks, Duplicate of Bug 45715?
<opi> Treenaks, same thing :P
<Treenaks> opi: not quite
<opi> ah, List-Post:
<opi> yeah, I noticed now
<Treenaks> https://bugzilla.mozilla.org/show_bug.cgi?id=204339
<pitti> sjoerd: ping
<sjoerd> pitti: pong
<pitti> sjoerd: it's reproducable
<sjoerd> cool
<pitti> sjoerd: every time I upgrade from hal 0.4.4 to 0.4.7 my computer is DoSed
<sjoerd> only on upgrade ?
<pitti> sjoerd: i. e. CPU goes to 100%, it becomes totally unresponsive and I have to hard-reboot
<pitti> sjoerd: yes
<pitti> sjoerd: now I booted again and it works perfectly
<pitti> sjoerd: I can stop, start, restart and everything
<pitti> odd...
<sjoerd> what is dossing your system ?
<pitti> sjoerd: that's the problem
<pitti> sjoerd: when I check with top, all proceses are quiet
<pitti> sjoerd: so it's not the hald process taking the cpu
<pitti> or, at least, it's not displayed
<pitti> however, cpu in general is 100%
<pitti> but no single process wants to be the reason :-(
<pitti> sjoerd: kernel bug?
<pitti> sjoerd: indeed, let's blame it to fabbione :-)
<sjoerd> could be
<pitti> sjoerd: I try with some other hal versions
<sjoerd> please
<abelli> pitti: hailie's chpax kills mono..
<pitti> sjoerd: btw, DOWNgrading back to 0.4.4 works like a charm
<pitti> abelli: yes, sounds like a good candidate to put into linux-hardened-support
<tseng> mono starts to run its own interpreted code at some point during the bootstrap process
<abelli> uee''''
<pitti> abelli: which binary must be disabled in particular?
<tseng> pax will certainly kill the build.
<pitti> tseng: the _build_?
<abelli> usr bin mono
<tseng> pitti: yes, i think i have a bug
<tseng> pitti: however, gentoo builds mono in a different manner
<tseng> pitti: http://bugs.gentoo.org/show_bug.cgi?id=74754
<pitti> abelli: so sudo chpax -s /usr/bin/mono; sudo chpax -p /usr/bin/mono makes it work?
<abelli> i need to sudo.. is it all right?
<abelli> yes it works
<pitti> WTH is that?
<pitti> Unpacking replacement hal ...
<pitti> dpkg-deb (subprocess): short read in buffer_copy (failed to write to pipe in copy)
<pitti> dpkg-deb: subprocess paste returned error exit status 2
<pitti> dpkg: error processing hal_0.4.6-1_i386.deb (--install):
<pitti>  short read in buffer_copy (backend dpkg-deb during `./usr/share/doc/hal/NEWS.gz')
<pitti> Keeeeeeeyyyyybuuuuuukk
<pitti> abelli: right, with sudo
<abelli> so those are the keys for heavens?
<pitti> abelli: okay, then I add it to l-h-support
<abelli> -s then -p...
<pitti> abelli: even easier
<pitti> abelli: just add it to /etc/page_exec.conf
<pitti> abelli: and then rerun sudo update-linux-hardened-support
<abelli> what if i dont have a page_exec.conf?
<pitti> abelli: it comes with linux-hardened-support
<pitti> abelli: oops
<pitti> abelli: /etc/linux-hardened-support/page_exec.conf
<pitti> sorry
<abelli> i should have understood.. sorry
* pitti commits the change
<carlos> pitti: ping
<pitti> Hi carlos!
<carlos> hi
<pitti> carlos: good to meet you, got a question
<carlos> pitti: me too
<carlos> :-D
<pitti> carlos: you first :-)
<carlos> pitti: I just remembered why I was interested on use automake/autoconf with pmount
<carlos> pitti: you are not naming the .pot file as it's named the .mo files
<pitti> carlos: hm?
<carlos> pitti: that will make the automatic import/export into Rosetta difficult
<carlos> pitti: the .pot file is called template.pot
<pitti> ah, that
<pitti> carlos: it should be pmount.pot
<carlos> but when installed the .mo, it's called pmount.mo
<carlos> pitti: yes, please
<pitti> carlos: incidentially my question was related, or nearly the same
<carlos> but it's an extra problem I should handle because I cannot fix all packages (I'm sure some of them have that problem) :-(
<carlos> pitti: really?
<pitti> carlos: I just wrote a script which converts a stripped tarball to the import format (<LOCALE>/LC_MESSAGES/<DOMAIN>.po)
<pitti> carlos: however, I had the same problem like you, finding out the DOMAIN
<pitti> carlos: so I assumed that the pot file was always called DOMAIN.pot
<carlos> pitti: autoconf/automake handle it correctly :-P
<pitti> carlos: but if it's not, I'm screwed
<pitti> carlos: how could it?
<carlos> pitti: because it has some special rules (at least with GNOME) that use the same name for the .pot and the .mo files
<pitti> ah, I see
<thom> firefox build of destiny on the way
<carlos> pitti: is there any way you give me that information when creating the translations.tar.gz file?
<pitti> carlos: that's the same question I wanted to ask you
<pitti> carlos: I could probably apply some heuristics
<pitti> carlos: i. e. like "find $pkgdir -name *.mo, then "basename $file .mo", then sort -u
<pitti> carlos: and write the result to /domains.txt
<carlos> pitti: what happens with multiple .pot files?
<pitti> phone
<carlos> ok
<pitti> brb
<pitti> back
<Kamion> pitti: how often are language packs getting updated at the moment? at all?
<pitti> I don't know , I wanted to ask you that
<pitti> Kamion: I want to do a complete rebuild soon
<pitti> Kamion: to fix the glibc dependency and to add the locale generation
<elmo> pitti: where did the mozilla-locale-fr dep go?
<pitti> elmo: I removed it, because it is for version 1.7.3, and we have mozilla 1.7.5
<pitti> elmo: so it is uninstallable
<elmo> pitti: so we fix mozilla-locale-fr
<elmo> there are about 8 like that
<elmo> I filed bugs on them all
<pitti> elmo: sure, that just was a hotfix
<Kamion> pitti: just wondering if I uploaded console-data with some extra locale bits shipped when they'd make it into a language pack
<pitti> Kamion: with the new set of base debs and my scripts working, I will probably do manual builds every week or so
<elmo> pitti: please don't do that, it messes with the sync-age stuff's head
<pitti> elmo: don't do what?
<pitti> elmo: remove support dependencies? build new base packages?
<pitti> elmo: or manual updates weekly?
<elmo> remove support dependencies because the dependencies are broken
<pitti> carlos: I've got no idea about multiple pots. The po files are just called <lang>.po, so you can't tell which domain it belongs to
<elmo> and I'm not terribly convinced by once a week either tho, now that you mention it
<elmo> can we not rebuild when -update packages get as big as base?
<pitti> elmo: no, I'm talking about weekly new _update_ packages
<pitti> elmo: the bases should remain as they are until short before the release
<carlos> pitti: but you have the .mo files from a package, right?
<elmo> oh, that's fine, I'd be surprised if people were happy with only weekly tho
<pitti> elmo: I just need this one set of new bases, because the current ones are broken
<pitti> elmo: weekly just for a start
<pitti> elmo: if I'm reasonably convinced that most of the stuff works, I can automate it further and do more often
<carlos> hmm, thinking it again, I think we will need a way to map it
<pitti> but right now I have to write a hell of a lot of new scripts to emulate Rosetta exports
<elmo> hum, why emulate?
<carlos> pitti: let me talk with daf about it
<pitti> elmo: right now I'm working at downloading and converting http://people.ubuntu.com/~lamont/translations,
<elmo> Kamion: do you haave germinate for woody handy anywhere? (any arch)
<pitti> comparing them to our current pos, and building a new archive out of the new ones
<pitti> because Rosetta does not yet do this
<elmo> pitti: I thought the plan was buildd -> rosetta -> you ?
<pitti> elmo: that's the future, yes :-)
<pitti> elmo: bitch carlos about speeding up :-)
<daf> pitti: there is no way to automatically know the gettext domain an application will use
<daf> pitti: it is not necessarily related to the template name
<daf> pitti: it might only be declared in the code
<pitti> daf: no, but the template name is the best guess I have currently
<daf> (though it is often available from looking at configure.in etc.)
<pitti> daf: actually what do you think about
<pitti> daf:  "find $pkgdir -name *.mo, then "basename $file .mo", then sort -u
<pitti> daf: ^ in pkgstriptranslations
<pitti> daf: this will at least tell us all translation domains
<daf> yeah, that makes sense
<carlos> pitti, daf: What about this:
<carlos> add a file with that output to the tarball
<pitti> daf: this should catch 95% of the packages with just one domain
<carlos> if there is only one domain
<carlos> we use it
<pitti> yes, that's the idea
<elmo> seb128: do you know if something recently dropped a depends on vorbis-tools?
<pitti> if there are several, it goes to manual processing
<carlos> if there is more than one domain, I will ask for a manual check
<carlos> right
<pitti> carlos: what do we do about the already present translation tarballs?
<carlos> pitti: don't worry
<pitti> actually I wanted to use them to build current langpacks
<carlos> hmm
<pitti> carlos: I do, if I can't map the domains, these translations are lost
<carlos> pitti: not really
<pitti> carlos: well, I check them manually
<seb128> elmo: rhythmbox, why ?
<carlos> pitti: the problem is to export the translations
<pitti> carlos: I finish my script, download all of it and correct manually
<carlos> so I will try to add a way to fix them before exporting 
<pitti> carlos: so first I update pkgstriptranslations to generate the domains.txt file?
<elmo> seb128: 'cos vorbis-tool wants to go to universe now.. I've asked for it to go to supported tho.. I just  wanted to make sure it was an intentional change
<carlos> pitti: yes, please, that way we get less .tar.gz files without it
* pitti drops everything else to do that
<carlos> pitti: what happens with Debian's po files?
<pitti> carlos: ?
<Kamion> elmo: output? no
<pitti> carlos: you mean the ones before the stripping age?
<pitti> carlos: I have them
<seb128> elmo: ok
<carlos> pitti: no, de debconf ones
<pitti> carlos: I just merge them
<elmo> Kamion: don't worry, seb explained why it disappeared anyway
<Kamion> elmo: hang on, *woody*? why?
<pitti> carlos: ah
<pitti> carlos: I don't touch them for now
<carlos> pitti: are they .mo files also?
<elmo> Kamion: meh, meant warty
<pitti> carlos: no
<pitti> carlos: they get merged to the templates file during package build
<elmo> both begin with a 'w' :p
<carlos> ooh, cool
<Kamion> elmo: http://people.ubuntu.com/~cjwatson/germinate-warty-output/
<pitti> carlos: well, not _so_ cool
<daf> don't we need a way to map paths in tarballs to translation domains?
<pitti> carlos: it doesn't use gettext in the running system
<carlos> pitti: then, please, export them also so they are imported into rosetta (but not exported when you ask the language pack)
<Kamion> elmo: it's only running against warty though, not warty+warty-security or anything
<elmo> oh, right, forgot about that page
<pitti> carlos: they are exported in the translation tarballs
<pitti> carlos: i just take each and every po file I can get
<pitti> carlos: usually they should be in debian/po/
<carlos> daf: yes, with that domains.txt file and some manual work it should be enough
<carlos> pitti: perfect, I will handle them as an special case
<pitti> carlos: you need a map for every package with > 1 domains which maps path -> domain
<pitti> carlos: should be possible
<carlos> so packages with them are not seen as multiple pot tarballs
<pitti> carlos: and maintain the map manually
<carlos> pitti: I know, we have already the needed fields in the database for it
<daf> carlos: sorry, I'm having a hard time following -- where will this file be stored?
<lamont> pitti/carlos: mind if I regenerate the entire tree under ~lamont/translations?  (will move a few files around, etc...)?
<carlos> lamont: no problem
<pitti> not for me
<pitti> lamont: wait
<lamont> ok.  that'll get rid of the dups
* lamont waits
<pitti> lamont: what do you mean with "regenerate"?
<carlos> daf: inside the *translations.tar.gz files
<pitti> lamont: if it means "rebuilding the source packages", then I need you to wait a bit
<carlos> daf: so we will have .pot, .po and domains.txt files
<lamont> pitti: "randomly" reorganize the contents of all the 2005* directories
<pitti> lamont: ah, ok. I don't mind that
<daf> carlos: hmm, ok
<lamont> not rebuilding, merely re-fetching from the buildd's.
<pitti> lamont: I will upload a new pkgstriptranslations shortly, we need that
<daf> carlos: this won't help us with importing multi-pot tarballs into Rosetta, though, right?
<carlos> daf: from the web interface?
<carlos> no
<carlos> daf: but I think it's safe to forget that use case in the near future
<elmo> infinity: ?
<thom> elmo: he went to bed an hour or so ago
<lamont> pitti/carlos: turns out that "regenerate" simply means "remove the duplicate files found in 20050127"
<lamont> ]   CC [M]   drivers/net/wireless/acx/acx100_helper.o
<lamont> drivers/net/wireless/acx/acx100_helper.c:2872:2: warning: #warning Is this used anymore?
* lamont giggles
* sivang is back
<dholbach> bbl *wave*
<carlos> lamont: you can do whatever you need with it atm,  I'm not doing anything that depends on its contents, just ask pitti if you need to do any change
<pitti> carlos: when do you think will exporting work?
<lamont> carlos: ok
* lamont is done mucking about - want a current copy of the script?
<carlos> pitti: I think daf told me he did the export, but until we finish the import (this week + extra checks) don't think it's going to be useful for you...
<pitti> carlos: right, just curious :-)
<carlos> lamont: do you have it in arch?, I think that should be enough
<pitti> lamont: would it be a problem if I put some (temporary) text files into <src package directory>/.. on the buildds?
<pitti> lamont: i. e. the dir where the translation tarball is?
<pitti> lamont: oh, I can't do that at user's machines
<pitti> lamont: darn, I need mktemp
<pitti> but that isn't essential
<pitti> carlos: putting in this domains.txt file is more difficult than I thought...
<carlos> pitti: how do you create the tarball?
<pitti> carlos: I thought about using "tar -A" to add this file to the tarball, but that option doesn't work :-(
<pitti> carlos: find -name "*.po" -o -name "*.pot" | tar cT - | gzip -9 > ../$tarball
<pitti> carlos: the problem is, I cannot just put a file "domains.txt" into the source package
<pitti> carlos: it might already exist
<pitti> carlos: and although the source is already built by that time, it is not good to destroy the source
<pitti> why, oh why, isn't debianutils essential?
<elmo> err, it is?
<pitti> oops, 
<pitti> oh
<pitti> cool!
<lamont> carlos: need to do that... :-)
<pitti> okay, so I can rely on mktemp, and my problem is gone
<carlos> pitti: is that correct? (I was looking for alternatives, just to know I could stop)
<pitti> carlos: correct what?
<carlos> pitti: that you are able to use mktemp :-)
<pitti> carlos: yes
<pitti> carlos: my fault
<carlos> perfect
<pitti> carlos: well, almost
<pitti> carlos: the file is called domains.txt.94584
<pitti> carlos: (or so, temporary)
<pitti> carlos: would that hurt you?
<carlos> pitti: if you cannot rename it, no as soon as It's always domains.txt.NUMBER
<pitti> carlos: okay, then I'll do that
<pitti> carlos: no, forget that
<pitti> carlos: mktemp -t :-)
<pitti> mktemp -d, I meant
* rcaskey_ has had fun experimenting making some of them new-fangled screen demos
<rcaskey_> vnc2swf is pretty neat
<rcaskey_> it seems to choke on things that get sudo'd though
<Kamion>             if self.emulate_3_buttons.get_active() and self.mouseDict[args]  != 'none':
<Kamion>                 buf = buf + "--emulthree "
<Kamion>             (a, b, c, d, e, protocol) = self.mouseDict[args] 
<Kamion> is there something magic about tuple/string comparison that makes the test at the end of the first line make any sense at all?
<sivang> Kamion: what's that supposed to do? dict by a click on a word? ;-)
<Kamion> it's part of the graphical kickstart frontend's mouse handling
<dholbach> re
<sivang> Kamion: ah ok, kickstat is also in python?
<Kamion> sort of
<Kamion> bits of Red Hat's implementation is in C; bits of our implementation will likely be in shell
<Kamion> there'll be a sizable python component though
<sivang> Kamion: and it uses the gtk db lib?
<sivang> s/db/fb
<Kamion> no
<Kamion> the graphical bit is something that you run on an ordinary system to generate a kickstart file
<Kamion> the kickstart file is then parsed noninteractively by the installer
<sivang> ah right ! oops
<sivang> yes, for mass intalls
<Kamion> indeed; although it's nothing that you can't do with preseeding either
<Kamion> it's purely a compatibility thing
<sivang> Kamion: right, preseeding allows you to create boiletplate system snpashot and apply them non interactively almos the same way?
<Kamion> yeah
<sivang> Kamion: so this step it a mere "let's make it easy for admin that already used Kickstart on their redhat/fedora system" ?
<Kamion> right, or admins who already have heterogeneous RH/Fedora/SuSE/blah setups
<Kamion> and preseeding doesn't have any pointy-clicky frontend at the moment, so this will provide that
<Kamion> assuming I can get it done before feature freeze, at least
<sivang> Kamion: I'd appriciate when you have time to toss me the link to read about preseeding the installer, I'd like that for the livecd and the loco version.
<sivang> or give a couple of instructions here
<sivang> (for preseeding the language/location question)
<Kamion> sivang: link to http://d-i.alioth.debian.org/manual/en.i386/ch04s07.html
<sivang> ok :)
<Kamion> unless you feel up to modifying the initrd, the language/location question can only be preseeded on the kernel command line (or by bootloader configuration)
<Kamion> in hoary, adding 'preseed/locale=he_IL' or similar to the append lines in bootloader configuration should be sufficient
<Kamion> possibly it's preseed/locale=he_IL.UTF-8, localechooser is complicated, try both
* sivang tomboys
<Kamion> should work for both the installer and the live CD
<pitti> lamont: pkgstriptranslations_6 uploaded
<pitti> lamont: it'd be nice if you could install it asap
<sivang> Kamion: yes, now that casper is actually d-i setting up the environment
<Kamion> indeed
<sivang> (or not, but sounds like it does ;-)
<lamont> pitti: if you just uploaded it now, then I can install it in about 50 monutes
<lamont> minutes, even
<pitti> lamont: that's fine
<thom> Uploading via ftp mozilla-firefox_1.0+dfsg.1-2ubuntu4_source.changes: done.
<Kamion> sivang: yeah, near enough :)
<sivang> Kamion: do you know the simple-cdd pakcage?
<Kamion> no, 'fraid not
<sivang> Kamion: err, I can't find the pakcag all of the sudden
<Kamion> cdd-common maybe?
<sivang> Kamion: maybe so :) checking..
<mdz> daniels: pong
<mdz> morning
<dholbach> hai mdz
<mdz> Kamion: do you publish britney output for universe anywhere?
<Kamion> mdz: no; britney runs on jackass and I don't have direct control over it anyway, I just mirror it
<Kamion> mdz: live CD announcement should be ready to go barring any wording fixes or whatever
<mdz> Kamion: positive feedback overnight?
<Kamion> worked for me on amd64, Kinnison liked it, haven't heard anything negative
<mdz> amu,lamont,thom: did your live CD tests go OK?
<Kamion> did wonder why it was taking >140MB of RSS just to run GNOME
<mdz> measured how?
<Kamion> oh, one thing that came to mind was that update-notifier doesn't really seem to make much sense in a live CD environment, but sits there chewing memory
<seb128> thom: bah you close bugs with changelogs entries not related to the bugs :p (#5585)
<Kamion> 'free'
<mdz> free says I am using 621M of memory after cache+buffers
<Kamion> not counting cache+buffers
<mdz> s/after/not counting/
<Kamion> fresh live CD, just started gnome-terminal and that's about it
<mdz> do you not normally run GNOME on your desktop?
<Kamion> not when I'm doing real work, no :P
<Kamion> I thought GNOME's system requirements were more like 128MB
<mdz> I don't think GNOME can accept all of that memory
<Kamion> and I'd expected there to be some slack in there
<lamont> mitzi's machine has 128MB... I wouldn't tolerate it
<mdz> it could very well include the 64M ramdisk
<Kamion> ah, possible
<mdz> I should add a text-only mode to casper
<Kamion> I thought we freed that
<mdz> no, it's used for COW
<Kamion> like 'live DEBCONF_PRIORITY=text'? :)
<mdz> we free the d-i tmpfs
<Kamion> er, DEBCONF_FRONTEND
<Kamion> or do you mean 'boot live CD to login: prompt'?
<mdz> the latter
<Kamion> ah; yes, that would be nifty
<mdz> "don't start gdm" mode
<mdz> could we allocate an isolinux section for the purpose?
<Kamion> isolinux doesn't really have sections ...
<mdz> or at least a bare command-line word, rather than a really-long/debconf-one
<Kamion> live-text?
<mdz> whatever you call the bits in isolinux.cfg that let you boot with different kernels/initrds/parameters
<Kamion> oh ok
<Kamion> sure
<mdz> casper-udeb/mode=text?
<mdz> or casper-udeb/display-manager=false
<Kamion> I think I prefer debconf templates to express single functions; the boot name can be friendlier
<mdz> heh, every small thread I start on ubuntu-devel to ask the question whether a particular package makes sense to promote to main, it erupts into a frenzy of people wanting their favourite package in main
<Kamion> hm, I need to shift casper to preseeding, the command line is beginning to reach the limits
<seb128> thom: what app is to fix (#2547) ?
<mdz> whatever makes sense to you; just let me know how it turns out
<mdz> and I'll make the trivial casper changes
<seb128> hum, just trying the liveCD, the panel is not started on boot, I just get the cdrom icon on the desktop :/
<mdz> seb128: strange; is it the same bug that some people see on normal installs?
<seb128> no
<seb128> or I'm not aware of the install bug
<seb128> I mean there is not panel started at all
<mdz> the panels started OK for me on the live CD
<seb128> I've right click on the desktop
<seb128> open a gt
<seb128> and enter "gnome-panel" in it
<mdz> and that works?
<seb128> yep
<seb128> but that's damn slow, I think the cd-drive has a problem on this box, I'll try with an another one
<Kamion> mdz: oh, how do you feel about renaming the "linux" boot option on i386/amd64 to "install"?
<Kamion> I've never liked the "linux" business
<mdz> Kamion: I always press enter
<Kamion> yeah, but if you need to supply options you have to type it in
<Kamion> powerpc uses 'install'
<mdz> oh, though I guess I do instinctively type'linux' if I need options
<Kamion> the inconsistency is annoying :)
<mdz> what about something which could be the same on install and live?
<Kamion> plus I'm thinking it would be less confusing on an install+live DVD to have the boot options named accordingly
<Kamion> I suppose we could alias linux to install or live accordingly
<Kamion> although it's a bit fiddly, and again makes no sense on an install+live DVD
<opi> can anyone do ma a favor?
<opi> s/ma/me
<mdz> daniels: php4-imap, rock on
<amu> mdz: tested 20050126 i386 with the ubuntu live label it works fine for me
<mdz> elmo: yay for sync notifications
<mdz> amu: 20050126.2 is the one which needs testing; did you mean that one?
<mdz> 20050126.2 will be released as a milestone today unless it is broken
<amu> 20050126 i tested ... unfortunately there was no newer once as i took the image     
<mdz> Kamion: jdub suggested a while ago that we allow sudo based on group membership, rather than username
<mdz> Kamion: this would prevent us from having to modify /etc/sudoers during install, and makes it easy to grant administrative privileges to newly-added users if desired
<mdz> Kamion: what do you think?
<amu> mdz: ok, i'll sync them and test all archs  
<Kamion> mdz: I like it
<Kamion> transition might be a pig, dunno, but I definitely prefer the group approach
<mdz> we can do it only for new installs
<mdz> or maybe just add the group entry to sudoers on upgrade, and mention in the release notes that users can add themselves and others to it
* amu send his QA doc to mdz and jdub and didnt got any Re: should i think, i wasted my time with it?    
<tseng> i typically add users to the wheel group for sudo access
<mdz> amu: you should send these things to the public mailing lists, rather than privately to me
<tseng> matchs su policy on gentoo and bsd
<Kamion> we have no wheel group, and it should be something in base-passwd
<mdz> tseng: I'd prefer not to change the semantics of an existing group, though
<Kamion> I think group 0 is best avoided here; it often leads to confusion
<mdz> amu: I read your report, and I think that it should be made available to other users who would like to participate in testing
<mdz> amu: please keep the process in the open
<Kamion> the 'sudo' group has the wrong semantics though
<Kamion>        exempt_group
<Kamion>                    Users in this group are exempt from password and PATH
<Kamion>                    requirements.  On Debian systems, this is set to the group
<Kamion>                    sudo by default.
<tritium> "The system is going down NOW !!this console" is kind of alarming to see after "Preparing for live session"
<mdz> I think what we want is the '%group in place of user' bit
<Kamion> I just don't like the idea of users with sudo access being able to write to accidentally-mode-775 root:root binaries without any further authentication
<mdz> tritium: cosmetic problems like that will be addressed later; this is an alpha release
<mdz> Kamion, thom: do we have live torrents?
<tritium> mdz, cool, I'm just providing some feedback
<amu> mdz: ok    
<Kamion> mdz: yes, should have
<mdz> yep, torrents are live
<tritium> PPC live CD looks pretty good.  Only resolution is 640x480, but all else looks pretty good.
<tritium> (on a G3)
<mdz> tritium: was Warty better or worse on the same machine?
<tritium> mdz, wrt to resolution?
<mdz> tritium: yes
<amu> mdz: rsync done, burning them ... report for all 3 archs comes 1-2h later   
<tritium> mdz, let me go check my Warty G3 box
<mdz> tritium: if you could file a bug against xserver-xorg with: /var/log/Xorg.0.log and /etc/X11/xorg.conf (from the live CD), and include information about what Warty did on the same machine, that would be great
<mdz> amu: thanks
<mdz> amu: please do i386 first :-)
<mdz> sladen: ping?
<rubenv> anyone has tested on an inspiron 8600c yet?
<rubenv> else i'll grab a livecd
<rubenv> won't make much difference as I'm already running hoary, but hey
<mdz> Kamion, mako, elmo: I'm going to remove the rsync:// info from the announcement before sending it out
<tritium> mdz, warty install gave me 1280x1024 on G3.  md5sum of /etc/X11/XF86Config-4 matches that in /var/lib/xfree86, so I don't believe I changed anything
<mdz> folks who have been rsyncing dailies will already know what to do
<mdz> tritium: could you include a copy of the XF86Config-4 in the report as well, then?
<rubenv> I have put up a 10mbit torrent seed for the three cds btw
<tritium> mdz, yes
<mdz> rubenv: thanks!
<rubenv> maybe i'll up it to 50mbit
<rubenv> ah, why not :)
<mdz> hmm
<T-Bone> hi
<haggai> lamont: could you check what OOo1's status is?  i uploaded yesterday and it's listed as out of date but no buildd logs showed up
<mako> mdz: alright
<mdz> Kamion, mako: any chance of getting the pretty dirindex header stuff in?
<mako> mdz: if you're sending it, tell me when its sent and i'll moderate it
<mdz> mako: yeah, I'm going to send it shortly
<Kamion> mdz: oh, into the live index? sure, one sec
<mdz> Kamion: in fact I think it would be good to make that a standard part of the iso publish process
<T-Bone> Kamion: did you have some time to figure out what's happening with my install attempts?
<Kamion> mdz: yeah, I agree
<mdz> Kamion: I guess you'll need to hack it up a bit for this live-only release, but if we could start doing the install and live milestones together, we could reuse nearly the same text
* mako nods
<Kamion> mdz: yeah, I'm trying to keep the text shared
* sivang is on for downloading and testing if it will help at this stage.
<lamont> haggai: i386 should have made the :03 run (just now)
<lamont> ppc is still slogging along...
<lamont> ppc is about 6.5 hours into the 7.5 hour build :-)
<Kamion> mdz: done
<mdz> ooh, nice
<mdz> one day we should add fancy icons
<mdz> but this'll do
<mdz> I'm ready to send the announcement
<Kamion> hold on a sec
<Kamion> just fixing the descriptions for MD5SUMS/MD5SUMS.gpg
<mdz> mako: a GAZILLION people
<mdz> how many is a gazillion these days anyway?
<Kamion> oh, never mind, can't make Apache do what I want, just killed those two descriptions for now
<Kamion> mdz: go ahead
<rcaskey_> mdz: 8 or 9 at least I would suppose
<mako> mdz: i'll tell you when i go in and moderate that message
<mdz> mako: ok, firing
<mako> lots more than news
<lamont> these images any different from last night?
<haggai> lamont: ah cool, thanks for checking
<Kamion> T-Bone: erm ... did you send me the log files from the failed install?
<mako> i think there has been this funny effect where because LWN has been soo good at publishing our stuff, people just don't both subscribing to our announcements lists :))
<mdz> lamont: no, did the ones last night work for you?
<lamont> yeah
<T-Bone> Kamion: i did yesterday, about 4mn after you requested them
<T-Bone> Kamion: :P
<Kamion> T-Bone: erm, can't find them
<mdz> mako: they kill us with love
<lamont> mdz: is the lack of an ia64 live because it doesn't build, or because we've decided to drop ia64 until things work?
<T-Bone> Kamion: fix your attachment killer? :P
<Kamion> let me see if I had a spam filter problem again
<rcaskey_> btw, I must say ubuntu is one of the few announce lists that actually hits the sweet spot of keeping you informed without filling your inbox with junk
<T-Bone> Kamion: Message-ID: <20050127000631.7847949c@Tatooine.r3z0>
<Kamion> bah, yes
<mako> we're gonna send two today
<mdz> lamont: last I heard from you, ia64 cloop didn't build
<mako> which is two more than we've sent in the last two months
<lamont> mdz: yeah - I need to check on that...
<mako> one for LoCo Teams, one for the live CD
<mdz> lamont: d-i certainly builds
<T-Bone> Kamion: do i have to send it again?
<Kamion> T-Bone: nope
<T-Bone> k
<rcaskey_> mako: when is array 4 happenin'
<Kamion> retrieved it
<mdz> am I not subscribed to ubuntu-announce? I might not be
<rcaskey_> I checked the schedule but it seems..off
<Kamion> rcaskey_: next Wednesday probably
<lamont> mdz: built last night: livecd-20050127-ia64.cloop-1024:65536 
<Kamion> the schedule needs to be rewritten to reflect reality
<rcaskey_> Kamion: and ics'd
<Kamion> rcaskey_: ics'd?
<lamont> mdz: there's been a 'current' for ia64 since 0119.4, with a hiatus on 25-26
<mdz> lamont: oh, I didn't notice that it was already building in the normal daily runs
<rcaskey_> put out an ical
<mdz> lamont: have you tried it yet?
<lamont> mdz: it's on the list...
<rcaskey_> it's all the rage for people who aren't writing in grease pencil on their monitors
<mdz> lamont: I've just been in the habit of invoking the build script with ARCHES="i386 amd64 powerpc"
<lamont> although I want to try the install CD first - my i2000 really wants to retire soon, you see....
<Kamion> mdz: the build script was taking care of that for you already :-P
<mako> mdz: it hasn't showed up yet
<Kamion> 2005-01-20 12:39:43 GMT Colin Watson <colin.watson@canonical.com>       patch-108
<Kamion>     Summary:
<Kamion>       Enable ia64 live CDs.
<mdz> mako: Jan 27 10:20:06 localhost postfix/smtp[5055] : A61A8B8780: to=<ubuntu-announce@lists.ubuntu.com>, relay=mail.alcor.net[68.168.78.100] , delay=11, status=sent (250 Message received: 20050127181753.LGOG10643.mta10.adelphia.net@mizar.alcor.net)
<mdz> Kamion: when you told me how to run it, you included that in your example
<Kamion> mdz: yes, but then I committed:
<Kamion> 2005-01-11 00:20:38 GMT Colin Watson <colin.watson@canonical.com>       patch-105
<Kamion>     Summary:
<Kamion>       temporarily remove ia64 from list of live CD architectures
<Kamion> mdz: guess I forgot to tell you, sorry
<mdz> I don't generally read the patch-logs :-)
<mdz> at any rate, we couldn't have released it with array3.5 since no one had tested it
<mako> mdz: i did eventually receive that message from you yesterday :)
<Kamion> true
<mdz> mako: where did it get held up, according to the headers?
<mako> let me check
<rcaskey_> Kamion: but it would be nice to just subscribe Evolution/Sunbird/iCal/Outlook and watch the schedule and get updates automatically
<Kamion> rcaskey_: oh, THAT ICS
<mdz> as opposed to the internet chess server?
<rcaskey_> yeah
<Kamion> T-Bone: how strange; debootstrap doesn't even appear to be trying to install lsb-release, yet it is in its list and it's in the archive
<rcaskey_> "So Bishop to King's Four, is that sooner or later?"
<T-Bone> Kamion: that's exactly it. Besides, it fails on unrelated package:
<rcaskey_> are auto updates going to beanbled out of the box for Warty?
<rcaskey_> err Hoary
<Kamion> T-Bone: not unrelated, ubuntu-base depends on lsb-release
<T-Bone> it says it can't install initrd-tools in the first place, whilst they are installed already. Same for the next error (after reattempting)
<Kamion> that's not an error
<T-Bone> Kamion: the error message on the install screen happens to say "There was an error installing initrd-tools, please check tty3..."
<Kamion> solve the first error and that will probably go away; there is little point attempting to debug subsequent errors that are all consequential
<T-Bone> agreed
<Kamion> T-Bone: do you have lsb-release on your CD? (use isoinfo -lR -i foo.iso | grep lsb-release)
<Kamion> T-Bone: what version of debootstrap do you have on your CD?
<Kamion> is this a CD? :-)
<T-Bone> Kamion: lol, that was daily from 25th
<T-Bone> lemme check
<Kamion> cjwatson@little:~/cdimage/www/full/daily$ isoinfo -lR -i 20050125/hoary-install-ia64.iso | grep lsb-release_
<Kamion> -r--r--r--   2    0    0            9342 Nov 17 2004 [  78888 00]   lsb-release_1.4-7.1ubuntu6_ia64.deb
<Kamion> cjwatson@little:~/cdimage/www/full/daily$ isoinfo -lR -i 20050125/hoary-install-ia64.iso | grep debootstrap-udeb_
<Kamion> -r--r--r--   2    0    0           38296 Jan 19 2005 [  18789 00]   debootstrap-udeb_0.2.45ubuntu22_ia64.udeb
<Kamion> ohh
<T-Bone> there you have it :)
<Kamion> use a newer CD with debootstrap-udeb 0.2.45ubuntu23
<Kamion> debootstrap (0.2.45ubuntu23) hoary; urgency=low
<Kamion>   * [hoary]  Add lsb-release (closes: Ubuntu #2501).
<T-Bone> dooooh
<T-Bone> Kamion: is it on today's iso?
<Kamion> yeah
<T-Bone> cool
<T-Bone> let's fetch it
<Kamion> cjwatson@little:~/cdimage/www/full/daily$ isoinfo -lR -i 20050127/hoary-install-ia64.iso | grep debootstrap-udeb_
<Kamion> -r--r--r--   2    0    0           38024 Jan 26 2005 [  18789 00]   debootstrap-udeb_0.2.45ubuntu23_ia64.udeb
* T-Bone needs to rsync isos instead of dlding them at some point
<Kamion> whoa, yeah, definitely
* T-Bone tries to recall how to do that
<sladen> T-Bone: man rsync
<T-Bone> sladen: no kidding?
<Kamion> I'm sorry, not sure how ubuntu-base 0.20 got onto that CD without the corresponding debootstrap-udeb
<T-Bone> sladen: what's 'man' btw?
<sladen> mdz: pong
<Mithrandir> rsync -v --progress --partial -a archive.ubuntu.com::cdimage/daily-live/current/hoary-live-amd64.iso hoary-live-amd64.iso
<Mithrandir> adjust for your file names.
<T-Bone> Mithrandir: thx a lot ;)
<Kamion> best use cdimage.ubuntu.com::cdimage/
<sladen> mdz: haven't done anything in the last couple of days.  Currently fighting my tax-return atm
<lamont> mdz: your liveCD boots slower than thom's laptop... :)
<mdz> sladen: oddly enough, I think I was pinging about something other than the usual usplash nagging ;-)
* lamont needs one more W2, then he can fight with his taxes
<mdz> lamont: maybe we should save a swsusp image from a booted system on the CD and restore it
<mdz> for ultra-fast boot
* ogra wonders how fast thoms laptop boots ....
<mdz> I guess that wouldn't work too well on varying hardware, though
<lamont> mdz: getting that to work with hw detection would be most amazing...
<lamont> "null symbol found"
<lamont> hrm.
<T-Bone> gah, still sucky throughput on cdimage.u.c ;P
<lamont> T-Bone: announcements can do that to you...
<mdz> lamont: yeah, saw that too
<mdz> it's new
<T-Bone> lamont: hehe ;)
<sladen> mdz: hardware issues;  you might be able to do it if you hid everything behind a xnest;  but then 3d would suck
<lamont> Kamion: as a reminder, rootfs for *64 will grow (slowly?) over time - we'll need to reset them every so often...
<sladen> lamont: how much fixing did you reckon partimage needed?
<lamont> sladen: it's pretty systemic
<mdz> how high does it score on the warn-o-meter?
<lamont> mdz: makes pointer from int of wrong size _all_ over...
<mako> you will be pleased to hear that we have put the fun back in computing: http://www.netsite.co.uk/content-185
<sladen> lamont: I'd be tempted to take the '-e' code path, strip the rest and just get that one subset of the code working
<lamont> growth rate looks pretty slow, actually.. 50-100KB/day about
<mdz> mako: does that count as InThePress?
<sladen> anyone seen:  http://www.irmateam.com/  the colour Rosetta ripoff?
<mako> mdz: it's not *really* press
<mdz> mako: yeah
<lamont> sladen: we actually save and restore, in order to walk the -e path
<mdz> mako: there's a lot of stuff like that out there, though
<mdz> mako: we should have a "nice things people have written about us who are not press" section
<mako> yeah totally, it would be good to collect it
<lamont> sladen: I'd me _very_ happy if I could just run -e on a partition
<mdz> mako: like that o'reilly stuff
<mdz> and people's blogs
<mako> yeah totally
<mako> we need a Love Letters section
<mxpxpod> is there a way to map the alt key on an ibook keyboard to Super_R and the apple key to Alt_L without using xmodmap?
<ogra> mako: wow, what a great name
<mdz> ogra++
* mako bats his eyes flirtateously at Ubuntu
* mdz surprises Ubuntu with a bouquet of flowers
<mdz> mako: right, so apparetnly my mail relay is fucked
<mako> i think we've now approached that point of all-consuming work where were are personifying our work and endowing it with romantic qualities.. like truckers who name their truck sally
<mdz> mako: I've pasted the announcement with my edits back into the wiki
<mako> mdz: i can send it
<mdz> mako: so that you can send it instead
<amu> mako: only if you promise, my wife will never find them :) 
<mako> http://www.ubuntulinux.org/wiki/LiveCDAnnouncement ?
<ogra> au: lol
<mdz> yes
<ogra> amu ^^
<lamont> smurfix: you need a few more userid's on your key. :-P
<smurfix> lamont: I know. *preen*
<lamont> bouncing cow.  yum
<amu> "This is the ubuntu LiveCD" yes!
<mdz> sladen: oh, I remember.  I wanted to know how you addressed the issue of console output from init for usplash, to see if I could apply the same method to the live CD
<mako> mdz: sent, let me see if i need to moderate my own messages
<mdz> sladen: where I need to suppress the "System is going down NOW" what not
* ogra wonders if lamont sees a bouncing steak there....
<sladen> lamont: see man chattr:   When a file with the s attribute set is deleted, its blocks are zeroed and written back to the disk.
<sladen> lamont: is that a stop-gap you could use
<mako> mdz: sent!
<sladen> mdz: don't think I've dealt with that particular one.  console=tty should take care of it, let me test
<lamont> sladen: so set the 's' attribute on every file in the image, rsync, and then clear the flag (since we don't want that on the disk...)
<mako> if i don't get to be "supreme community commander" i want to be "propaganda minister"
<lamont> mako: 'minister of propaganda' you mean
<mako> lamont: right
<mdz> mako: only if pitti can be "minister of defense"
<lamont> pm is prime minister
<lamont> or process management..
* lamont is never sure
<mako> mdz: YES
<T-Bone> lamont: pm is *after lunch* ;)
<sladen> lamont: for the livecd, there shouldn't be any problem is just leaving it on
<sladen> s/is/with/
<lamont> sladen: removing the file on the livecd with that set would cause it to allocate zero blocks from the ramdisk
<lamont> which is not what we want...
<sladen> lamont: but yes, chattr -R  the lot, then chattr -R again
<mako> in the US, secretary of war was changed from secretary of war. i think Minister of War would be equally intriguing :)
<mako> sorry, secretary of defense was changed from secretary of war
<sladen> lamont: good point...  
<lamont> sladen: given that chattr feature, why shouldn't I just switch over to that completely, instead of using partimage?
<lamont> seems to be exactly what the doctor ordered.
<mdz> lamont: they do different things
<lamont> ok.
<mdz> the chattr won't ensure that _all_ empty blocks are zeroed
<lamont> chattr probably doesn't deal with the inode
<mdz> it also won't deal with files created during the build process
<lamont> ah, yes
<Treenaks> mako: next stop: secretary of peace
<lamont> wait - those don't count
<mdz> oh, ou're righn
<mdz> you're right
<lamont> files that are created and removed during the build process are not on the image
<mako> Treenaks: make love not war
<mdz> lamont: rsync --inplace won't delete the file, though
<mdz> and slack won't be zeroed (will it?)
<sladen> it'll likely not deal with freed-up inodes.  But I suspect the number of those may well be small enough not to worry for the moment
<mdz> the man page only mentions deletion, not change of size
<sladen> *shrug* try it and see
<mdz> mako: bittorrent is building
<mdz> mako: <5 minutes from transmission ;-)
<dholbach> i'm trying to set up a pbuilder, and followed the howto on the wiki, but everytime i try to build something, i get this at some stage:
<dholbach> dpkg-source: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)
<dholbach> dpkg-parsechangelog: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)
<abelli> smurfix: ding
<mako> smurfix: i think we shoudl put info on locos onto the participate page
<mako> smurfix: what do you think?
<smurfix> mako: do it
<smurfix> abelli: dong ?
<mako> smurfix: cool.. i send that link out probably a dozen times a day
<abelli> smurfix: what about the domain you have registered?
<mako> smurfix: so having something there  would be super useful i think
<smurfix> abelli: ubuntu-it.org ?
<abelli> is it? ok..so yes.
<smurfix> abelli: do you have a webspace it should point to?
<abelli> ubuntuitalia.org
<abelli> ill send you the ip as soon as i receive the sparc that will host it
<ogra> abelli: wow, so you will be the first user of fabbionnes sparc port ?
<abelli> ogra: im actually supposed to help fabbione in that.. but im so crap in mantaining promises
<abelli> i mean trying to fix d-i's bugs
<smurfix> abelli: as soon as you have it, tell it to accept that name (plus www.*) as ServerAlias and tell me the IP.
<sladen> mdz: ''System is going down now'', is actually wall'ed to everyone.  Hmmm, hadn't actually thought about that one
<lamont> The Live CD runs completely off of the CD and will not touch any of the data on your hard drive so it is:
<lamont> liar.
* Mithrandir quickly upgrades his sparc to ubuntu-sparc.
<sladen> has anyone played with Alpha yet/
<abelli> smurfix: so you're not going to redirect it on ubuntuitalia.org?
<lamont> sladen: I have one.. :-)
<abelli> lamont/sladen: how much?
<lamont> mako: the announcement doesn't mention swap partitions... :-)
<sladen> abelli: well, I paid nothing.  But still need to find it a phat IDE disk
<lamont> abelli: I paid the same amount as sladen
<abelli> why are you this lucky?
* ogra would love a up2000 .... if anybody knows one for sale.......
<amu> mdz: i386 .... ipw2200 isnt autodetected, it was before,  xorg with 640*480, and UNKNOWN keyboard, 
<lamont> mine says 'alphastation 600 5/266'
<sladen> mine says 'Alphastation 500au ?/???' -- 500Mhz chip
<Mithrandir> 2 kNOK for a Ultra 10.  that's not too bad.
<sladen> mdz: patching init is the obvious one, either to just syslog, or to >/dev/console which is got rid of in the normal fashion to tty1
<abelli> i actually bought a 450mhz ultra sparc for 10 eur on ebay
<lamont> mdz: when I umount things (from the command line) their icons don't disappear.
<abelli> but it sounds a bit crappy
* lamont has an SS5 and an SS20
<lamont> actually paid money for one of them - can't remember which
* sjoerd paid money for his SS5
<mako> abelli: wow
<sjoerd> got my ultra 5 for free
<mako> my fastest computer is 750 mhz
<abelli> sjoerd: that's unfair..
<abelli> =)
<Mithrandir> my slowest, working computer is 450MHz.  It being my DSL gw.
<sjoerd> abelli: what was unfair is that they didn't have a monitor for me anymore :)
* T-Bone got a SS4 and U5 for free too ;)
<lamont> mako: mitzi's computer is 1.6GHz, but only has 128MB of RAM... :-(
<[Clint] > my fastest working computer is 1GHz, being my firewall
* Mithrandir got a SS4, SS5, SS10 and U5 for free! :)   Possibly also a SS20, I don't remember.
<mako> lamont: i have .5GB memory and lots of fast disk which is all that really matters for me
* T-Bone stares at mako ;^)
<mako> T-Bone: ion
<mako> this gnome stuff is for weenies
<Mithrandir> I need a bit more memory, since I only have .5GB.
* mako remembers what channel he's in
<T-Bone> hehe
<mako> whoops
<T-Bone> lol
* lamont goes to see if his wife logged off, so he can try adding more memory to her machine
* T-Bone has .5GB on his dual g5 2.5GHz, which is a shame
<mdz> sladen: in busybox init, it's just written to the console fd, not wall'd
<Mithrandir> T-Bone: that's just silly.
<abelli> mako: im going to buy a 200mhz arm processor and itll cost 20 times that sparc..
<mdz> sladen: which is /dev/vc/0 at the moment
<Mithrandir> I'm getting 2GB in the FX55 I'm getting for my thesis.  That's nice.
* abelli is away pappa time
<T-Bone> Mithrandir: heh. I need more money to buy ram. As a matter of fact, i have a few very powerful box handy, but they usually lack either RAM or disks ;P
<mako> T-Bone: that stuff is overrated anyway ;)
<Mithrandir> T-Bone: then they're not very powerful :)
<T-Bone> aside from the ia64 which are well gifted in RAM (2GB each), the next box i have with a reasonnable RAM amount is my old dual G4: 1GB. Everything else ranges between .2 and .5
<T-Bone> Mithrandir: alas :P
<mdz> mako: ~5mbit sustained up from my seed alone
<mako> mdz: shit.. let me jump on that
<mdz> amu: my ipw2200 was detected
<T-Bone> Mithrandir: I'm looking for a hardware sponsor, see? :^)
<mako> columbia.edu to the rescue!
<mdz> amu: these problems are all new with array3.5 compared to 20050126??
<sladen> mdz: are you just worried for the LiveCD---it would be nice to get rid off it for the desktop install too
<mdz> sladen: well, the live CD uses a completely different init
<mdz> sladen: so I imagine we need to do the work twice
<mdz> at least if we end up patching init
<T-Bone> w00t. Stack dump and kernel oops while trying to mount a freshly JFS / partition with Hoary daily d-i
<mdz> ono ia64?
<T-Bone> that's the first time I try JFS on ia64 tho. Guess i'm gonna use some other fs
<lamont> T-Bone: non-gluttons use ext3...
<mdz> s/ono/on/
<amu> mdz: yes
<T-Bone> lamont: ext3 suck hell
<amu> mdz: testing now ppc
<mdz> amu: that makes no sense
<mdz> they use exactly the same cloop image
* T-Bone would have to try JFS with debian d-i to compare at some point
<tritium> do I have to commit my description on bugzilla before I can attach files?
<mdz> amu: the primary difference is that d-i will not ask questions for network config
<mdz> that should be very nearly the only difference, in fact
<amu> mdz: with 20050126 i can choose my network, now, 2 times tried it was detected but not ask for a essid  
<mdz> amu: ok, that is a feature then
<T-Bone> lamont: ayeee. Seems that the partition table got fscked up
<amu> mdz: i've 3 different access points ... 
<mdz> it is detected; it simply leaves it unconfigured in order to be non-interactive
<smurfix> Who can replace ubuntulinuxorg's favicon.ico? I've got a nicer one with a transparent background ;-)
<amu> mdz: sorry, i should say configured, it is detected  
<mdz> amu: ok, I am relieved
<lamont> Kamion: d-i... This is the Ubuntu installation system, built on 20041227ubuntu6.   -- those extra 7 characters kinda mess the output up a bit...
<mdz> amu: what about the X config, you said it was 640x480
<mako> mdz: i'm downloading at 20Mb/s and going up quickly :)
<mdz> whoa
<amu> mdz: nv card, use the correct driver, nv, xorg.config set the correct resolution 1600*1080, but X starts with 640*480   
<mdz> mako: | speed:      0    B/s down -   2.3 MB/s up                                    |
<mdz> mako: I think you're downloading from me over i2 ;-)
<mdz> amu: same with 20050126?
<mako> man.. downloading a CD iso in 4 minutes is *great*
<mdz> mako: 2.3 megabytes/sec is an insane amount of uplink
<amu> sorry i cant remember 
<lamont> Detecting hardware to find CD-ROM drives  ..12%..22%..32%..42%..52%..62%Detect and mount CD-ROM
<lamont> !! ERROR: Error while running 'modprobe -v amd74xx'
<lamont> grumble
<T-Bone> lamont: yeah
<lamont> interestingly, it finds the cd after that...
<T-Bone> lamont: i think this one should be removed
<T-Bone> lamont: yeah, it's just a stupid module handling poorly the case where no matching device is found
<T-Bone> that's really nothing more than a lame bugger
<mdz> I wish we could dispense with loading those modules explicitly
<mdz> and just let hotplug handle it
<mako> mdz: if it dipped now, it's because i finished
<amu> mdz: @ was also not working with a germany keyboard layout, same with 20050126
<ogra> dholbach: gah, my evo has a floating point exception on amd64 too, dammned.....
<mdz> mako: yeah, falling
* T-Bone crosses fingers, 60% done of ubuntu-base
<dholbach> have a nice evening - i'll have a beer :-)
<dholbach> mvo_: see you in 25 minutes :-)
<sivang> dholbach: night
<sivang> dholbach: eh
<lamont> T-Bone: I'm using the 1/24 install cd
<dholbach> ogra: thats why i switched to mozilla-thunderbird temporarily :-/
<T-Bone> lamont: will fail
<sivang> dholbach: just noted you're going to get a beer and not signing ogg
<ogra> dholbach: orig.tar.gz ??
<T-Bone> lamont: use today's
<dholbach> ogra: later :-)
<ogra> k
<lamont> T-Bone: ah, ok.  that'll be about 2 days from now, at the current download rate... :(
<dholbach> sivang: signing ogg?
<lamont> or I could drive to town..
<T-Bone> WHEEEE! Ubuntu-base done!! Kudos to Kamion :)
<T-Bone> lamont: it will fail no matter what. You're wasting precious download time :^)
<lamont> T-Bone: I _have_ 1/24.  I'm downloading yesterdays
<mako> mdz: we need to find out how to take advantage of our 2MB/s connection between each other
<mako> mdz: stream movies or something
<lamont> or do I need this morning's daily build?
<T-Bone> lamont: you do
* ogra goes to morgue... :-/
<T-Bone> any cd before 1/26 is buggy
<lamont> sigh and grumble
<mdz> mako: yeah, maybe we could even find a way to get ARRESTED
<lamont> before, or 'on or before'
<T-Bone> mako: try videolan: www.videolan.org ;)
<mdz> mako: don't you know, streaming media kills babies
<tritium> mdz, I filed a bug against xserver-xorg as you asked, re: G3 LiveCD resolution
<mdz> tritium: thanks
<mako> mdz: dude, my favorite radio statino in seattle streams UNCOMPRESSED
<T-Bone> lamont: can't tell. I'd say on or before. Kamion can answer ;)
<tritium> it's #5940.  sorry daniels ;)
<mdz> mako: what, at like 8khz?
<mako> mdz: 44khz
<mako> mdz: 1.4Mb/s
<dholbach> bye
<shaya> noticing changes needed for beagle are making it into hoary.  are there beagle debs anywhere?
<T-Bone> err
<T-Bone> Kamion: "No boot loader has been installed". WTH?
<abelli> mako: yo, can you introduce me to docbook?
<mako> mdz: www.kexp.org
<lamont> docbook: abelli; abelli: docbook.  :-)
<Mithrandir> abelli, meet docbook.  docbook, this is abelli.
<Mithrandir> :)
<mako> abelli: do you need a tutorial?
<lamont> Mithrandir: ^5!
<mako> abelli: because at the moment, i'm a bit swamped
<abelli> mako: thank you
<Mithrandir> lamont: :D
<tritium> mako, are you in Seattle?
<abelli> mako: ok another day
<mako> tritium: new york today :)
<T-Bone> lamont: any clue why it doesn't install elilo?
<lamont> T-Bone: ah, initrd-tools, eh?
<mako> tritium: i haven't been in seattle since sunday ;)
<lamont> T-Bone: that's a Kamion question
<T-Bone> lamont: yeah. But initrd-tools ain't the problem. The problem is a fux0red debootstrap
<lamont> ubuntu-desktop/base don't depend on any boot loaders
<tritium> mako, Oh, okay.  I used to live in Mukilteo when I worked at Boeing.  :)
<tritium> (Everett facility)
<T-Bone> lamont: there's no way you can get something useful out of these CDs without arse-pain
<mako> tritium: i'm from seattle and my family is still there.. so i end up there pretty frequently
<lamont> T-Bone: even todays?
<tritium> mako, I've since moved away.  Sometimes I go back to visit.
<T-Bone> lamont: todays works, except it complains at the end that it will not install any boot loader, which is a regression from previous ISOs
<lamont> T-Bone: ah, ok.
<T-Bone> lamont: hence my surprise
<lamont> and then it's execute a shell and install elilo time, eh?
<mdz> mako: that is insane
<T-Bone> lamont: right
<abelli> seattle? wasnt zero cool from seattle?
<T-Bone> lamont: i'm a bit sad, i thought today was *the* day. Ie the day we could have announced that IA64 is now instalable ;)
<mako> abelli: he was
<mako> abelli: and he moved to newyork.. just like me :P
<abelli> mako: thank you, have you seen acid burn lately?
<lamont> T-Bone: today isn't over yet...
<mdz> Mithrandir: ping?
<T-Bone> lamont: heh
<T-Bone> lamont: at the end when it tells you to reboot, do: modprobe efivars; chroot target; apt-get install elilo; elilo --autoconf --efiboot --root /dev/rootdev -b /dev/EFIdev and you're done ;)
* T-Bone boots his brand new Ubuntu-installed zx2000! YAY!
<lamont> T-Bone: woot
<T-Bone> doh. something went wrong
<T-Bone> the boot menu entry wasn't added :(
<abelli> dehiho..
<abelli> what can you do with such a machine?
<T-Bone> lamont: well, it's just cosmetics. The files are there in EFI/ubuntu
<abelli> ahh.. intel..
<T-Bone> there it boots
<T-Bone> and hangs on hotplug, just as usual
<T-Bone> ah no, this time it went further
<T-Bone> lamont: this is live news dude, the box is up and running with the nice greeting message ;^)
* T-Bone giggles
<lamont> abelli: I use it for the local mirror and squid proxy
<abelli> lamont:  what the sparc one?
<lamont> abelli: actually an i2000
<T-Bone> lamont: what would it take to get the installer do the right thing WRT elilo?
<T-Bone> oh bummer, that's a kamion question ;)
<lamont> T-Bone: I imagine someone with clue... :)
<T-Bone> lol
<T-Bone> i'll send a diff to fabbione. I think we want efivars builtin somehow. I'll have to check the behaviour on the zx6000 too, had issues with MPT Fusion devices
<lamont> T-Bone: wonder if maybe the issue is the modprobe efivars?
* T-Bone is currently waiting for ubuntu-desktop installation to complete
<lamont> that is, it's not there, so the elilo step gets skipped, or fails, or something
<T-Bone> lamont: nah. elilo works without efivars. It just can't update the boot entry in that case
<abelli> lamont: thank you
<abelli> does anyone here knows extremetech.com
<T-Bone> lamont: not having efivars doesn't prevent you from installing a package, hopefully ;)
<abelli> i actually need some kind of site to get introduced to 64 bit processors, i dont want to read each developer guide
<T-Bone> IDE disks are so full of shit. They're a shame to any powerful machine ;P
<T-Bone> abelli: what do you want to know? The difference is that instructions and registers are wider, that's all :^)
* T-Bone ducks
* abelli is in debt with T-Bone 
<abelli> will ever ricover this debt?
<abelli> T-Bone: i mean main differences, pros and cons, of alpha, usparc, g5
<T-Bone> doh
<T-Bone> lamont: ok, i'm adding to the curse list 'udev' and 'hotplug'
<lamont> T-Bone: udev is your friend, though.
<T-Bone> i have 60+ of these process running defunct at nice -10
<T-Bone> the box is collapsing
<T-Bone> lamont: nah. udev is not my friend :(
<lamont> udev event issues in 2.6.10 ia64 kernel.  check.
* T-Bone disables udev and hotplug, adds a few modules to /etc/modules, reboots
<T-Bone> lamont: that's "udev block" and "hal" stuff going mad
<sjoerd> T-Bone: hald a D process by any chance ?
<Treenaks> sjoerd: I had my load going way up during upgrade... reboot fixed it
<Treenaks> sjoerd: no processes running (according to top) though
<sjoerd> Treenaks: pitti discovered a weird bug where upgrading hal dosses the system without any apparent reason
<T-Bone> sjoerd: nope
* sjoerd has never seen the behaviour
<Treenaks> sjoerd: yes, I had that as well
<Treenaks> sjoerd: reboot fixed it
<sjoerd> same for him
<Treenaks> argh! desktop scrolling using the scrollwheel is the "wrong way around"..
<Treenaks> scroll up is move left..
<Treenaks> that's just Wrong
<abelli> buona sera
<T-Bone> sjoerd: the mess happened while i was apt-get install'ing ubuntu-desktop
<Treenaks> abelli: goedenavond
<sjoerd> T-Bone: mabye the same problem then
* abelli is away recruiting ppl for fabbione's sparc port
<sjoerd> T-Bone: hoary install/upgrade ?
<T-Bone> sjoerd: hoary install
<T-Bone> sjoerd: just killed all udevd and the box feels much better
<ogra> gah 30 mins for downgrading evolution manually....
<ogra> what a crap
* T-Bone gets nice "I/O error: No such file or directory" messages while scrollkeeper rebuilds its db. Amusing
* lamont looks at abiword, scratches his head
<amu> mdz: ppc on a pb4 is fine, except there's also no @ with german keybord layout, amazing thing was, i'm beeing ask about the essid ( ext. pcmcia card ) 
<ogra> lamont: its something to write text ith ;)
<ogra> with even
<lamont> ogra: reviewing patches - changelog and actual patch are somewhat at odds.
<ogra> ah....
* ogra curses evolution...
<Treenaks> ogra: "curses evolution".. that's called "mutt"
<ogra> Treenaks: .-P
<T-Bone> floating-point assist faults  with firefox-bin. Yummy
<mdz> amu: the netcfg changes are a bit ad-hoc; there are probably still cases where it can ask a question
<ogra> T-Bone: could you try if evolution segfaults with a floating point error on ia64 too ? i suspect there is a 64bit prob with it....
<T-Bone> ogra: sure, once i have the box almost working. Besides, a bug on ia64 does not necessarily mean that's 64bit related. If you knew how many progs actually bug on ia64... ;P
<T-Bone> s/ia64/ia64-linux/g
<amu> mdz: you would like an amd64 test also ?  
<mdz> amu: certainly
<mdz> it works ok on amd64 here
<mdz> but more testing is always good
<ogra> T-Bone: but if it fails on amd64 _and_ ia64 there is some hint in this direction i think....
<Kamion> lamont: 20050126 at least has the updated debootstrap-udeb
<T-Bone> ogra: heh
<Kamion> T-Bone: ubuntu-desktop is frequently screwed; I generally blame GNOME
<Kamion> T-Bone: elilo> hmmmm
<lamont> -# GNUmakefile.in generated by automake 1.9.3 from GNUmakefile.am.
<lamont> -# @configure_input@ 
<lamont> +# GNUmakefile.in generated automatically by automake 1.4-p6 from GNUmakefile.am
<lamont> what's wrong with this picture, hrm?
<ogra> Kamion: huh ? i thought GTK 
<Kamion> T-Bone: look in /var/log/syslog (or /var/log/debian-installer/syslog) and tell me if there's anything from elilo-installer in there
<T-Bone> Kamion: well i usually blame ia64 and its linux kernel support ;)
<Kamion> if ! apt-install elilo ; then
<Kamion> it certainly tries to install elilo
<T-Bone> booting, will tell in a few sec
<Kamion> lamont: pre-20050126, you'll need to edit /usr/lib/debootstrap/scripts/hoary before base-installer runs and add lsb-release to base
<T-Bone> things are much better without hotplug/udev, fwiw
* T-Bone gets up to the GDM prompt, sweet!
<Kamion> we need to fix hotplug/udev, not just make them go away :)
<mdz> indeed
<mdz> is there any reasonably authoritative Python parser for Packages style files?
<Kamion> T-Bone: you said they were *defunct* processes, though? as in zombies?
<mdz> everyone seems to include their own
<Kamion> mdz: I thought that was python-apt
<mdz> reportbug, linda, apt-listchanges, etc.
<Kamion> T-Bone: I'd be more inclined to pin that on a kernel bug, personally ...
<T-Bone> Kamion: as in zombies, "D" state, whatsoever
<mdz> Kamion: python-apt's is nice and fast, but not very Pythonic
<mdz> it is instead apt-ish
<elmo> it's definitely the close we have to authoritative for Python tho
<elmo> closest
<Kamion> zombies != D state by quite a wide margin
<T-Bone> Kamion: yeah, the kernel sucks a lot
<mdz> it can't do things like parse from a Python file object
<mdz> because it needs a real file descriptor to give to apt
<elmo> yeah, that's annoying
<T-Bone> Kamion: i said 'defunct' in the first place :)
<mdz> slack ass maintainer should fix it
<Kamion> T-Bone: it really needs to be fixed; we are standardising on udev and hotplug across the whole distribution for good reasons, and we're going to have trouble supporting an architecture that can't cope with them
<T-Bone> Kamion: heh.
<T-Bone> Kamion: i can't find anything very clear in the installer logs, i'll mailthem to you
<Kamion> T-Bone: I've weakened my filters a bit, shouldn't be sin-binning your attachments any more
<T-Bone> ok
<T-Bone> ;)
<ogra> T-Bone: btw, you are listed on MaintainerCandidates.....since ages....
<T-Bone> ogra: never took time to remove that entry ;)
<ogra> T-Bone: oh, you doont want anymore ? or did you bypass the process ?
<lamont> mdz: thoughts on albatross 1.10-9.1?  claims to be no different than 1.10-9ubuntu1 - do we want to sync that, or leave them split?
<T-Bone> ogra: actually i'm a maintainer since sometime before december
<mdz> lamont: universe, fine with me
* lamont adds the tag, slowly building his collection
<ogra> T-Bone: sad, i thought i found another MOTU victim to poke and annoy you until you join...... ;)
<T-Bone> ogra: actually i've never been a MOTU ;)
* ogra wants at least 10 MOTUs on the next CC agenda....
<mdz> ogra: YES
<elmo> giggle
<lamont> elmo: if you're bored, please sync albatross_1.10-9.1
<tseng> ogra: i might be mistaken, but there is a long list on MaintainerCandidates that i dont think have been on an agenda
<elmo> lamont: err, it's already in universe?
<elmo>  albatross |   1.10-9.1 | hoary/universe | source
<ogra> tseng: it requires more then just being on MainainerCandidates.....i.e. some action from your site as you know ;)
* lamont grumbles
<tseng> ogra: yes.
<thom> seb128: the ones mentioned; gaim, notably
<ogra> tseng: so its a thing to poke them to get active :)
<elmo> 124G    /srv/ftp.no-name-yet.com/backup
<elmo> hmm, that might be a bit OTT
<thom> yow
<T-Bone> Kamion: i just hit 'send' ;)
<Astharot> hi
<T-Bone> Kamion: i wonder if one of the issues is to have 2.6.10
* ogra also has a list of about 15 ppl from irc that he could imagine MOTUs....
<T-Bone> Kamion: iirc, it's not considered as a very stable kernel for at least ia64 (and parisc, to some extent :P)
* T-Bone bbiab, dinning time
<Kamion> T-Gone: we can't have different kernels on different architectures though; we decided against that long ago
<Kamion> 2.6.10 will just have to be patched up
<Kamion> T-Gone: I see the elilo-installer bug, will fix
<lamont> seb128: you're not around are you?
<seb128> lamont: ?
<lamont> woot
<seb128> why ? :)
<lamont> seb128: I need to figure out how to tell at a glance if a change in build-deps is because of gnome 2.{8,10}, or not..
<lamont> is that easy?>
<HrdwrBoB> is it silly of me to ask that 2.4 gets removed from universe?
<HrdwrBoB> some people installed it and broke heir systems
<lamont> HrdwrBoB: gnome, or kernel?
<HrdwrBoB> kernel
<lamont> both should get nuked
<HrdwrBoB> but yeah
<HrdwrBoB> I've seen it twice now
<Kamion> T-Gone: fix in my tree, but alioth just went away; off to the pub now, will commit later
<seb128> lamont: in build-deps of what ?
<lamont> build-deps
<ogra> HrdwrBoB: when do you go for MOTU ?
<lamont> HrdwrBoB: maybe we need a 'twilightzone' component?
<lamont> for things leaving the universe, and all that... :-)
<ogra> hehe
<HrdwrBoB> haha :)
<HrdwrBoB> ogra: when I create a gpg key later this morning
<HrdwrBoB> unfortunately I have some real work to do today
<ogra> HrdwrBoB: YAY :)
<ogra> HrdwrBoB: i'm happy if you do it at all ;)
<amu> mdz: amd64 also ok, expect there's also no @ and |
<ogra> HrdwrBoB: ....as you are on top of my personal candidates list ;)
<HrdwrBoB> heh, woot
* HrdwrBoB feels special
<ogra> HrdwrBoB: you do awesome support... hard to ignore ;)
<HrdwrBoB> ah, unfortunately awesupport support is easy to ignore :)
<ogra> heh
<HrdwrBoB> then you end up having to install a full 32bit chroot of warty on a 64 bit system and pulling your hair out because you need to support ancient coldfusion and eventually finding it was a gcc problem and compiles fine with gcc 2.95
* mdz finally resyncs bugzilla components with main
<mako> mdz: HOT
<HrdwrBoB> cool
<lamont> mdz: diff analysis is going to be at least 2 passes...  doing gross/low-hanging fruit now, noting pending/etc for pass 2..
<T-Bone> Kamion: you're multiplicating constraints that are going to make things way harder ;P
<T-Bone> Kamion: it's a known issue that some kernel versions are troublesome on some archs and not on others...
<smurfix> mako: you saw my announcement oops?
<ajmitch> ogra: rounded up any more candidates?
<ogra> ajmitch: dholbach is packaging his first packages... and HrdwrBoB will join us too it seems :)
<ajmitch> ogra: good
<ogra> if i keep this rate we will have 365 MOTUs in a year ;)
<ajmitch> ogra: you should run packaging mentoring classes for the MOTUs ;)
<ajmitch> because I'd imagine you'll be spending a reasonable amoiunt of time reviewing packages
<ogra> ajmitch: considering it ;) 
<ajmitch> #debian-mentors & the accompanying lists are useful
<ogra> at the current rate my other ubuntu work falls a bit behind...which is not good....
<ajmitch> yep
<ogra> and unfortunately i still have a job to earn my life (6h meeting with the CTO today...)
<ajmitch> ouch
<ajmitch> I'll be starting a coding job soon, actually
<lamont> elmo: please sync aqsis
<ogra> lucky you
<lamont> aqsis_1.0.0-1 that is
<ajmitch> low pay, coding php.. not that lucky :)
<ajmitch> part-time, too
<HrdwrBoB> better than a poke in the eye witha  sharp stick
<ajmitch> yep
<ogra> ajmitch: since november i'm more a politician....then a technician....its boring and sad...but pays my rent :(
<mdz> lamont: also cleaning out some of the junk in the debian->ubuntu diff, I see
<lamont> mdz: yeah
<mdz> lamont: sync requests should go via email so that we have an audit trail
<lamont> mdz: ok
* lamont will finish the A's first.. :-)
<ajmitch> ogra: ouch
<ajmitch> there's a possibility of a sysadmin job coming up for me, which is one reason I want this selinux stuff working :)
<ogra> ajmitch: but php coding is a good start....better then mine was....(support for dialup users in '96)
<HrdwrBoB> sysadmin is highly overrated ;)
<ajmitch> HrdwrBoB: I know, but it'd pay the rent :)
<ogra> ajmitch: it gets boring after some time....but you get connections for better jobs :)
<ajmitch> heh
<HrdwrBoB> speaking of work, I'm off, later
<ogra> ciao
<ajmitch> bye
<ajmitch> yeah, I'll end up with a couple of part-time jobs, rather than one fulltime
<thully> what is this array 3.5 - I just burned the latest daily build of the live CD to test, is it the same
<ajmitch> dunno, I accidentally deleted my overnight download with rsync :)
<lamont> :n
<lamont> :q
<lamont> why does it do that, I wonder...
* ajmitch looks for a uni machine to download on 
<thully> I just checked - they are one and the same
<thully> BTW, array 3.5 looks awesome!  networking works good, and I wasn't bothered with too many questions
<sivang> when I have a working new package I did, debdiff would be best to do to provide a patch ?
<sivang> (It's a amodified source pkg)
* ogra reboots to array 3.5
<melazyboy2> Just wanted to make a package suggestion, Orpheus, it's a text-based console/terminal audio player available at konst.org.ua/orpheus
<ajmitch> melazyboy2: you could put it on the universe candidates wiki page
<ajmitch> is it packaged, and is it under a free license?
* ajmitch sees gpl
<melazyboy2> ajmitch: its not even on debian sid =/
<melazyboy2> ajmitch: Im just hoping it allows me to play in a true alsa enviroment, a feture that mp3blaster lacks
<ajmitch> melazyboy2: ok, I'll throw together a package
<melazyboy2> ajmitch: Awesome thanks, that guy also produces centericq, one of my alltime favorite utilities
<T-Bone> melazyboy2: how is it better than mp3blaster for instance?
<ajmitch> if it allows you to pass options to ogg123 & mpg123 to use alsa, then it should
<melazyboy2> T-Bone: Allows you to edit id3 tags, play cds and has the centericq interface, also exports playing files and has alot of other options
<melazyboy2> ajmitch: I can pass those options to ogg123, mp3blaster can't
<melazyboy2> aucutually now that i think about it, im not evne sure mp3blaster can play oggs at all =/
<melazyboy2> yes it can
<T-Bone> heh
<ajmitch> cdbs makes for nice, quick packaging at times
<ajmitch> wb ogra 
<ogra> :(
<ogra> array 3.5 still doesnt like my laptop
<ajmitch> melazyboy2: lots of compile warnings, no errors so far though
<ogra> mdz: 640x480 instead of 1280x800, still no pcmcia....
<amu> ogra: ppc & nv? 
<ajmitch> melazyboy2: deb built, now I need to write a manpage for it
<ogra> amu: amd64, nv
<amu> ogra: same here with i386 and nv 
<mdz> lamont: did you make that pcmcia-cs fix?
<mdz> ogra,amu: one of you should file a bug about it, if it is not already filed
<ogra> amu: i had expected the X error...but not the pcmcia....
<lamont> mdz: no - still waiting to understand where to crib from....
<ogra> mdz: i know, i wanted to file it last weekend (have already promised it to daniels)
<ajmitch> ogra: just about got a new deb for you :)
<amu> ogra: booting with a pluged in card, i've no trouble, i didnt checked removing pcmcia from a running sys ... nethertheless added to the testproto 
<lamont> Kamion: where does the install process decide whether or not to install pcmcia-cs?
<mdz> amu: the Warty live CD uses TZ=UTC, right?
<ogra> amu: /etc/init.d/pcmcia is missing.... even plugging out and in wont help
<mdz> the package is not installed
<mdz> (pcmcia-cs)
<ogra> mdz: yup... #5730
<amu> mdz: ...hmm hard to say :) sorry can't remember
<mdz> amu: it just seems strange, that people testing the hoary live CD seem to notice that it uses UTC
<mdz> but surely this is normal for a live CD
<ogra> i noticed that my panel clock was english....it said Thu ... but the time was right....
<amu> mdz: sounds logic for me too 
<amu> mdz: if you want i'll check it ... still have the old images  
<amu> sorry 24reconnect :) 
<ogra> amu: still t-online ?
<amu> ogra: no :) they offer just net with 1 ip, i need a small net  
<ajmitch> melazyboy2: ok, debs seems to be working..
<T-Bone> lamont: immediately after asking for ppp iirc ;)
<ogra> lamont: my pcmcia card is detected and the LEDs light up....the dhcp seems to work too... but once in the desktop its gone
<ogra> i'll reboot again soon and check on the console
<thully> The preset password for the user on the live CD for Hoary is ubuntu , correct?  Because when I click the update manager and enter my password to see the updates, nothing happens
<amu> ogra: same here booted, in german everthing is "english" 
* lamont goes to fetch kids from school
* T-Bone calls it a night, bye all
* ogra goes to check where pcmcia disappears...
<elmo> lamont: violates UVF - please mail mdz & jeff, cc me
<amu> mdz: TZ in warty was not UTC  
<mdz> amu: what was it?
<amu> KTZ="$(getbootparam tz 2>/dev/null)"
<amu> [ -f "/usr/share/zoneinfo/$KTZ" ]  && TZ="$KTZ"
<amu> if [ -f "/usr/share/zoneinfo/$TZ" ] ; then
<amu>    rm -f /etc/localtime
<amu>    cp "/usr/share/zoneinfo/$TZ" /etc/localtime
<amu> fi
<mdz> what is the tz parameter set to by default?
<amu> mdz: it was not set 
<amu> :-) 
<mdz> ...
<ogra> it disapperars exactly when it says "gonig down...."
<mdz> ogra: yes
<mdz> ogra: d-i has pcmcia support
<mdz> ogra: but there are no pcmcia packages installed in the desktop image
<ogra> yup....
<mdz> this is known
<mdz> Kamion: I don't suppose there is a shell getopt available in the d-i initrd?
<minghua> Hi, I am wondering how can I request a update for packages in Hoary universe.
<ogra> resolving the X bug will be a harder task....took me nearly a weekend to figure out the modeline i need... no way to get it working with hsync vrefresh..
<minghua> I am the debian maintainer of scim package, a input method package for CJK languages
<mdz> minghua: you can email ubuntu-devel@lists.ubuntu.com (remember to include the version number of the package)
<ogra> minghua: drop a mail to the ubuntu-devel list....
<minghua> I see, thanks mdz and ogra
<lamont> elmo: yeah - that's the plan
<abelli> smurfix: ding
<smurfix> dong ?
<abelli> smurfix: your mailman is in german,
<smurfix> bah. I'll teach it not to do that.
<abelli> other thing there will be opportunities for email forwarding with ubuntu-it.org
<abelli> ?
<smurfix> no problem.
<smurfix> abelli: OK, default should be en now
<abelli> smurfix: thank you very much... it wasn't really an issue, i didnt know if i did subscribe or not, since the email you sent me was in german too. :)
<smurfix> abelli: there was a paragraph in english though. ;-)
<abelli> the first line?!? =)
<mdz> lamont: hwclock still doesn't know how to access the hardware clock on amd64, apparently
<mdz> lamont: is there a patch out there for that?
<amu> mdz: build a new warty, extracted it, and checked eveything, TZ is untouched, localtime -> /usr/share/zoneinfo/UTC  
<lifeless> erm, has something been removed from evolution ? updated just now to latest hoary, and my ssh-tunnel options and functionality have gone byebye
<sm> it's certainly got issues.. filtering is broken
<ogra> lifeless: lucky you....mine dies with a floating point excepion
* sm wonders about evolution QA
* ogra wonders about novell
<lifeless> its functionality I depend heavily upon :[
<HrdwrBoB> sm: you're it
<ogra> me too...
<ogra> lifeless: morgue.ubuntu.com ... but downgrade is a pita
<sladen> mdz: hwclock should just be going through the kernel, I think
<ogra> sudo /etc/init.d/hwclockfirst.sh  start
<ogra>  * Setting the System Clock using the Hardware Clock as reference...     [ ok ] 
<ogra> hmm, no error i its not during bootup....
<ogra> s/i/if/
<sladen> ogra: I think it opens /dev/rtc, does that exist at that point
<sladen> mdz: is this live/amd64 or all amd64
<ogra> sladen: good point.... maybe a udev/ordering issue
<ogra> all
<ogra> it happens on every boot here
<sladen> mdz/ogra: I can believe that udev doesn't bother since, it's not as though it can find it on the PCI bus :)
<amu> ogra: you still online with a liveCD ? 
<ogra> amu: i never was... no pcmcia, no net :/
<amu> somebody else, i need to know which version of update-notifier is installed
* ogra tries something out...
<mdz> sladen: this happened to be live/amd64
<mdz> sladen: yes, it goes through the kernel, but there are several ways to do that; it differs from one architecture to the next
<mdz> I would expect that on a modern port like amd64 it would use /dev/rtc
<mdz> amu: /casper/filesystem.manifest
<mdz> amu: has a list of versions of all packages
<mdz> lamont: does the daily d-i build happen in time for the daily live CD build?
<amu> mdz: thx
<amu> mdz: #5942, guess he has not enough ram? 
<mdz> amu: 5942 is a typo
#ubuntu-devel 2005-02-08
<lifeless> jdub: ping
<mdz> wow, the extra seed is very small
<mdz> daniels: ing
<mdz> ping
<amu> mdz: err 5943
<ogra> hmm, not even moving it to S26 (after rtc is loaded) helps....
<mdz> amu: yes
<mdz> build-essential is huge
<amu> mdz: thx
<mdz> amu: he can try booting with a larger ramdisk_size
<mdz> probably we should increase the default even
<ogra> gah evo is broken again....
<jdub> lifeless: pong
<lifeless> jdub: you mentioned a new imap implementation for evo. It looks like it doesn't support the external-command facility that I use to access my email.. and that the older imap code has been removed from evo.
* ogra kicks evolution with a long hard stick
<lifeless> jdub: so I'm rather fucked on email :[
<amu> mdz: i think less it's better, i'll work a little with the live tomorrow and watch the ramuseage very carefull    
<jdub> erm
<jdub> i don't think that's true
<jdub> latest evo in hoary?
<jdub> elmo: ping
<lifeless> yes
<lifeless> theres only one Imap type now
<lifeless> and it has the description the new code had when I glanced at it @ your house the other week
<lifeless> 'IMAPv4rev1'
<carlos> lifeless: yes, you need to reconfigure your imap settings
<mdz> ogra: I noticed recently that there is a UniverseCandidates page with packages that people would like to see added to universe
<carlos> lifeless: I think you should come back to previous version if you don't want to fight with evolution
* carlos has a list of bugs to file
<ogra> mdz: i'll link to it from the MOTU page
<carlos> the "reply to list" is not working anymore
<ogra> gah
<carlos> the CC field is erased while you write the email
<mdz> jbailey: there is already one NFS server howto in the wiki; it would be better to improve that one
<ogra> on amddd64 its segfaulting totally
<ogra> evo that is....
<carlos> and some others 
<lifeless> carlos: the options to reconfigure *are missing*.
<jbailey> mdz: Ah?  Okay. I thought I search for it.  Will combine the two.
<carlos> lifeless: really?
<carlos> didn't saw it
<carlos> let me check
<lifeless> carlos: really. I use ssh tunneled iMAP.
<elmo> jdub: ?
<jbailey> lifeless: The latest evo sucks rocks in a few different ways.  You might be better to pin the old one.
<carlos> lifeless: right, that option is not there anymore
<mdz> jdub: what's up with gnome-app-installer
<lifeless> jbailey: yeah, sounds like. now to figure out how to get it back easily :[
<jbailey> lifeless: Your apt cache?
<jdub> elmo: could you check what's up with that second include on planet ubuntu?
<carlos> lifeless: dpkg -i /var/cache/... of evo && dependencies, not too easy but should work
<lifeless> jbailey: perhaps ;|
<elmo> jdub: there is no entropy.inc ?
<jdub> mdz: getting some fixes from ross, and i've pretty much got the .desktop sucker going
<elmo> did you want me to run planet for config/entropy too?
<elmo> I tried but it spasssed out hideously
<jdub> :-)
<jdub> yes, thanks
<jdub> it would have spewed the same way the others did :)
<mdz> jdub: are the HUGE FONTS GOING TO STAY?
<mdz> jdub: is sodipodi (universe) just there as a test case?
<elmo> jdub: nah, it was much worse before, but you're right, it's just doing that now
<lifeless> carlos: so, is the ssh option going to come back? or should I file a bug to prod that
<elmo> jdub: now it's just empty?
<carlos> lifeless: no idea, but I think you should file a bug about it, don't think it depends on imapv4, seems like they forgot to implement it 
<lifeless> ubuntu.com or upstream ?
<ogra> mdz: i added the link, but UniverseCandidates content is not really convincing....
<carlos> lifeless: ask seb128 about it, don't know how that is handled in Ubuntu/GNOME, I suppose you could file a bug in bugzilla.ximian.com and send the link to seb so you save time for him
<lifeless> seb128: ^^^^^
<jdub> mdz: yes and yes. :)
<jdub> elmo: yeah, ok
<seb128> carlos, lifeless: what's the issue ?
<carlos> seb128: evolution bugs not related to Ubuntu packages
<lifeless> seb128: ssh tunnel support (external connection commands) for imap is gone in the latst evo.
<seb128> jdub: dude, new gamin require, I'm not sure (not rebooted yet), but apparently the current one doesn't handle inotify 0.18
<lifeless> seb128: should I file a bug, and if so in bug..u.c or upstream ?
<carlos> seb128: should be filed directly at bugzilla.ximian.com or to ubuntu's bugzilla and you will care about them?
<seb128> lifeless: better to go upstream
<jdub> seb128: yeah, i know; fabbione uploaded while i was asleep :-)
<jdub> seb128: doing it first priority this morning
<seb128> jdub: ah ah
<seb128> jdub: you sleep too much dude :p
<lifeless> seb128: do you know their plans about the ssh support ?
<jdub> all a matter of timezone perspective. ;)
<seb128> no idea
<jdub> dear thom, ROCK!, love jdub
<lifeless> oh great. 
<seb128> firefox user ? :)
<lifeless> to login to bug.x.com, I need them to email the password to me.
<lifeless> guess what I can't use right now ?!
<jdub> lifeless: your legs? you can't walk to the phone! NOOOOO!
<lifeless> ')
* sm giggles
<lifeless> iz biological bug
* ogra has evo working again.....
* ogra hugs the morgue
<seb128> what was the issue ?
<tseng> jdub: tomboy has arrived!
<tseng> jdub: let me upload the goods for you.
<ogra> seb128: https://bugzilla.ubuntu.com/show_bug.cgi?id=5870
<seb128> oh, it was assigned to nobody
<seb128> jdub: they changed my state of packaging machine :p "<elijah> seb128: has 548 bugs closed already this month; he's a bug closing machine"
<ogra> yeah
<ogra> they are absolutely right :)
<tseng> jdub: http://getsweaaa.com/~tseng/tomboy/
<jdub> tseng: working on other stuff just atm, but will load up the page for a bit later :)
<tseng> jdub: wonderful, ta
<tseng> jdub: when you get to that, refresh it if you dont mind.. i have a few ?s as well.
<carlos> sladen: hi
<carlos> sladen: around?
<sladen> carlos: vagely
<bluefoxicy> huh?
<bluefoxicy> one of the goals of hoary (opportunistic low-prio) is NX?
<bluefoxicy> I thought there weren't going to be added security features in Hoary (PaX[NX + ASLR] , GrSec hardened kernels, SSP, PIE, etc)?  Is this a different definition of NX?
<bluefoxicy> I like the hoary goals I think. . .
<tseng> bluefoxicy: look at where that goal is listed
<tseng> its pretty low on the list iirc
<tseng> and goals are goals, not hard requirements
<mdz> bluefoxicy: http://www.nomachine.com/
<mdz> bluefoxicy: that NX
<ajmitch> bluefoxicy: it's a great NX, too
<ajmitch> however Mithrandir said he was wanting to rewrite the freenx server
<bluefoxicy> tseng:  I know
<bluefoxicy> I'm just curious
<bluefoxicy> ahh
<bluefoxicy> mdz, ajmitch:  Ok, that's not what I was thinking of then.
<ajmitch> yeah :)
<ajmitch> the other NX will take a bit of work with PaX & all
<bluefoxicy> I'm still a bit taken back that simple things like grsecurity linking restrictions (which are supposed to dead-stop the tmpfile races in USN 3-1, 5-1, 6-1, 4-1, 13-1, 15-1, 16-1, 24-1, 43-1, 49-1, 51-1) aren't going in, but eh.  pitti said (Hoary+1) so :)
<tseng> bluefoxicy: i wish you would quit trolling people with your pumped up statistics
<daniels> mdz: pong
<tseng> bluefoxicy: esp. on lkml
<bluefoxicy> tseng:  I don't pump anything up, and I'm not trolling, just feeling around.
<mdz> daniels: http://people.ubuntulinux.org/~cjwatson/germinate-hoary-output/extra.seed
<mdz> daniels: looks like a bunch of lrm stuff is not seeded
<bluefoxicy> tseng:  I have nothing better to do anyway
<daniels> mdz: ok, will take care of it along the same lines as the old lrm stuff was
<bluefoxicy> tseng:  http://rafb.net/paste/results/tZ5Jp878.html Aside from fool around with my kernel
<thully> Just installed from the latest daily build - Hoary sure has improved, and the clock issue seems resolved
<thully> However, I have a few questions about the default behavior in the installer
<thully> First of all, it seems a little strange that we ask 2 questions in stage 2 - could these be eliminated?
<tseng> thully: thats being worked on.
<tritium> can't quite get ppc livecd to boot using qemu-system-ppc on i686 (invalid opcode)
<mdz> tritium: works for me on a real ppc
<thully> Also, I like how networking was handled on the live CD, but not on the install CD - any chance the install CD debian-installer could be changed?
<tritium> mdz, using qemu?
<tseng> thully: he qualified "real"
<mdz> tritium: no, on an actual powerpc machine
<thully> tseng - ?
<mdz> tritium: so probably it is a bug in qemu
<tritium> mdz, I'm sure.  Yeah, I tried the live CD earlier.  I reported that bug for daniels re: screen resolution
<tritium> I was using G3 earlier
<mdz> ah, right
<thully> I really liked how the network detection picked up wi-fi without asking me - after booting I was on the wireless network! (only one other live distro has done that for me - Kanotix)
<thully> Any chance this no-question network configuration could also be done in the install CD?
<bluefoxicy> <mdz> tritium: works for me on a real ppc <tritium> mdz, using qemu?
* bluefoxicy snickers
<mdz> bluefoxicy: no need for that
<bluefoxicy> mdz:  I think he probably missed "real," but the exchange is funny
<tritium> bluefoxicy, well, of course it works when not using qemu ;)
<thully> is the loopback interface appearing as a network interface in the system tray a known bug?  If not, i'll report it
<lexhider> daniels: can I ask you about bug 5917.
<jdub> seb128: rebooting to test new inotify and gamin :)
<seb128> jdub: rock :)
<daniels> lexhider: sure
<lexhider> you said it may be monitor hardware bug, I've been using this monitor with linux for 3 years with no problems. Is it still possible that this is the problem?
<daniels> lexhider: i suppose ... it certainly seems very, very strange
<jdub> seb128: ah, crap. :)
<tritium> lexhider, what architecture are you using?
<seb128> jdub: doesn't work ? :(
<tritium> that bug is similar to my bug today (5490) in PPC for the LiveCD
<tritium> 5940, that is
<jdub> seb128: got gam_server processes running, dying, running, dying, six at one time...
<jdub> ;-)
<seb128> utch
<lexhider> i386
<lexhider> adm
<lexhider> when you say "hardware bug", do you mean a problem with this specific monitor or do you mean a problem with this particular monitor model [viewsonic e70 by the way] ?
<bluefoxicy> wtf
* bluefoxicy sigh.
<daniels> bluefoxicy: i mean, for whatever reason, when it first boots, the monitor is totally unresponsive to probes for its sync ranges and resolutions.  i do not know how widespread this is; you'll have to forgive me for not being a connisseur of viewsonic monitosrs.
<tritium> lexhider, I think you should add HorizSync and VertRefresh to your xorg.conf.  Your monitor probably doens't report edid
<bluefoxicy> daniels:  uh?
<tritium> doesn't, that is
<daniels> tritium: it does, just not all the time
<tritium> okay
<lexhider> 1) I haven't been able to reboot to test if it happens with monitor off because I'm on dialup and it doesn't happen every reboot.
<lexhider> I had no problems with warty with same monitor if that is relevant.
<thully> I was just thinking about a few things, and I was wondering - how was the decision made on what to include on the Hoary live CD
<jdub> the livecd, atm, is the default desktop install
<thully> why can't everything on the install CD be included?
<jdub> well, that's basically what the desktop install is
<jdub> the install cd happens to contain the ship seed
<daniels> lexhider: yeah, warty does things a bit different
<jdub> the live cd is desktop seed + live seed (which we might not be using yet)
<jdub> the install cd is desktop seed + ship seed (which is not installed by default)
<thully> yes - but there is more on the install CD that isn't installed by default
<jdub> that's the ship seed
<jdub> some of it is just inappropriate
<lexhider> daniels: I'll try some rebooting and other things and be back later.
<thully> OK - i just wondered because I use some of the stuff not installed by default and it would be nice to have in an emergency (using the live cd)
<jdub> if they make sense, we can put them in live seed
<thully> they probably don't - I was talking about thunderbird, compilers, and kernel headers specifically - don't know how much space these would take up compressed on the live cd, though
<mdz> we could very well end up adding build-essential to the live CD, it's not clear yet
<mdz> if you have real use cases to contribute, that helps
<thully> when you have to use your winmodem in an emergency - keep the files on a floppy or usb key and build them
<tritium> on the other hand, in the case of an emergency, be prepared (have them pre-built)
<thully> what if you're on another machine you don't usually use?
* jdub thinks build-essential on the livecd would be cool
<thully> also, compilers could be useful for building anything special needed for recovery not in Ubuntu, and for computer science classes :)
<thully> thunderbird - well, I prefer thunderbird over evolution and that's the first thing I install after installing Ubuntu :)
<tritium> each user has their own needs, though - mine would be tetex
<thully> someone should keep an ordered list of package requests for the live CD and add these on a space-permitting basis
<thully> may be a good idea for install CD, also (adding additional packages based on what people want on a space-available basis)
<dholbach> re
<tseng> wb.
<ajmitch> hi
<dholbach> hai tseng :-)
<dholbach> wow, this place is really crowded :-)
<ajmitch> yeah, it's getting busier
<ajmitch> I heard ogra lured you to apply to be a MOTU?
<dholbach> ajmitch: he didnt have much to do to lure me :-)
<ajmitch> :)
<jdodson> hey daniels you around?
<ajmitch> dholbach: planning to maintain a certain set of packages?
<daniels> jdodson: sup
<jdodson> daniels: nada, well i checked out the tickets like you mentioned, found a cheaper one for 1,200 usd.
<dholbach> ajmitch: i'd love to be helping out at whatever part there's a need 
<daniels> jdodson: nice one
<jdodson> daniels: yeah, thanks for the heads up.
<daniels> any time :)
<jdodson> daniels: i think its obvious my wife usually does the trip arrangements:)
<daniels> ah well, worked out for the best anyway
<dholbach> ajmitch: but a first thing i really wanted to do was packaging more recent c++ stuff and cleaning stuff up together with debian people (like libg*mm-packages)
<jdodson> daniels: agreed.
<ajmitch> dholbach: we'll just have to ensure that packaging quality is kept at a high level
<ajmitch> for all the universe packages that are touched
<dholbach> ajmitch: of course
<HrdwrBoB> yes
<jdub> dholbach: rock, *mm action :)
<ajmitch> yes, apparantly people still use c++ these days :)
<mdz> lamont: Kamion answered your pcmcia-cs question in Bugzilla already (#5730)
<dholbach> jdub: we'll have to knock some comprehension into some debian people, but *mm absolutely rocks ;-)
<ajmitch> how bad is the situation in debian?
<daniels> shouldn't we have some part of hoary-seeds cachrevved or wahtever?
<daniels> it's taking like a hojillion years to get it
<dholbach> ajmitch: i wrote some bug reports with  tested  and  compiled  new upstream versions on my box, but there was no measureable reaction
<dholbach> ajmitch: the situation could be worse, since most developers tend to compile their own libg*mm packages, but that's not how i'd want it to be
<ajmitch> if there are packages around, nobody should have to compile their own
<ajmitch> are they badly packaged, or just out of date?
<dholbach> ajmitch: the latter
<ajmitch> not so bad then
<dholbach> damn, i'll have to get up in 4 hours
<ajmitch> heh
<ajmitch> I'll be gone for the weekend, luckily
<dholbach> and i shouldnt have been drinking that much
<dholbach> ................. :-)
<daniels> hm
<ajmitch> and I've recently been offered a part-time job, so I'll most likely be able to get to .au in april/may :)
<dholbach> ajmitch: lucky you *congrats!*
<daniels> mdz: afaict all my unseeded stuff just belongs in supported -- do you disagree with that assessment?
<elmo> boggle, we don't support libapache2-svn? meh
<dholbach> alright... sleep tight everyone - i'm off to bed :-)
<ajmitch> night
<dholbach> night ajmitch
<mdz> daniels: I suppose
<mdz> daniels: xfree86?
<mdz> daniels: isn't fglrx-control the awful config program?
<daniels> mdz: i'm much happier not needing to support xfree86* :)
<daniels> mdz: well, yeah, xfree86-driver-fglrx would need to be in universe, given that it depends xfree86, which is in universe
<daniels> mdz: yah, it's some qt horror
<mdz> daniels: those do not sound like they belong in supported
<mdz> nothing with 'xfree86' or 'horror' in it, I'd say
<jdub> "horror" and "supported" are not compatible
<daniels> so what do I do to get germinate to stfu about them?
<jdub> uploading dnotify-only gamin due to current inotify support being b0rk.
<tseng> =/
<jdub> yeah
<jdub> it'll sort out in the next few days though
<jdub> meanwhile
<jdub> BEAGLE
<jdub> very nearly in hoary :)
<ajmitch> great
<ajmitch> universe?
<jdub> yeah
<jdub> tonight or tomorrow
<ajmitch> sweet
<ajmitch> might give me an excuse to put hoary on the laptop
<jdub> 'might'? :)
<ajmitch> I've been tempted
<ajmitch> it has sid currently 
<tritium> jdub, what kind of dependencies does it have?  lots of mono packages?
<jdub> tritium: yes
<ajmitch> hopefully not too much that's mono-specific
<jdub> it's way mono
<jdub> the protocols don't require you to write stuff in mono
<jdub> but the whole infrastructure of beagle is way mono
<ajmitch> as in, I hope i can get it working on pnet
<ajmitch> rather than just mono :)
<jdub> ew.
<tseng> we still need evo-sharp
<tseng> and gsf-sharp, whatever that is
<jdub> tseng: there are non-required depends
<jdub> those two are the most important
<tseng> well, it wouldnt make sense to send it out w/o evo support
<jdub> beagle can also use wv (wordview, not wvstreams) 1.0, but can't use 2
<jdub> tseng: yes, see log from last night :)
<tritium> the demo I saw of beagle was impressive.  made me think twice about it
<jdub> we have the *required* depends, but not the crucial optional depends. whiprush and some of the arslinux crew were going to work on those.
<jdub> tritium: you had to think twice?
<whiprush> this thunderbird one appears to not work.
<tritium> jdub, well, about installing the mono stuff just for beagle
<sivang> morning all
* lamont wonders why his sound quit working
<lamont> I didn't even upgrade this time. :-)
* lamont makes an early night of it, wondering if he's coming down with something or something.
<jdub> tritium: 'just' for beagle is far more convincing than 'just' for tomboy, muine, etc.
<jdub> tritium: beagle really does change how you use your computer
<jdub> night lamont
<tritium> jdub, after seeing it's capabilities in the demo, I'll agree
<tritium> with that statement
<whiprush> It'd be neat if you could put a field in your panel ala the contact search one and shortcut right into it.
<jdub> whiprush: ah, see auric notes on the gnome wiki
<jdub> whiprush: also F12 kicks best and focuses the search entry :)
<whiprush> yeah that's what I was alluding to.
<whiprush> yeah, it's a killer combo with f11 for tomboy.
<robertj> jdub: did you see that inotify has made it's way into Morton's kernel?
<jdub> yeah :)
<jdub> rocking!
<robertj> jdub: are the inotify extensions still hot to the tuch or are they pretty steadyfast?
<jdub> inotify itself works nicely
<jdub> beagle uses inotify directly
<jdub> gamin uses inotify, but the support for 0.18 is b0rk
<robertj> so gamin is a stipped down userspace fam that is another consumer of inotify?
<jdub> pretty much, yeah :)
* robertj puts on his hat and pulls out his corn cob pipe
<jdub> though s/userspace/run-by-user/
<jdub> it is binary compatible with the useful bits of fam, too
<jdub> so you don't need to change software to work with it
<robertj> is the idea to transition beagle over to gamin?
<robertj> instead of playing directly with inotify
<jdub> no
<jdub> beagle is very demanding in its use of inotify
<schweeb> heh, compile it with the mozilla backend, and it's very demanding with your memory too
<jdub> beagle definitely has memory problems atm :)
<robertj> so where does gamin fit into beagle, nowhere?
<jdub> robertj: nowhere
<robertj> so gamin is just like a "eh, well we might as well package it, something might need it"
<schweeb> nautilus uses gamin for file notifications
<robertj> ahh
<jdub> no, gamin replaces fam, which is used by many things
<jdub> nautilus, gnome-vfs, kde, etc.
<robertj> clamav
<whiprush> so, for example, as you copy a large file you get the nifty "xx MB" thing updated in real time under the icon or whatever."
* jdub chuckles at whiprush's quote marks
<whiprush> :p
<whiprush> also, gamin doesn't tie up cdroms and usb keys like fam does. 
<jdub> gamin does
<schweeb> jdub: watch how passionate he is about this stuff IRL, you'll chuckle at him then too
<jdub> if it uses the dnotify backend (which is all fam could use)
<jdub> with inotify, it doesn't
<whiprush> well, not counting your last upload, heh.
<jdub> yeah. grr. ;)
* robertj goes down the dep checklist to determine how far away from beagle he is
<whiprush> I see thom got in some ff integration patches. woo.
<jdub> robertj: if you're using hoary, you have the whole list
<robertj> is libgmime the right version?
<schweeb> jdub: thanks for that btw <3
<whiprush> yep
<jdub> robertj: yeah
<robertj> jdub: are beagle and the mono hooks packaged anywhere?
<jdub> last night i wrote a todo item to update the beagle wiki page in the morning
<jdub> when i got up, someone had already done it ;)
<jdub> robertj: hooks?
<robertj> jdub: Evolution-Sharp, Gsf-Sharp
<jdub> no, the optional stuff is not packaged
<jdub> whiprush: did you guys start on those?
<whiprush> looked at some of them. 
<robertj> Neither is beagle?
<jdub> beagle itself isn't quite - i'll finish and upload it tonight or tomorrow
<whiprush> what exactly do you need, a list of what you want as depends and what you want as recommends instead right?
<schweeb> robertj: as long as you have all the depends, it takes like 3 mins to compile on a slow system
<jdub> whiprush: i thought you guys wanted to package them?
<robertj> schweep: just checking
<whiprush> oh oh. we must have misunderstood each other then. I thought you just wanted us to try each of them out an gauge how well they worked.
<jdub> ahr
<whiprush> I can do some though, keeping in mind I'm brand new at this ... hmm, perhaps I need to bug tseng/ogra more.
<tseng> whiprush: whats that?
<whiprush> packaging in general.
<tseng> ok.
<jdub> mono stuff is slightly tougher than normal stuff
<whiprush> yeah I noticed
<tseng> i still need to come up with a tomboy patch to install to debian standard locations i believ
<whiprush> hopefully I'll find a friendly DD at linuxworld t give me some pointers
<robertj> schweeb: my clock is ticking on the 3 min thin ;)
<schweeb> robertj: how fast is your system?  mine's a 1.7Ghz laptop w/ 640M RAM
<robertj> 2.8 celeron 512
<robertj> eMachine is rockin ;)
<robertj> $300 last Oct
<schweeb> ugh, emachine
<schweeb> that's like saying "Packard Bell" back in the day
<robertj> Maybe the AMD 64 will be $300 this October
<robertj> My parents bought a PB as our first computer
<robertj> we upgraded the ram from 4 to 8 megs and suffered a 300% speed decrease until we could afford a bios upgrade a few months later
<robertj> btw, where does dbus-sharp come from (yes I did the export stuff)
<whiprush> libdbus-cil
<ajmitch> jdub: maybe I should dive in & help with mono packaging stuff as well? who's currently doing it?
<robertj> thanks whip
<jdub> ajmitch: no one in particular, daniels and i did dbus and gmime
<jdub> ajmitch: just to have the base depends
<ajmitch> right
<ajmitch> so it's a matter of whoever can get the bits together
<jdub> yeah
<tseng> tomboy as an applet rocks
<ajmitch> are you using released or cvs/svn snapshots of stuff/
<schweeb> tseng: if only I could run applets in fluxbox w/o gnome panels ;_;
<tseng> dbus-sharp 0.23
<tseng> hopefully done cvs snapshotting that for awhile
<daniels> tseng: interestingly, they're talking about doing 0.24 like, this week
<tseng> daniels: i heard its getting chilly in hell.
<ajmitch> unfortunately I'm visiting parents for weekend, not much chance of doing ubuntu stuff there
* ajmitch throws a couple of warty install cds in the bag
<schweeb> ajmitch: heh, livecd!
<daniels> elmo: could you please update linux-headers-* in concordia's hoary chroot?
<elmo> daniels: done
<daniels> elmo: thanks
<robertj> anyone have the link to gnome's discussion of the Desktop menu
<netdur> ubuntu livecd is first livecd for amd64 and ppc?
<robertj> hrmm, beagle did build and install fine but best is unhappy
<robertj> libgecko problem perhaps?
<jdub> how unhappy?
<schweeb> how is it unhappy?
<jdub> error about dbus in the best output?
<schweeb> doesn't it need a dbus-dev pkg or something
<jdub> netdur: don't think so, but it's the first really slick one ;)
* schweeb had this problem earlier
<jdub> schweeb: yeah
<robertj> let me check the logs
<schweeb> be sure dbus-1-dev is installed
<schweeb> and dbus-glib-1-dev
<robertj> logs pretty spammy right now with the initial crawl
<robertj> doesn't seem to spew anything else when best runs
<robertj> (best:20339): GLib-GObject-WARNING **: specified instance size for type `GtkMozEmbed' is smaller than the parent type's `GtkBin' instance size
<jdub> oh man
<jdub> we should so get pyphany in
<schweeb> pyphany?
<schweeb> sounds... python-ish
<schweeb> heh
<robertj> or maybe gnome web browserish
<robertj> It must be an Epiphany rewrite in python
<jdub> python + epiphany
<jdub> extensions silly, not a rewrite!
<jdub> ouch
<schweeb> ah, python epiphany binding
<robertj> hehe
<robertj> an un-googleable name ;)
<schweeb> not raelly...
<schweeb> worked for me
<jdub> it's very new
<robertj> hrmm
<schweeb> http://mail.gnome.org/archives/gnome-announce-list/2005-January/msg00064.html
<sivang> ogra: morning
<sivang> jdub: what does it allow you to do?
<jdub> write ephy extensions in python
<sivang> jdub: eh , so we can turn it into a pyfox? ;-)
<JanC> heh, sounds fun  :)
<jdub> elmo: planet update please :)
<elmo> jdub: done
<jdub> thanks!
<fabbione> morning
<pitti> Morning folks!
<pitti> bah, my main internet access is dead again... (modem now)
<pitti> anything urgent?
<pitti> mdz: here?
<Treenaks> hm, should beagled eat all of my memory?
<mdz> pitti: yes
<pitti> mdz: is it a known bug that the array 3.5 live cd does not set locale, timezone and keyboard layout?
<pitti> mdz: timezone was already reported on u-devel
<mdz> pitti: it cannot set the time zone, and never will
<mdz> no live CD does
<pitti> oka
<pitti> y
<mdz> it does set the locale and keyboard layout
<pitti> but at least locale and keyboard layout should work
<mdz> at least, it does for me
<pitti> hmm, I had an English locale (could also have been C) and an English keyboard layout
<mdz> what is in /etc/environment?
<pitti> mdz: this file does not exist
<mdz> odd
<pitti> so if it _should_ do it, then I can debug this further
<pitti> mdz: just asking whether it was not yet implemented... :-)
<pitti> Morning seb128!
<seb128> hello
<seb128> hey pitti :)
<YokoZar> Hello, I am currently the Debian packager for the Wine project.  The "official" Debian maintainer hasn't been updating the packages and refuses to turn them over to me, so we've setup our own apt repository at winehq.org
<YokoZar> The packages have been tested a lot, and are also in the Ubuntu backports project working fine.  I'm wondering if they could become the ones that sit on Ubuntu's repository, rather than the (very old) Debian unstable ones.
<YokoZar> So, what's involved in getting this done?
<pitti> YokoZar: since wine is currently in universe, the obstacles for maintaining it yourself are not that high :-)
<YokoZar> Well what's involved in getting it into hoary universe then?
<pitti> YokoZar: I think a good first step would be to announce your repo on ubuntu-devel@lists.ubuntu.com
<pitti> YokoZar: then we can find somebody to upload
<YokoZar> There's another issue: due to the nature of Wine, we REALLY can't support ppc or amd64 arches very well
<pitti> YokoZar: and if you want to maintain them in Ubuntu, you can apply for becoming an universe maintainer
<YokoZar> I suppose I could do that
<pitti> YokoZar: that's excusable :-)
<pitti> YokoZar: well, what means "very well"?
<pitti> YokoZar: is't the package Arch: i386 only?
<YokoZar> It's actually possible to get some use out of wine on non i386 arch's
<YokoZar> You can use winelib to compile windows apps natively
<YokoZar> I'm working on compiling Miranda IM with winelib at the moment
<pitti> ah, but don't execute readymade exe files
<YokoZar> In theory I could make it into a package that depends on Wine and could run on all arches
<YokoZar> Which would be a nifty way of porting Miranda to ppc
<YokoZar> All I need to do is learn some makefile goodness and I'll be set
<YokoZar> Wine is getting very usable now.  The Ubuntu packages I made let you click and run .exe files, and they can even put icons on the desktop.  We're close to putting the start menu in the applications window too (Crossover Office already does this).
<pitti> YokoZar: if your packages are better, please announce them on u-devel; also introduce yourself shortly if you want to apply as maintainer
<pitti> YokoZar: sounds cool!
<pitti> YokoZar: I tried the current wine once (because now I have a windows app I need to use), and I could not get it running
<YokoZar> My packages?
<syn-ack> YokoZar: sounds like you're starting to be more like codeweavers and how they do things. Im starting to get VERY interested... :)
<pitti> YokoZar: getting maintainer status is much easier for Ubuntu/universe than for Debian :-)
<YokoZar> Yeah.  Removing a debian maintainer is also impossible
<YokoZar> I don't mean to sound conspiratorial, but the current Debian maintainer works for transgaming and has a real conflict of interest in making a timely release of a usable package
<pitti> YokoZar: http://www.ubuntulinux.org/wiki/NewMaintainerProcessDraft
<YokoZar> syn-ack: There's a program called Winetools that I'm packaging up now.  It's got a one-click setup and lets you install some apps that help wine work
<YokoZar> It depends on nonfree Microsoft software though (it'll be in the contrib section), since it can be used to install internet explorer and such
<syn-ack> YokoZar: good. Im thinking of uninstalling Crossover now.
<Kamion> click and run .exe files> didn't we fix that in Debian years ago?
<Kamion> maybe not ... IIRC Ove not adding the packaging change
<YokoZar> Yeah there's been a mime type for debian for a bit
<ogra> morning everyody....
<Kamion> YokoZar: not a mime type, I meant the update-binfmts thing
<ogra> gah.... first words this day and already a typo....
<pitti> Hi ogra
<syn-ack> YokoZar: You guys working on an ActiveX plugin? I hope not.
<YokoZar> Don't remove crossover just yet if you play steam.  It's a bit broken in winehq.  But...we're close to getting DirectX 9 working (There are screenshots of Pirates! running) which means it's only a couple months before HL2 works
<haggai> hi ogra 
<mdz> YokoZar: are you interested in maintaining the packages in Debian on an ongoing basis?
<YokoZar> syn-ack: not to my knowledge, no.  But it is quite possible that you'll be able to play HL2 on Hoary.  I'd give the odds at about 50:50, depending on when hoary gets frozen.
<Kamion> hm, I should see if winehq manages Black and White, I had PAIN trying to build winex/cedega/whatever-it's-called-this-week
<mdz> YokoZar: what is your name?
<YokoZar> mdz: I'd maintain them for Debian and Ubuntu, yeah.  But I can't submit them for Debian, unless you want to NMU them :)
<YokoZar> mdz: Scott Ritchie
* ogra smells a new MOTU
<ogra> :-D
* haggai too :)
<ogra> is lamont already awake ?
<mdz> YokoZar: as you may or may not already know, our maintainership model is quite different from Debian's, and one of the goals is to avoid having an inactive maintainer block others' work
<dholbach> hai everyone
<YokoZar> mdz: Yeah, I figured that.  If you're referring to the winetools package (which isn't maintained in Debian), it depends on a version of wine later than the latest debian release
<mdz> YokoZar: you said that the Debian maintainer won't turn the packages over to you; is there a chance that the two of you could collaborate rather than one of you having exclusive ownership?
<ogra> moin dholbach
<dholbach> hellas ogra! :-)
<YokoZar> mdz: He asked for a comaintainer a while ago.  I volunteered, offered up a new package version, he said "I'll hold onto the package for now" and then never released another update
<haggai> YokoZar: how long ago?
<amu> moins  
<YokoZar> Well last update he uploaded was the september release, which is ancient in Wine terms.
<ogra> hi amu
<syn-ack> mdz: I like the sound of that. I do find that there is a lot of stale mantainership and politics that I cant stand in Debian. I like this because its more like because there seems to be more of a part of the community. Something more than just...... Stale.
<YokoZar> I got an aim message from a user just thanking me for writing the package and saying how cool it was that he could get an icon on the desktop.  He used it to install partypoker and then won 800 dollars.  It was kind of flattering, heh.
<mdz> YokoZar: where can I find your packages currently?
<YokoZar> mdz: http://www.winehq.org/  - click the downloads page
<YokoZar> And then either the debian or ubuntu link
<amu> hi ogra
<YokoZar> I wrote the text on that page too (I've been slowly rewriting Wine's documentation - I've already redone the introduction to the User Guide)
<mdz> hmm, wine.sourceforge.net isn't answering me
<haggai> it's working for me
<ogra> here too
<YokoZar> sf.net is erratic
<mdz> finally got through
<YokoZar> Wine is kind of in a transitory stage at the moment
<YokoZar> We're finishing up the winecfg tool (a graphical configure thing) and eliminating the config file, moving stuff into the registry
<YokoZar> But at the moment it doesn't write any changes.  However, wine will create a default setup when you run it, which should work for a lot of stuff.  Winetools will create an even better setup.
<haggai> +  * Added dummy packages libwine (which depends on wine) and libwine-dev (which
<haggai> +    depends on wine-dev) in order to ease upgrade from older versions.
<haggai> YokoZar: you should be able to use provides/conflicts/replaces to avoid more packages
<YokoZar> haggai: I can't for that though, because apt is buggy
<haggai> YokoZar: in what way?
<YokoZar> Two ways
<YokoZar> The first is that it will output the old dependencies (this is an old bug in apt), saying that it recommends the (obsolete) winesetup
<mdz> YokoZar: your packages look quite different from the Debian ones (incompatible, even)
<mdz> e.g., you seem to have it split up differently
<mdz> is this an explicit choice?
<YokoZar> The other thing is that if you provide a wine that replaces/conflicts libwine apt will read the old wine depends file and conclude that you want to remove a dependency, and refuse to install
<YokoZar> I set it up differently for a few reasons.  The first is that everything in wine is needed - the seperation of wine and libwine was arbitrary and breaking stuff
<YokoZar> We had to ask people coming into IRC for help "Are you a debian user?  Yes?  Install from source then or get all the packages"
<YokoZar> You need every wine binary to run even programs compiled with winelib (like I'm doing for Miranda) - there really is no point to splitting it.
<YokoZar> Furthermore all the old libwine-* packages are obsolete, as Wine will automagically detect what sound server and such to use
<haggai> YokoZar: do programs ever link against libraries in winelibs?  The seperation is partly for backwards compatibility
<mdz> YokoZar: apt's use of recommends and suggests, while suboptimal, is purely informational and can't cause problems with an upgrade
<dholbach> hai mvo_!
<mvo_> hi dholbach 
<YokoZar> mdz: that was an unrelated output bug
<YokoZar> mdz: the real bug is that it reads the old dependencies
<mdz> YokoZar: I find that very difficult to accept :-)
<YokoZar> mdz: if you want to see the apt bug remove the libwine dummy package, move libwine into conflicts/replaces for wine, and try apt-get dist-upgrade
<YokoZar> The Debian ones had tons of hacks in them that were no longer needed for Wine (in fact, they tended to break things.)  The best way to do it really was to start from scratch.
<mdz> YokoZar: I don't have time to do an experiment like that right now, but if you describe it in more detail, I can probably explain what's really happening
<YokoZar> The other problem I have is that that dummy package is over 2 megabytes, because I can't figure out how to remove the upstream changelog from it
<haggai> YokoZar: I don't see any Provides: in wine
<haggai> YokoZar: you need the Provides for a smooth upgrade
<YokoZar> I believe I had that at one point (provides, replaces, conflicts)
<YokoZar> I might be wrong though
<YokoZar> I hope I am wrong and it's my stupidity (and misreading of documentation) that prompted my need for dummy packages
<YokoZar> I'd really like to get rid of the dummy packages, especially since they're 2 megs each
<haggai> hopefully that will fix it
<Kamion> check your dh_installchangelogs calls, would be my guess
<haggai> now, what about my question about linking earlier?  Does anything link directly against /usr/lib/libwine.so.1 & /usr/lib/libwine_unicode.so.1 ?
<YokoZar> Also I would like to point out that in less than 10 minutes I love this channel about 100 times as much as #debian-devel, whose first instinct was to yell at me for not supporting all esoteric sound systems until I had to explain to them Wine's autodetection
<YokoZar> oh yeah
<YokoZar> linking
<YokoZar> winelib compiled apps link to wine's libraries in /usr/lib/ and /usr/lib/wine
<Kamion> YokoZar: your dummy packages should really be Architecture: all, and built in binary-indep
<YokoZar> Kamion: thanks, will change
<YokoZar> I just remembered I need to change the mime type file too, from MSDOS executable to Windows executable
<Kamion> YokoZar: if you do that, then your binary-indep rule can simply say 'dh_installchangelogs -i' rather than 'dh_installchangelogs ChangeLog'
<Kamion> and you won't get the upstream changelog
<Kamion> you probably also want to add the -a option to many of the dh_* rules in binary-arch, and -i correspondingly in binary-indep
<Kamion> s/rules/commands/
<YokoZar> Do we even want the upstream changelog in any of the packages?
<Kamion> the upstream changelog is often valuable
<Kamion> it should be in the primary package, at least
<YokoZar> I guess only in the wine package, yeah
<Kamion> but there's little point duplicating it if they all depend on that
<haggai> YokoZar: So you're saying, becuase the shlib versioning is broken at the moment, there should not be a libwine package?
<Kamion> might consider symlinking the doc directories together, since all of the binary packages depend on wine
<YokoZar> haggai: uh
<Kamion> that can be fiddly to do correctly, though; in particular the transition will be awkward
<YokoZar> Kamion: good point.  Wine's got it's own funky docmaking
<haggai> YokoZar: I'm trying to work out why you want to not follow usual packaging conventions for libwine
<YokoZar> On that note, how do I make it an official help file?
<Kamion> since dpkg does not want (for good reasons) to replace a directory with a symlink on upgrade
<YokoZar> haggai: Because the wine libraries depend on the wine binary
<YokoZar> haggai: winelib compiled apps still need to be run "wine foo.exe.so"
<YokoZar> We are making a wrapper script that lets you run them "./foo.exe" but that calls the wine binary
<Kamion> you don't need a wrapper script for that surely?
<syn-ack> YokoZar: I thought there was already one for that...
<koke> hi, I have an auto(conf|make) question :)
<YokoZar> syn-ack: It's kinda broken at the moment
<syn-ack> YokoZar: aha.
<YokoZar> Well in theory we could make a Windows app (say, Miranda IM) rather indistinguishible from a linux one, if you have the wine package installed
<koke> I have some sources and I want debian/ subdir to be added when I do make dist
<Kamion> update-binfmts with an appropriate detector to distinguish Windows executables from .NET PE
<Kamion> all that was written years ago
<YokoZar> At least as far as the normal user is concerned.
<YokoZar> Kamion: I think at this point the wine binary does stuff that is more than just running the app and pointing it to winelib.  Mainly, it calls the wineserver
<YokoZar> It's still important for winelib apps to be managed by wineserver, in case they try to message eachother or their children
<Kamion> YokoZar: the point of binfmt-support is that it can cause the kernel to spot that it's a Windows binary and run it via 'wine foo.exe'
<Kamion> so you don't need wrapper scripts
<YokoZar> Kamion: oh I see you're talking about the wrapper script.  The thing is it's not a windows binary if it's compiled with winelib - it's a unix binary
<dholbach> koke: why doesnt yout /debian/ reside in the tarball? why do you want to create it on  "make dist" ?
<Kamion> oh, I see
<Kamion> right, I understand now
<YokoZar> Which is what's so cool about it - we could run it on PPC :)
<haggai> YokoZar: so is it impossible to have a smooth transition?  Where e.g. libwine changes ABI and becomes libwine.so.2, but older apps linked against libwine.so.1 can continue to be run under the new wine?
<YokoZar> Another issue that came up is on the amd64 arch - Wine needs 32bit libraries, but that's kinda difficult on a 64 bit install
<haggai> (the new wine version, linked against libwine.so.2)
<koke> dholbach: at this moment I have no tarball, just a svn repos
<Kamion> mdz: you need getopt(1)? coincidentally, I happen to need it too; I'll add it
<YokoZar> haggai: No everything needs to be coordinated by the same wineserver...no sense keeping old versions around anyway
<Kamion> +       //kill(-1, SIGSTOP);
<Kamion> mdz: eww, you evil C++ person
<Kamion> although I guess // is C99 now, more's the pity
<YokoZar> The good thing is Microsoft has the same approach - you can still run windows 3.1 apps on Windows XP
<YokoZar> So if we get our DLLs working like the XP ones, no problem.
<dholbach> koke: most upstream developers just add the debian directory to svn or cvs - it's okay that way :-)
<YokoZar> The best way to make comments is to #define and #undef them ;)
<YokoZar> #define comment here's some useful code
<YokoZar> #undef comment
<Treenaks> YokoZar: EEP
<Kamion> #ifdef 0 is much saner
<Kamion> sorry, #if 0
<syn-ack> YokoZar: theyve only been doing that since 2k SP4  though, before that, it was somewhat of a PITA.
<Kamion> or indeed #ifdef UNDEFINED, which is useful documentation
<koke> dholbach: yes, it's added, but when I do make dist to generate the tarball I want debian/ to be included
<haggai> YokoZar: but couldn't the new wineserver still run the old app? (Sorry I don't know the internals very well)
<Kamion> dholbach: it's pretty annoying to have debian/ in the upstream tarball, usually
<YokoZar> syn-ack: Well the old approach was to have multiple DLLs alongside eachother (eg: seperation between system and system32).  Wine can do a similar thing
<Kamion> speaking as a package maintainer
<dholbach> koke: add it to DIST_SUBDIRS and SUBDIRS 
<syn-ack> YokoZar: right, You are defanantly coming a long way from what I used to try and get working...
<dholbach> Kamion: why is that?
<YokoZar> haggai: We're talking about winelib compiled apps only here (of which there currently aren't any...)  - the wine binary itself does the linking I think.
<koke> dholbach: thanks, that whas what I was looking for :)
<YokoZar> haggai: And there's no need to getting the wine binary to support old, broken versions of wine dll files
* syn-ack goes to sleep();
<Kamion> dholbach: well, most packages are non-native, i.e. have a separate .diff.gz
<Kamion> dholbach: firstly, it's conventional to have the whole debian/ directory in .diff.gz, for easier browsing of the packaging
<Kamion> dholbach: (and in your style you end up with weird changelog diffs in the .diff.gz)
<dholbach> dholbach: oh yes... i can see that
<YokoZar> Here's some food for thought: Wine can be compiled and run in Windows.  Some of the Wine DLLs are so perfect that they can replace windows ones
<Kamion> dholbach: secondly, you can't remove files in a .diff.gz, only add or change them; you can get yourself into some awkward situations with the debian/ directory in the upstream tarball
<Kamion> dholbach: thirdly, the package maintainer is generally much better at knowing what needs to be in the debian/ directory than the upstream maintainer is
<haggai> YokoZar: ok, so you assume mass breakage of all wine apps (assuming there are some :)  when you get a new wine version.  It goes against the Debian way but if that's what upstream are insisting on I suppose we can do it too
<YokoZar> In theory if our DirectX dlls worked perfectly (which are really just a wrapper for OpenGL), they could be used on Windows and you'd run everything in OpenGL
<Kamion> dholbach: fourthly, nowadays debian/ directories are used by a number of distributions rather than just Debian, so you can't assume that you're going to be making all the uploads of the package
<YokoZar> haggai: Well, we might want to change it when we stabilize winelib, and start making winelib apps
<haggai> YokoZar: that's what I'm thinking
<Kamion> mdz: (why do you need getopt, incidentally?)
<YokoZar> haggai: I'll ask around on the wine developer channel a bit.  But in the meantime finishing up my Miranda pacakge would be nice
<YokoZar> It'd probably make a good news story too.  
<haggai> YokoZar: at the moment I see good reasons from you why it _could_ be done, but no reason why it _must_ be done
<dholbach> Kamion: you're right... i just saw it from my point of view, where i downloaded the tarball and had a fully functional package afterwards, but yes, i can seh your *count* 4 arguments :-)
<Kamion> dholbach: I realise that the other approach has its appeal too, just pointing out the downsides. :)
<YokoZar> Ok I'll be writing that email off to ubuntu-devel
<haggai> YokoZar: I'm thinking, leaving it how it is shouldn't hurt.. and would make things a little more predictable in the future perhaps if things did stabilise
<YokoZar> Thanks guys, this is really exciting
<YokoZar> haggai: We could always turn the dummy package into a not-so-dummy package
<haggai> YokoZar: ..and mean you were not quite so different from Debian
<YokoZar> It just seems strange to have a libwine package that depends on wine and vice-versa
<YokoZar> If I'm going to do that why not just have one package
<haggai> because you go against the concept of libpackage<SOVER> and make it a lot different from Debian
<YokoZar> I'm not entirely certain winelib apps even link against libwine at the moment
<YokoZar> I know that sounds strange, but if they're called with wine it's really only the wine binary that's linked with libwine
<YokoZar> And the wineserver binary
<haggai> yes I understand.  I'm only thinking we don't need to restructure wrt Debian at this stage
<haggai> if you were to take the packages over in Debian too I think the argument would be stronger to do the transition
<Kamion> it's not really libwine that depends on wine, surely; it's the binaries built with libwine that depend on wine
<Kamion> imagining for a second that they were Debian packages, you could handle that with shlibdeps
<YokoZar> A libwine package that didn't have the wine binaries would be useless - it couldn't even run winelib compiled apps
<haggai> YokoZar: yes, but it could do in the future..
<YokoZar> But that would mean there's nothing in the wine package anymore...
<haggai> binaries built against a particular shared lib go in there
<YokoZar> Well, sorta
<YokoZar> Like I said I don't see anything wrong with keeping the dummy package around in case we need it later, and sort of leaving things how they are
<YokoZar> If things did change we could make wine depend on libwine again
<haggai> I'm not so happy about that.  That's just not making a decision because we can't decide :)
<YokoZar> It's like quantum physics, isn't it
<YokoZar> information about wine's position is inversely proportional to information about its speed
<haggai> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#SYMBOLVERSIONING might be interesting
<haggai> as an example of how this could be solved in the futre without breaking other apps
<YokoZar> Also I heard a rumor that Mr. Shuttleworth is planning on creating the first all-Linux moon colony using the Ubuntu developers as the legislative body: confirm/deny?
<haggai> although I accept you're probably thinking that sort of complication will never be necessary anyway
<YokoZar> Honestly I'm having trouble understanding it
<Kamion> haha
<Kamion> COMMUNITY MOON COUNCIL
<YokoZar> Kamion: Why else do you think there's a screening process?
<YokoZar> Oh yeah I've got more packaging questions
<YokoZar> If I wanted to create an applications menu link to winecfg, what would be the way to do that?
<YokoZar> I received conflicting information earlier about the .menu stuff and the fd.o stuff
<YokoZar> The other thing was having Wine's user guide appear in the Gnome help menus - I'm a bit confused about how to do this, and if it should be done upstream or here
<Kamion> registering it with scrollkeeper is probably the way to do that, although my information could be out of date
<Kamion> generally upstream should provide an OMF file and the packaging should call dh_scrollkeeper
<Kamion> (and build-depend on debhelper (>= 4.1.46), if that isn't implied already)
<YokoZar> Wine uses .sgml files for its docs and then compiles them with docbook2man and stuff - is there one that will make OMF files?
<Kamion> OMF isn't a document format, it's a little file that describes the documentation and says where it is
<YokoZar> And what form is the documentation supposed to be in?
<Kamion> docbook's fine
<YokoZar> Do you have a link for that stuff?  I could put in a patch to winehq and soon all the distros would be doing it right.
<Kamion> there are lots of examples in /usr/share/omf
<YokoZar> Thank you
<Kamion> http://scrollkeeper.sourceforge.net/documentation/writing_scrollkeeper_omf_files/index.html
<Kamion> that should do it :)
<YokoZar> Most excellent
<dholbach> can anyone give me a hand with pbuilder?
<dholbach> i sticked to the information on the wiki, updated it, but get these error messages "dpkg-source: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)"
<dholbach> and end up with "checking for C compiler default output file name... configure: error: C compiler cannot create executables" :-/
<Kamion> sounds like you're missing build-essential somehow
<Kamion> the former warning is (IIRC) normal-in-pbuilder and harmless
<dholbach> Kamion: should a package build-dep on build-essential?
<Kamion> no
<dholbach> that's what i thought
<Kamion> by definition
<Kamion> pbuilder should install it automatically though
<Kamion> hmm, I wonder what the best way to let an application know about the installer's supported locales is
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<Kamion> suppose I should make localechooser spit out a tiny .deb or something
<pitti_> carlos: here?
<carlos> pitti_: hi
<pitti_> carlos: just FYI, I'm currently implementing the stripped tarball extraction
<pitti_> carlos: including overrides
<pitti_> carlos: do you already work on that, too?
<carlos> pitti_: to get your tarballs imported into Rosetta?
<carlos> yes
<pitti_> carlos: btw, the first new tarball (with domains.txt) is online
<carlos> cool!
<pitti_> carlos: the problem are all the other tarballs
<pitti_> carlos: some of them don't even include a pot file, that was a bug
<carlos> so, what should we do?
<pitti_> carlos: I solved the ones with missing potfiles by adding an override
<pitti_> carlos: well, I don't want to duplicate your work
<carlos> pitti_: missing potfiles == with .po but not with .pot?
<pitti_> carlos: so if you are already working on it, when do you think this is ready?
<pitti_> carlos: yes
<carlos> pitti_: How is that possible?
<pitti_> carlos: the pot is in the source directory, but it did not get copied into the tarball
<pitti_> carlos: obviously a bug
<pitti_> carlos: shouldn't happen any more
<pitti_> carlos: I rewrote that part in version 6
<carlos> ooh, I thought there was no .pot file in the source tree
<pitti_> ah, you need the pot for rosetta, too, right?
<carlos> pitti_: I'm not changing any .tar.gz file, not sure where do you think we are doing the same task..
<pitti_> carlos: so I'm afraid we have to rebuild these packages
<carlos> pitti_: yes, I need it
<pitti_> carlos: I don't change the tarballs, too. I try to impllement some heuristics to find out the domain of the broken ones
<carlos> pitti_: what's the point behind it? is there any problem with the .mo lookup we talked yesterday?
<carlos> it should work always...
<pitti_> carlos: and also do an implementation for multi-pot packages (but that's not ready yet=
<pitti_> s/=/)/
<pitti_> carlos: yes
<pitti_> carlos: that it wasn't done 
<pitti_> carlos: for the already present tarballs
<pitti_> carlos: it did not work before I uploaded 6 yesterday :-)
<pitti_> carlos: we are already stripping for a few days now
<pitti_> carlos: so the tarballs in 20050126/ and most of 20050127/ are mostly useless
<pitti_> carlos: s/mostly/many of them/
<pitti_> carlos: I will assemble a list of the broken ones
<carlos> pitti_: don't worry about them, if we have a list we could fix it later in Rosetta manually
<pitti_> carlos: okay
<carlos> and next build of that package will get the right name
<pitti_> carlos: so given that you ignore the broken ones for now,
<pitti_> carlos: when can I get the set of all imported po files from Rosetta?
<pitti_> carlos: in particular I only need those which were uploaded recently
<pitti_> carlos: i. e. for which tarballs exist in http://people.ubuntu.com/~lamont/translations/
<carlos> pitti_: we are not (yet) importing into Rosetta
<pitti_> carlos: and I need then sooooooon...
<carlos> doing tests locally, after that test in our development server and finally in our production server
<pitti_> carlos: anyway, if you say that you need more time for that, I will continue to implement my temporary system
<carlos> pitti_: It will not be ready in production until next week
<carlos> we cannot move new code into production as fast
<carlos> or we could break the server
<pitti_> okay
<ogra> c u later
<pitti_> carlos: okay, I have my preliminary own system ready
<pitti_> carlos: now it's good enough to build new base langpacks
<pitti_> carlos: wow, we already stripped 188 MB worth of po files
<carlos> pitti_: so you get  the .po from the same tar.gz we import into Rosetta?
<pitti_> carlos: yes
<pitti_> carlos: from lamont's tarballs
<carlos> pitti_: and how do you handle multi pot tarballs?
<pitti_> carlos: I have a script which downloads all tarballs (only for the newest source upload)
<pitti_> carlos: well, later I handle this with overrides
<carlos> manual table?
<pitti_> carlos: $ cat domain-overrides/glibc
<pitti_> libc build-tree/glibc-2.3.2/po/
<pitti_> carlos: -> that means: in source package glibc, use the domain "libc" for all po files in build-tree/glibc-2.3.2/po/
<pitti_> carlos: right now my script supports only one line per override file
<pitti_> carlos: and that's enough for now
<carlos> pitti_: hmm, perhaps you could send me it so we go faster when fixing them by hand in Rosetta :-D
<pitti_> carlos: because all multi-pot tarballs I encountered mostly contain only bogus pots in addition
<carlos> bogus pots?
<pitti_> carlos: sure, I send you the complete package
<pitti_> carlos: yes, something like "header.pot" with only the information header
<carlos> pitti_: well, multi pots and packages like pmount with only one .pot but wrong domain name
<pitti_> carlos: I can handle pmount with an override
<pitti_> carlos: I also override the tarballs with no pot file at all
<pitti_> carlos: I send you the list, then you don't need to do this work again
<carlos> thank you
<pitti_> carlos: we have now 33 packages left for which we need to guess the domain from the pot
<pitti_> carlos: that amount can be handled easily
<pitti_> carlos: and eventually it will go down to 0 with new uploads
<carlos> ok
<seb128> mvo_: around ?
<mvo_> seb128: yes
<seb128> mvo_: got my mail ?
* mvo_ checks mail now
<seb128> "update-notifier fr.po"
<seb128> or something like that
<mvo_> yes, thanks. commited already
<seb128> BTW I was speaking about the non-translation issue
<seb128> ie: it doesn't use the .mo file here
<seb128> is the translation supposed to work ? 
<seb128> s/was speaking/wanted to speak/ rather :)
<mvo_> seb128: sorry, I don't have a mail from you but from a different frensh guy (Jean privat) and he send me a update-manager fr.po 
<seb128> ok
<mvo_> it looks like I don't have the mail (yet?). when did you send it?
<seb128> before going to sleep yesterday
<rubenv> lot's of downloads on the livecd torrents
<rubenv> about 50gig seeded last night
<thom> why do the language packs depend on mozilla locale packages when we're not shipping mozilla?
<thom> pitti: ^
<pitti_> thom: we support it
<dholbach> thom: not to mention that mozilla-thunderbird doesnt work with the current  mozilla-thunderbird-locale-* -packages
<thom> dholbach: thunderbird is irrelevant and will be fixed
<thom> pitti: it's not seeded
<dholbach> thom: ok
<pitti> thom: it was in main a while ago...
<pitti> thom: apparently it got demoted
<pitti> thom: okay, I will fix the support packages then
<thom> oh, gar
<pitti> thom: hey, it's still in main
<pitti> thom: mozilla-browser
<Mithrandir> gcc-3.4 manages the feat to build-depend on _two_ versions of automake.
<thom> yeah, psm drags -browser in
<thom> hrm, wonder if we can remove mozilla-psm
<pitti> thom: we discussed about removing mozilla from supported a while ago on u-devel
<dholbach> bbl
<Kamion> we demoted mozilla-psm to supported after discussion on ubuntu-users
<Kamion> or -devel
<Kamion> the conclusion seemed to be not to demote it to universe entirely
<pitti> thom: but there were still many folks who preferred mozilla over ffox
<thom> really?
<thom> gar
<thom> that *sucks*
<thom> three browsers is just silly
<thom> ok
<thom> Kamion: can you confirm though that the locales packages for mozilla itself don't appear to be seeded
<Kamion> give me an example of a language pack that depends on them?
<Kamion> oh, no, don't
<pitti> Kamion, thom: mozilla-locale-fr is seede
<pitti> d
<Kamion> pitti: why isn't it showing up in http://people.ubuntu.com/~cjwatson/germinate-hoary-output/rdepends/ALL/ then?
<pitti> OTOH, e. g. -es isn't
<thom> oh, are they just seeded via the lang packs?
<thom> 11:50 ~/work/hoary-seeds% grep mozilla-locale *
<thom> 11:59 ~/work/hoary-seeds%
<Kamion> <cjwatson@cairhien ~/src/ubuntu/seeds/hoary>$ grep mozilla-locale *
<Kamion> <cjwatson@cairhien ~/src/ubuntu/seeds/hoary>$
<pitti> thom, Kamion: for my sake I can remove the locale packages from mozilla
<Kamion> s/for my sake/as far as I'm concerned/?
<pitti> :-)
<pitti> yes
<Kamion> yeah, I think it's only the language packs that are pulling them in at the moment
<pitti> that means, I don't think there is a particular value of adding them to the support packages
<pitti> most people use ffox
<pitti> and people can still install the locales manually if they really want to
<Kamion> if it were recommended by the language packs, and nothing else was recommended that we didn't want to install by default if available, then you could recommend the mozilla locales and I could have base-config use aptitude --with-recommends ...
<Kamion> not sure if that's sane though
<pitti> hmm, I think that doesn't really help
<pitti> either we want the locales, or we don't
<pitti> well, the difference would just be that the locale packages would go to universe, right?
<Kamion> ok, let's ditch 'em?
<Kamion> yeah
* pitti votes for ditching
<thom> +1 for ditching
<pitti> okay
<pitti> thom: elmo will hug me; I will upload som 160 new packages now anyway :-)
<pitti> thom: so if I also upload some more support packages, it won't make much of a difference any more :-)
<thom> heh :-)
<pitti> carlos: ping
<carlos> pitti: pong
<pitti> carlos: http://people.ubuntu.com/~pitti/strip2lparc.tar.gz
<carlos> what's that?
<pitti> carlos: this contains the tool to build an update.zip tarball (like one exported from Rosetta)
<pitti> carlos: from people.u.c/~lamont/translations
<thom> so if you're de-depending on mozilla-locale-* we can just sync them from unstable
<pitti> carlos: and it contains also the overrides
<carlos> oh, ok
<carlos> perfect, thanks
<pitti> thom: Just did
<pitti> thom: I mean, removed the deps
<pitti> carlos: maybe you can also recycle some code from dload-strippedtar
<carlos> pitti: don't think so, I have already that code
<pitti> okay
<carlos> in fact I just imported your pmount tar.gz into my local computer
<thom> pitti: right
<thom> elmo: when you wake up, please sync mozilla-locale-* from unstable so they're installable again
<pitti> "wake up"?
<thom> well, he was still awake at 5, so i guess he's not around now
<pitti> carlos: okay, all langpacks uploaded
<pitti> carlos: so I now have a working "Rosetta emulation"
<carlos> :-)
<pitti> carlos: that gives you some more time to finish the import/export
<carlos> pitti: well, I still will try to finish it as soon as possible
<carlos> but thanks
<pitti> hmmm,
<pitti> wasabi: GPG error: http://archive.ubuntu.com hoary Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<pitti> wasabi: GPG error: http://security.ubuntu.com warty-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<pitti> sorry wasabi, that wasn't intended directly to you
<pitti> that line started with a "W:"
<pitti> mvo_: do you know what's wrong here? ^ 
<mvo_> pitti: about the key error? no
<pitti> mvo_: does it work for you?
* mvo_ apt-get updates
<mvo_> I got a different error: "universe/binary-i386/Packages.gz MD5Sum mismatch"
<pitti> somebody sabotages our ftp server!!!
<rubenv> i'm getting weird stuff with universe too today
<mvo_> pitti: try to remove the /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_Release and update again please
<pitti> mvo_: I purged all files in it
<pitti> mvo_: same error
<pitti> hoary Release and warty-security Release
<marcin_ant> hello - I would like to ask about website competition - are there any previews of projects that already submitted?
<mvo_> pitti: I get MD5sum errors. there is something strange here :/
<pitti> mvo_: I don't believe that there is something wrong with the archive, though
<mjg59> What assumptions does the live CD make about the internal clock?
<pitti> mvo_: however, if it helps, during the last days I could not authenticate package downloads from main as well
<rubenv> pitti: when my apt cronjob runs
<rubenv> universe disappears
<smurfix> marcin_ant: ask mako -- he should be around later (or send email)
<rubenv> but when i reload it with synaptic
<rubenv> all is fine
<rubenv> very strange :)
<pitti> rubenv, mvo_ : oh yes, I used good ol' apt-get
<mvo_> the last apt update was at the 19. jan and it didn't changed anything on the http or apt-secure side
<marcin_ant> smurfix: ok - thanks
<rubenv> the weirdness began today
<mvo_> pitti: there is http://archive.ubuntu.com/ubuntu/Archive-Update-in-Progress-mirnyy.ubuntu.com
<pitti> mvo_: hmm, updating isn't atomic then
<pitti> ?
<mvo_> apt-get update? 
<dholbach> re
<jbailey> Is the HardwareSupport/Machines/Laptops page intended to be Hoary or Warty?
* thom fails to understand why people think sbuild is hard to use, having just set three up
<jbailey> thom: I haven't tried it in about 3 years, but it used to require a bit of hacking to figure out where all the pieces needed to go.
<jbailey> The .deb package was procken out of the box.
<seb128> thom: you are on amd64 right ?
<infinity> The current debs from debian-admin work fairly well.
<infinity> OTOH, I'm still from the old skool "hack to make it go" camp, and it wasn't THAT bad.
<thom> seb128: yeah
<seb128> thom: do you get #5870 ?
<thom> the only thing i ended up hacking was to add hoary as a valid dist
<ogra> seb128: did you see the last comment there ?
<thom> seb128: looking
<seb128> ogra: that's not really useful ....
<thom> evolution
<thom> zsh: 24969 floating point exception  evolution
<seb128> nice
<seb128> do you have any idea on what could cause that ?
<ogra> seb128: but a hint if you compare a sytem where it builds with the buildd ?
<seb128> no
<thom> i'd put money on you not using gcc-3.4 to build on amd64 personally
<ogra> ah, ok...understood :)
<seb128> ogra: I need details on the build environment from a working system
<seb128> ogra: mine is i386 which is not really useful :p
<seb128> thom: you mean that it should be built with gcc-3.
<seb128> 3.4 ?
<ogra> seb128: i havent done it myself yet...will try it after work and provide info :)
<thom> seb128: yes
<seb128> and the buildd use ?
<dholbach> thom, seb128: wouldnt this include recompilation of 2497246 libraries?
<thom> they'll use 3.3 by default
<seb128> thom: so that's an issue for lamont or the package ?
<thom> dholbach: not necessarily
<seb128> dholbach: evolution-data-server and evolution only according to the comments
<thom> seb128: packaging; that's just a hunch though, i can have a play after firefox finishes building here
<thom> seb128: evo links against nspr, right?
<seb128> thom: that would be grrrrrreat :)
<seb128> correct
<seb128> why ?
<thom> yeah, i bet that's it
<dholbach> thom: i had the issue with c++ code once and i had to recompile libraries too to get it working
<ogra> thom: then i would spend you a beer next time we meet :)
<thom> dholbach: nspr is already linked against 3.4 so it should just be evo
<thom> ogra: ;D
<thom> actually, i should leave it broken and force everyone to use mutt
<dholbach> dholbach: alright... cool *hopes to get his evolution on amd64 fixed too* ;-))
<ogra> hehe...
<dholbach> thom: alright... cool *hopes to get his evolution on amd64 fixed too* ;-))
<seb128> thom: does mutt connect to exchange servers ? :p
<thom> seb128: if the exchange server has imap enabled, sure :P
<Kamion> wow, it actually started up
<Kamion> http://people.ubuntu.com/~cjwatson/kickstart.png
<Kamion> although lots of the values are wrong, I know
<thom> Kamion: cool
<ogra> dholbach: you are talking toyourself very often.... thought about seeing a pychiatrist ;-P
<dholbach> ogra: i'll make an appointment :-)
<ogra> dholbach: it has something sciziphrenic  ;-)
<ogra> Kamion: so now make it match the HIG ;-P
<Kamion> ogra: I'll be happy if it works
<ogra> :)
<lamont> hrm.. router is machine checking...
<lamont> may be time to retire it.
* Kamion contemplates uploading this to get past the feature freeze, so that all else is bug-fixing ... :-)
<Kamion> OTOH I'm not terribly convinced I want to support it just yet
<lamont> Kamion: it=??
<Kamion> lamont: http://people.ubuntu.com/~cjwatson/kickstart.png
<lamont> oh. that.
* Kamion giggles at http://people.ubuntu.com/~cjwatson/kickstart-packages.png - could possibly do with being a bit more useful
<Kamion> this is porting-by-hacksaw
<thom> heh
<jdub> dear mjg59, i love fully working suspend! love, jdub.
<mjg59> dear jdub, you may thank me with nubile young ladies, love, matthew
<jdub> dear mjg59, will you be coming to lca/udu? love, jdub.
<mjg59> If Mark will pay for my flights, most certainly
<jdub> heh
<mjg59> I should register for lca, really
<thom> AAARGH, cdbSHIT
* thom shakes his fist at seb128 
<seb128> what ?
<seb128> what's wrong with cdbs again ? :p
<thom> eds uses it, that's what:P
<seb128> in a weird way, be careful
<jbailey> seb128: Hmm>?
<seb128> there is a control.in but you need to run debian/rules update-control to update debian/control
<seb128> that's not done to the build for this one
<thom> oh dear lord
<seb128> :)
<maswan> dear ftpmasters, @ERROR: max connections (25) reached - try again later
<maswan> (tonight)
<thom> ok, how do i set CC in debian/rules in such a way that it'll make it configure?
<jbailey> thom: Setting CC is usually enough, just do it after the cdbs bits.
<seb128> ifeq ($(DEB_BUILD_ARCH),amd64)
<seb128> export CC=gcc-3.4
<seb128> export CXX=g++-3.4
<seb128> OPTFLAGS=-O
<seb128> endif
<seb128> 
<seb128> if you want to do like epiphany
<thom> ok
<thom> wasn't sure if it needed special magic
<thom> thanks
<seb128> np :)
<jbailey> Added to my todo list:  Make Thom a Believer. ;)
<thom> jbailey: how much are you willing to pay? :-)
<jbailey> thom: Perhaps I can arrange the ship you mjg59's nubile young ladies once he's...  No.  I should probably come up with something better. =)
<marcin_ant> mako: ping
<thom> yay local mirrors: Fetched 18.1MB in 1s (10.0MB/s)
<Treenaks> hm.. something can't count :)
<thom> seb128: e-d-s building, evo queued
<seb128> rock
<smurfix> Treenaks: or round
<Treenaks> smurfix: it must be a P1 using FDIV then ;)
<lamont> if [ "$have_pcmcia" -eq 1 ]  && ! grep -q pcmcia-cs /var/lib/apt-install/queue 2>/dev/null; then
* lamont looks around for something to clean up the vomit with
<mooch> anyone knows what ubuntu uses for autobuilding packages? sbuild with wanna-build?
<lamont> mooch: pretty much
<lamont> at least for warty/hoary
<lamont> will radically change shortly after hoary, I expect
<mooch> lamont: what will you guys use?
<lamont> mooch: launchpad infrastructure will do the builds
<mooch> is/will be it available somewhere as source code? 
<lamont> mooch: it's not even written yet
<mooch> right, if it is launchpad i guess it will not be...
<mooch> ;(
<lamont> nor will it be very generally usable
<thom> seb128: gcc-3.4 doesn't help
<thom> seb128: guess this is a Mithrandir job
<seb128> urg :/
* Mithrandir radiates some gcc hate
<Mithrandir> thom: hm?  what do you want me to do?
<thom> Mithrandir: make evo work on amd64 ;-)
<thom> Mithrandir: seb has the details
<Mithrandir> seb128: have you broken evo again?
<seb128> Mithrandir: try to run evo on amd64
<seb128> #5870
<seb128> a part of #3619 too
<seb128> SIGFPE on start for amd64 users
<Mithrandir> checking for mutexes... UNIX/fcntl
<Mithrandir> configure: WARNING: NO FAST MUTEXES FOUND FOR THIS COMPILER/ARCHITECTURE.
<Mithrandir> from http://people.ubuntu.com/~lamont/buildLogs/d/db4.1/4.1.25-17/db4.1_4.1.25-17_20040817-2250-amd64-successful
<seb128> arg
<Mithrandir> didn't I fix this?
* lamont goes to get ready for the day, feed the horses, and (root cause) fetch the laptop from his car.
<Mithrandir> #281059 with patch
<T-Bone> lamont: "feed the horses"? You're living in a ranch? :)
* T-Bone needs to update his info database, section "LaMont Jones" ;^)
<lamont> T-Bone: only 3 horses - 2 of them are boarders
<T-Bone> sweet ;)
* T-Bone is eager to be able to ride again. Still not recovered from his ski injuries ;P
<seb128> Mithrandir: could you fix it ? :)
<Mithrandir> seb128: if archive.ubuntu.com wasn't so DOG SLOW, I could.
* Mithrandir tries to calm down
<Mithrandir> sorry, I've been hitting my head against gcc, binutils and glibc for a few days.
<jdub> haggai: around?
<haggai> jdub: yo
<haggai> jdub: thanks for making the lists
<marcin_ant> #ubuntu
* marcin_ant sorry
<jdub> wow, having entertaining problems with the archive
<pitti> jdub: you too?
<pitti> jdub: I get lots of "gpg signature failed" errors since recently
<zul> haggai, whats the wiki page for adding yourself to the motu canidates page?
<ogra> zul: MaintainerCandidates is the place where you add yourself
<zul> thanks...i knew it was something like that
<ogra> http://www.ubuntulinux.org/wiki/MaintainerCandidates
<Mithrandir> seb128?
<zul> ogra, done
<ogra> hi Chuck ;)
<Kamion> lamont: what's wrong with the pcmcia thing?
<Mithrandir> seb128: this is crackful:
<ogra> Kamion: its missing on the amd64 livecd image
<Mithrandir> : tfheen@golem ..ution-data-server-1.1.4.1 > ldd /usr/lib/evolution/evolution-data-server-1.2| grep libdb
<Mithrandir>         libdb-4.2.so => /usr/lib/libdb-4.2.so (0x0000002a96886000)
<Mithrandir>         libdb-4.1.so => /usr/lib/libdb-4.1.so (0x0000002a997bc000)
<Mithrandir> : tfheen@golem ..ution-data-server-1.1.4.1 > ldd /usr/bin/evolution |grep libdb
<Mithrandir>         libdb-4.1.so => /usr/lib/libdb-4.1.so (0x0000002a9c7c2000)
<Mithrandir> : tfheen@golem ..ution-data-server-1.1.4.1 >
<Mithrandir> seb128: mixing db4.1 and 4.2 is a good way to make bad stuff happen
<Kamion> ogra: hmm? didn't know about that
<Kamion> pcmcia-cs is only in Ship, not Desktop
<Kamion> so certainly something would need to be done to install it ...
<jdub> 99% [2 Packages bzip2 1798144] 
<jdub> bzip2: Data integrity error when decompressing.
<ogra> Kamion: #5730
<Kamion> mdz: how about having casper run the apt-install queue, like base-installer does?
<Kamion> oh, that
<seb128> Mithrandir: outch
<[Clint] > Mithrandir: using db4.1 is a good way to make bad stuff happen
<Mithrandir> Clint: mixing libdb4.1 and 4.2 is an even better way.
<Mithrandir> Clint: is there something about the last patch from Kurt (in 281059) you don't like?
<mvo_> pitti: hals seems to be going mad :(
<mvo_> pitti: s/hals/hald/
<pitti> mvo_: does your computer use 100% CPU now?
<mvo_> pitti: yes
<mvo_> and the mouse stops for 1s 
<mvo_> and then goes again
<pitti> mvo_: please check with top whether it's really hald
<pitti> mvo_: I had this bug too
<pitti> mvo_: but it has nothing to do with 0.4.7 in particular
<pitti> mvo_: it only happens on hal upgrades and also happens with 0.4.4 
<pitti> mvo_: please reboot, that will fix it
<mvo_> it's hald (also it's not shown as 100% cpu)
<pitti> mvo_: hald itself was quiet for me
<mvo_> no other way than reboot :( ?
<pitti> mvo_: the kernel suddently went to 100%
<mvo_> I don't want to reboot :/
<pitti> mvo_: I believe that is a kernel bug
<pitti> mvo_: you can check
<pitti> mvo_: sudo killall -9 hald
<pitti> mvo_: I bet this won't fix it
<Mithrandir> seb128: you want to handle it further?
<pitti> mvo_: I think the kernel goes mad
<mvo_> pitti: killall doesn't help
<pitti> mvo_: right
<pitti> mvo_: becuase it's no particular process which causes this high load
<pitti> mvo_: if you can find out the culprit, I'd be incredibly grateful
<seb128> Mithrandir: pretty busy atm with my ~350 bugs, but I'll have a look
<pitti> mvo_: I have to leave soon, so I cannot look after this any more today
<elmo> thom: uh, really "-*"?   and that'll surely violate UVF, so can you do the normal drill for that?
<seb128> Mithrandir: do you have an idea on how to fix it ? 
<mvo_> pitti: hm, ok
<mvo_> pitti: I'll reboot then
<thom> elmo: sure
<Mithrandir> seb128: whack db4.1 so it goes away from the whole chain
<mvo_> pitti: thanks
<pitti> mvo_: thanks for breaking your system? :-)
<maswan> hey, it seems like the torrent tracker for the livecd doesn't work. intentional? working on it? want to "borrow" one from around here?
<seb128> Mithrandir: right
<mvo_> pitti: thanks for promising me to have a look :)
<Mithrandir> seb128: shout if you need a hand, then?
<thom> maswan: hrm, it was certainly working earlier
<seb128> Mithrandir: any hand would be appreciated, I'm sort of bug flooded atm
<Treenaks> jdub: did I read correctly? beagle in universe over the weekend?
<Mithrandir> seb128: I'll see if I can find the time, then.  Currently neck deep in gcc shit
<seb128> Mithrandir: there is #2623 already about eds and this in fact :/
<seb128> Mithrandir: ok, thanks
<maswan> thom: can you check if it is a local problem then? I'm just getting timeouts..
<thom> looking
<jdub> Treenaks: yes
<Treenaks> jdub: Coolness!
<Treenaks> jdub: where do I send the beer & women?
<jdub> quick:~# ifup sit0
<jdub> ioctl: No buffer space available
<jdub> Failed to bring up sit0.
<jdub> ^ hrm, anyone familiar with this kind of error?
<Mithrandir> jdub: /dev/shm mounted?
<jdub> yeah
<jdub> tmpfs        tmpfs     31M     0   31M   0% /dev/shm
<elmo> strace interesting?
<maswan> thom: any luck?
<jdub> oh
<jdub> man
<crimsun> jdub: you're not adding one you haven't deleted?
<thom> maswan: not yet, still playing
<jdub> crimsun: nup
<crimsun> jdub: (a tunnel device, that is)
<jdub> crimsun: as in sit0? no
<maswan> we've recently decided that ubuntu is neat for work, so I can (temporarily) throw some fun resources at mirroring/torrent tracking and so if needed. :)
<jdub> maswan: rad!
<maswan> So in that regard, I'm going to head off a while and go work on an install server here instead of just sitting around, ircing. I'll be back in a while. :)
<thom> ok, thanks for the offer. may well take you up on it if this doesn't come back :-)
<dholbach> re
<Mithrandir> maswan: is ftp.acc.umu.se ill or something?  I'm only getting about 2MB/sec from it
<kent> hmm, Synaptic is complaining that Hoary universe Packages.gz has wrong md controlsum :( Is that something to mind?
<jdub> hrm
<jdub> my qube is seriously b0rk
<maswan> Mithrandir: Hmm.. I'll check. Do you remember what frontend you got that from?
<Mithrandir> maswan: sorry, fallen out of scrollback.
<maswan> Mithrandir: Ok. I'll look aroudn a bit. It might just be that that particular frontend had a bit much too do just then.
<Mithrandir> maswan: yeah, guess so
<maswan> the bandwidth graph doesn't seem to indicate any large-scale failure
<maswan> (small hickup at 14:00 or so, but not in the last couple of hours)
<Mithrandir> could just have been my local link being a bit busy.
<maswan> thom: any luck? I can trivially put them up on the cdimage.d.o tracker and give that some exercise, if you want to repoint dns somewhere.
<Treenaks> meh.. md5sum mismatch..
<Treenaks> (yes, I know it's known)
<lamont> Kamion: testing a change to pcmcia-cs now that will only start it if pcmcia is present on the machine.
<lamont> then we can just seed the beast
* lamont notes that little bitty chunks of ice propelled by sub-freezing air at 5 atmospheres can really hurt.
<lamont> draw blood even.
<zul> usually yes lamont :)
<Kamion> hm, my language pack code in base-config was not quite right
<Kamion> are we going to put some language packs in Ship at any point?
<Kamion> because until we do it's like a fairly serious l10n regression for non-networked folks
<lamont> Kamion: did we stop building livecd's daily?
<Kamion> oh no, the language pack code's ok, I just screwed up the test. cool
<Kamion> lamont: yeah, mdz asked for that before the announcement, I'll turn them back on
<Kamion> lamont: want a build now?
<lamont> Kamion: yeah - just got pinged for an ia64 image
* dilinger listens to an interview w/ mark shuttleworth
<Kamion> lamont: building
<daniels> UNGH
<daniels> it would be awesome if we could remove people's ability to file bugs on certain packages for given amount of time
<lamont> daniels: because they're idiots, or because you're trying to fix the bug you introduced? :-)
<jdub> daniels: "this bug is queued for fixing, expect to see it soon"
<daniels> jdub: yes, but typing that like fifty times gets repetitive
<daniels> the ability to close multiple bugs as duplicates of one with a single click would be PHAT
<daniels> (well, n+1 clicks, where n is the number of bugs you want to mark as duplicates)
<Kamion> can't you do that with the "change multiple bugs at once" interface?
<daniels> the what interface?
<Kamion> daniels: "Change Several Bugs at Once" at the bottom of any bug list
* maswan mumbles a bit and wishes someone would have applied the make-arla-work patches so he didn't have to recompile the kernel
<Kamion> hm, unfortunately "duplicate" is not one of the several things you can do using that interface
<lamont> Kamion: very limited abilities in change several at once - can't close them, dunno about dup
<Kamion> lamont: you can close them
<daniels> Kamion: shiny
* maswan suddenly remembers this fancy "bug tracking system" and goes to find his password. :)
<zul> maswan: duh :)
<lamont> Kamion: kewl.  ISTR you couldn't before
* lamont grumbles - must go to town for lunch today, so that I can get some more Mt Dew.
<lamont> Kamion: about to upload a new pcmcia-cs that no-ops if pcmcia not present
<lamont>  * PCMCIA not present
<Kamion> cool
<lamont> (it just duplicates the have_pcmcia logic from ddetect)
<lamont> then the next question is, should ubuntu-desktop Depend: it, or should the livecd just install it and be done with?
<Kamion> should probably go in u-d
<Kamion> er, ubuntu-base even
<Kamion> it's not obviously a desktop thing; in particular you may well need it after the first reboot before u-d is installed (in the install CD scenario)
<lamont> Installed-Size: 1080
<lamont> mind you, u-b sounds good to me
<lamont> and not just because it means I don't have to change the livecd scripts. :-)
<Kamion> alternatively it can stay in Ship for size reasons, and go in Live as well
<Kamion> but I think mdz wants it installed always
<lamont> yeah, I think so
<lamont> we're definitely having a live-seed then?
<lamont> in which case, could I pretty please have ubuntu-meta generate an ubuntu-live metapackage?
<Kamion> I don't know if we're definitely having one ...
<Kamion> oh, live CDs built, including ia64
<Kamion> biggest of the lot, at 613MB
<lamont> ia64 is?
<Kamion> er, sorry, 577MB. Looking at the install CD by mistake.
<Kamion> Yeah.
<lamont> shall we draw the mark at 600MB for when you scream about ia64/ppc size growth?
<thom> maswan: torrents should be back up now
<lamont> BUGS AND LIMITATIONS
<lamont>        The c, s,  and u attributes are not honored by the ext2 and ext3 filesystems  as  implemented  in
<lamont>        the  current mainline Linux kernels.    These attributes may be implemented in future versions ext2 and
<lamont>        ext3.
* lamont pounds head on wall
<daniels> lamont: utf-8, man!
<maswan> thom: thanks
<daniels> unless that was utf-8, and screen is just shit
<lamont> daniels: ??
<lamont> echo $LANG
<lamont> en_US.UTF-8
<lamont> I'm innocent, dammit./
<jdub> calc: around?
<maswan> thom: I'll help along a bit with the bandwidth then. Lets see how high I can push this machine. ] ;)
<thom> cool :-)
<thom> heh, incoming on the amd64 torrent just jumped to 1.5MB/s
<Mithrandir> hm, I should possible join in the race, then?
<maswan> thom: 1.6M/s in, 800k/s out. :)
<thom>    Totals:   1.0 MB/s 950.2 KB/s 
<Kamion> daniels: looked like UTF-8 to me
<maswan> Totals:  2.7MiB/s  1.9MiB/s
<thom> fortunately, i don't have to pay bandwidth for that box
<Kamion> daniels: and I'm using irssi in screen ...
<maswan> (that's for all three)
<Kamion> lamont: 600MB> ok, assuming you mean ia64/amd64
<lamont> Kamion: doh
<lamont> yes
<thom> (that box is totally weedy, too - 100mbit network card and a single p IV)
<lamont> basically, we'll want to let them grow for a while, and then pay the price of resetting them.  And then again about a week before preview, or so.
<maswan> and ther the amd64 is done
<maswan> thom: ah, dual opteron with 4 gigs of ram and gigE here
<Mithrandir> I'm only getting like 1MB/sec down :/
<thom> yeah, a bit outclassed
<maswan> it isn't really taxing the machine though
<lamont> 24816264   4%    9.44kB/s   15:22:04
<RV> torrent seeding?
* lamont has no sympathy for Mithrandir 
<rubenv> time for an uncap :] 
<maswan> Totals:  2.1MiB/s  3.6MiB/s
<thom> hrm, that box just hit 0.71 load, which is the highest i've seen out of it - go freebsd ;-)
<rubenv> 19gb on ppc, 13gb on amd64 & 25 gb on i386 sent out already since this morning
<Kamion> mdz: did you have a particular reason for dropping all my localechooser branding changes and uploading a new version based on Debian?
<Kamion> oh, and not updating .po files following changes either
* Kamion tries to figure out how to re-merge ...
<maswan> thom: Oh, regarding that, is cdimage.u.c still slow? I could put up a mirror of just the livecds if that would help offloading it.
<Mithrandir> maswan: the problem with cdimage.u.c being slow is that the regular archive goes slow as well.
<rubenv> torrent stats: outgoing: 13421kbits/sec :)
<Mithrandir> I'm at outgoing 1.7MB/sec now.
<maswan> Mithrandir: Yeah, so if there would be need for offloading just the livecds with http redirects or so, I could put a mirror up at ftp.acc.umu.se. That one should be able to handle a couple of hundred megabit/s more.
<Mithrandir> plus another MB/sec from my workstation.
<maswan> Totals:  1.5MiB/s  4.2MiB/s
<maswan> just the ppc one I haven't gotten downloaded yet
<Mithrandir> I'm guessing I'll jump a bit when I have the complete thing.
<Mithrandir> and my gcc compile finishes :)
<Mithrandir> the ppc one is a lot faster than i386 here, actually.
* rubenv wonders whether he should start seeding on the second server too :)
<Mithrandir> amd64 being double the speed of ppc being double the speed of i386
<rubenv> pretty weird
<maswan> Mithrandir: all up to which seeds you happen to connect to
<rubenv> if you consider the number of seeds on amd64
<Mithrandir> maswan: it's almost the same on my desktop as my other box.
<maswan> Mithrandir: my i386 was faster than ppc
* mode/#ubuntu-devel [+o thom]  by ChanServ
<elmo> I've redistributed the cdimage and archive loads, but the problem is because of lack of ftp and rsync virtual hosting, a bunch of people are grabbing the ISOs from archive.u.c
<mdz> Kamion: gah, no
<mdz> Kamion: I must have downloaded the wrong source
<mdz> Kamion: I wanted getopt to implement a dpkg-reconfigure wrapper for casper
<Kamion> mdz: ah. well, you should have it now; want to fix localechooser before triggering a d-i rebuild, though, because the installer is probably fucked at the moment
<mdz> Kamion: have you fixed it already, or shall I?
<Kamion> I was making a localechooser change anyway, so I'll do it
<maswan> Seems to be holding steady at about 4M/s total
<Mithrandir> maswan: have you tuned it in any way?
<Mithrandir> I'm only doing about 2MB/sec
<Kamion> hm, although the change I was going to make requires NEW; I'll leave that part 'til later
<maswan> Mithrandir: nope, just btlaunchmanycurses.py . in a directory with the three .torrents
* Mithrandir bumps the max_uploads param
<trulux> where's pitti?
<trulux> I have good news for him
<trulux> we've solved the libssp bugs and now we have that part done
<trulux> just make the name-changed packages and we will have done the ssp implementation for Ubuntu
<tseng> trulux: erm
<maswan> Mithrandir: did it help?
<Mithrandir> maswan: not really, no.  Possibly due to me turning it a bit too high causing it to not use the disk cache too well
<Mithrandir> I'm going to let it sit around for a little and see what it ends up at
<maswan> Mithrandir: ah. Hmm.. I could try here. I fit all 3 isos in ram. :)
<Mithrandir> give it a shot.
<Mithrandir> I've only got 1G on this box.
<maswan> Oh, well. Going home now. I'll chekc in on that again when I get home.
<mdz> oh, we were on slashdot last night, explains the live CD spike
<mdz> "What precautions do these LiveCDs take to prevent damage from occuring to the installed base system? I trust Knoppix because I've used it a few times, but Ubuntu has a funny name, so I'm a little more wary of it."
<maswan> oh, btw, let me know how much a cdimage mirror takes (now and for the future) and we'll add it to the list of stuff we want to mirror here at ftp.acc
* lamont says hello to the letter 'C'
<Kamion> maswan: what, all of cdimage, not just releases.ubuntu.com?
<Kamion> (cdimage == stuff like daily builds too)
<maswan> Kamion: That was what I was thinking about, yes.
<lamont> mdz: new pcmcia-cs uploaded
<Kamion> cjwatson@little:~/cdimage/www/full$ du -s
<Kamion> 75773068        .
<Kamion> I should probably archive the old Sounder CDs
<maswan> For stuff like the livecd, hoary installs and so on.
<mdz> lamont: cool, I'll test on my laptop
<Kamion> it's nice to have them around for reference, but don't need them on cdimage.u.c
<maswan> Kamion: Expecting the size to more than double anytime soon?
<Kamion> maswan: you can expect a few gig of release images every six months
<Kamion> (I'm just zapping sounder-test now, down to 65GB)
<jdub> jbailey: can you tell cdbs to use autogen.sh instead of configure?
<maswan> Kamion: Ok. Thanks. We'll think about it. It's mostly an issue of disk space, something that is fairly hard to get donations for (unlike old servers etc).
<Kamion> maswan: hm, in fact a couple of GB every couple of weeks for beta-test images; but we'll archive those a while after release
<Kamion> I shouldn't expect more than double all that soon, no
<seb128> jdub: class/autotools.mk ?
* maswan nods and really heads home
<jdub> ooh, after upgrading udev, it has turned into a fork bomb!
<Mithrandir> jdub: .. useful
<jdub> seb128: DEB_CONFIGURE_INVOKE it seems to be - thanks!
<seb128> jdub: you too ? I just had to reboot
<seb128> load ~9 due to udev, no way to stop it
<seb128> and pitti is hidding :p
<mdz> thom: so what happened with the tracker overnight, and can we do something about it for next time?
<jdub> seb128: while true; do sudo killall udevd; done
<jdub> ;-)
<thom> mdz: it got slashdotted
<Kamion> mdz: if you've been having locale problems on the live CD, this might be why, actually; the casper/pre.d symlink change was one of the things dropped
<mdz> thom: which resource was starved?
<thom> mdz: it's now on a seperate box from cdimage/archive so should be less problematic
<mdz> Kamion: that explains some test results
<thom> mdz: /everything/ - auckland is at a load of ~800 current
<Mithrandir> thom: 800?  whoa.
<mdz> ah, so it wasn't the tracker that killed it
<thom> no, the tracker was still up, just toally unresponive
<jdub> seb128: DEB_CONFIGURE_SCRIPT, rather
<Kamion> mdz: 0.04.0ubuntu2 uploaded
<mdz> I was wondering how the tracker itself could have been overloaded
<mdz> I didn't realize it shared a machine with archive/cdimage
<Kamion> mdz: once it's built, could you trigger a new d-i build? I'd like tomorrow's CDs to have that fixed
<mdz> Kamion: yep
<mdz> me too
<Kamion> unfortunately I have to go to London in five minutes so I can't wait for it myself
<seb128> jdub: what are you trying to do ?
<mdz> Kamion: regarding getopt/reconfigure stuff, do you want to share the wrapper between casper and your questions-before-reboot stuff?
<Kamion> mdz: I only have one actual use for dpkg-reconfigure per se
<Kamion> mdz: but that would probably be sane, yes; put it in cdebconf-udeb?
<Kamion> mdz: or in debian-installer-utils if it doesn't need to link against libdebconf
<mdz> hmm, maybe we should talk about it later and figure out if there's actually a common need
<Kamion> di-utils binary package, probably
<mdz> it was going to be a shell script
<jdub> seb128: just using autogen.sh instead of configure, works now
<mdz> just to centralize all the environment variable hacks and such
<seb128> jdub: ok
<Kamion> mdz: ok, di-utils it would be then; shall we talk about it over the weekend when I get back?
<mdz> Kamion: yeah
<mdz> I'll just cut and waste for now
<Kamion> ok
<mdz> lamont: pcmcia-cs uploaded just recently?  I don't see it yet
<calc> jdub: hi
<Hwolf> I just had a major crash in hoary after using apt-get. Can anyone help me narrow it down?
<Hwolf> I started getting 'input/output errors' and after a minute or so x quitted, and had to hard-reset
<lamont> mdz: installed 20 minutes ago
<jdub> calc: you keen for a runtime-cpu-detecting libtheora patch?
<lamont> mdz: so blame slashdot
* calc on phone will have to talk about it later
<dilinger> Hwolf: check for kernel errors in /var/log
<dilinger> if there's anything useful, file a bug
<Hwolf> dilinger, i've never looked at /var/log in my life. Which file?
<Hwolf> *grumble* crash messed up my firefox profile. Exit bookmarks
* calc back
<thom> it was probably the new udev brokeness that jdub and seb both saw not so long ago
<Hwolf> Will you guys flame me if I ask how to get my firefox profile back?
<calc> jdub: sounds ok to me, will need to forward it upstream to make sure it doesn't break anything :)
<jdub> calc: this is happening on an upstream branch
<Hwolf> dpkg: failed to open `/var/lib/dpkg/status' for writing status information: Input/output error
<Hwolf> E: Problem executing scripts DPkg::Post-Invoke 'touch /var/lib/update-notifier/dpkg-run-stamp'
<Hwolf> E: Sub-process returned an error code
<Hwolf> E: Sub-process /usr/bin/dpkg returned an error code (2)
<jdub> so, who's on amd64 and ppc who could try these out for me?
<Hwolf> That's doing an apt-get upgrade
<calc> jdub: ah ok sounds good then
<mvo_> Hwolf: do you have the dir /var/lib/update-notifier/ ?
<Hwolf> hidde@system:~ $ ls /var/lib/update-notifier
<Hwolf> bash: /bin/ls: Input/output error
<Hwolf> Need a hard reboot to fix this.
<Hwolf> I cannot open any program or run any command line right now
<Hwolf> I'll be right back.
<dholbach> i'm off guys
<mdz> calc: also, we should et the new libogg (for amd64) in Ubuntu before feature freeze; if you don't think you will have time to update it in Debian, one of us can do it for Ubuntu (and upload to Debian as well if you want that)
<dholbach> have a nice evening
<mdz> s/et /get /
<trulux> tseng: :)
<Hwolf> mvo_, back
<calc> mdz: how long until feature freeze?
<mdz> calc: ~1 week
<calc> yea i will probably need someone to do it, i am going to be pretty busy this week (i think), just got a job today :)
<jdub> http://people.ubuntu.com/~jdub/hoary/ <- libtheora, please build+test on amd64 and ppc (yes, it needs autofoo related build deps)
<T-Bone> mdz: is ia64 still in line for hoary or is it too late already?
<tseng> jdub: ping me when you have a few minutes for tomboy?
<jdub> tseng: yes!
<tseng> jdub: i had some quick questions.
<tseng> thanks.
<jdub> oh, that was "yes! go for it" not "yes! wait your turn!"
<tseng> ok, sure
<tseng> http://getsweaaa.com/~tseng/tomboy/ < source is here
<tseng> the questions are about trying to get it past lintian
<tseng> it gives 2 errors about duplicate runtime deps, which are solved by cutting back to just ${net:Depends}, but im not sure how to verify quickly that it still has proper depends at that point
<tseng> the other error is about using an old Policy, which isnt very helpful at all
<sid77> hi
<dholbach> *GRRR* whats wrong here: 4070B/s
<mvo_> dholbach: slashdoted I think
<mdz> T-Bone: has it had a successful automatic install yet?
<kent> dholbach, the ubuntu server is very slow for me aswell, (if that is what your talking about..)
<T-Bone> mdz: we're very close to that
<dholbach> kent: yes :-)
<T-Bone> mdz: actually the fix made by Kamion this morning should enable me to make a full install on my zx2000
<dholbach> kent: but my connection is terribly slow all day now :-/
<T-Bone> mdz: there are some autodetection issues on some kinds of boxes tho, i'll work on that this week end. My main concern is the kernel stability. Seems that 2.6.10 is pretty much a hell on ia64 with hotplug/udev enabled/
<mdz> it sounds like we should be able to release something, but I'm not confident that we can stand behind it as an officially supported architecture at this time
<T-Bone> k
<T-Bone> mdz: basically i'd like to know whether i should put max effort into it (like a rush sprint) or if i can get some sleep at night :)
* mvo_ is away now to play some hockey
* T-Bone brb
<maswan> Mithrandir: 3M/s
<daniels> static char *_XkbKnownLanguages = "c=ascii:da,de,en,es,fr,is,it,nl,no,pt,sv=iso8859-1:hu,pl,cs=iso8859-2:eo=iso8859-3:sp=iso8859-5:ar,ara=iso8859-6:el=iso8859-7:he=iso8859-8:tr=iso8859-9:lt,lv=iso8859-13:et,fi=iso8859-15:ru=koi8-r:uk=koi8-u:th,th_TH,th_TH.iso8859-11=iso8859-11:th_TH.TIS620=tis620:hy=armscii-8:vi=tcvn-5712:ka=georgian-academy:be,bg=microsoft-cp1251";
<lamont> T-Bone: is it much better with 2.6.11?
* dholbach is away to do some serious learning
<daniels> dear XKB,
<daniels> DIE! DIE! DIE! DIE!
<daniels> cheers, daniel
<T-Bone> lamont: couldn't test that yet. It was much better with 2.6.8 that's for sure
<T-Bone> anyway, be back in a jiffy
* lamont lunches
<azeem> daniels: is there a chance xkb is actually gonna die?
<abelli> ogra: ciao
<tseng> heh, we lost jdub 
<Hwolf> Am I totally screwed up if the superblock of my xfs partition is gone?
<ogra> abelli: hi
<tseng> Hwolf: you certainly arent in a good position
<tseng> Hwolf: tried xfrepair?
<tseng> xfs_repair rather.
<Hwolf> tseng, yes, it won't find the secondary block. I'm talking about my root partition.
<abelli> ogra: hows the database?
<ogra> abelli: didnt do much during this week, just examining hal... too much MOTU work... but this weekend i'll play with hal patches...
<ogra> abelli: most of the stuff i need already exists....i just need to inject it in the right place....
<abelli> ogra: mmm... call it Hailie
<daniels> azeem: no, not at all
<daniels> azeem: it's better than the previous horror show we had.  it's just that ALL the code we have to deal with it in the free implementations is COMPLETE CRAP.
<ogra> Hwolf: use a livecd and read the manpage of xfs_repair very carefully...i have never seen a xfs you couldnt repair....even if it can be a pita
<abelli> ogra: didnt you see mine?
<abelli> :)
<ogra> abelli: i saw it....lets talk about a name if there is something to give a name to ;)
<ogra> abelli: ...and i wont rename hal ;) 
<azeem> daniels: ok, cool. Cause Debian GNU/Hurd is probably gonna use it to configure the console keyboard layout with it at some point, so I'd like to know whether our bets are off :)
<abelli> ogra: no i mean ... the b0rk3d xfs
<ogra> abelli: ah, ok
<daniels> azeem: you're what?!?
<ogra> abelli: nope, i didnt see yours...
<abelli> Hailie: Hardware Abstraction Injected Layer...
<ogra> hehe
<abelli> ogra: coz u need to inject the real Hal
<azeem> daniels: what's the problem?
<daniels> azeem: you do realise that the number of people on the planet who understand xkb is around the same as the number of people who have had a hojillion bajillion watts of power running through them and survived, right?
<ogra> abelli: if i make any real changes to hal i'll send them upstream....(even if its senseless, since hal 0.6 will be a total rewrite)
<daniels> i have enough of an understanding to solve most bugs and get by pretty well, which i acquired after of months of attempting to solve really hard xkb bugs.  only denis barbier, svu and ivan pascal actually understand the whole thing, and understand it well.
<ogra> OMG
<azeem> daniels: AIUI, there's an xkb driver for the Hurd console, which uses xkb keymaps and configuration options. I'm not sure the whole (or even parts) of the xkb codebase are involved
<ogra> did anybody read this ? http://news.bbc.co.uk/1/hi/england/london/4195339.stm http://www.boingboing.net/2005/01/27/jailed_for_using_a_n.html
<azeem> ogra: anybody who read /. ;)
<ogra> oh
<ogra> azeem: which doesnt include me :)
<daniels> azeem: that's absolutely scary
<azeem> in which way?
<azeem> I thought there was at least the suggestion to unite the console and X11 keyboard setup on Linux as well
<mdz> elmo: are extraordinary delays in archive processing to be expected at the moment?
<thom> ok, why does my cdrom drive get spun up every few minutes? just to check whether there's a disk in it? that's hella annoying
* ogra counts four on the CC agenda :)
<ogra> hmm, kaite remains pretty silent on me today....
<mdz> thom: minutes? dunno. the media check is every second or two
<ogra> but it shouldnt spin up....
<hidde> Guys. I accidentaly erased my /boot, I'm now running an ubuntu(warty) from my secondary harddisk. /root should be fine. How can I boot back into my /root (hoary) installation, can I just copy a kernel and piont it to the hoary /root?
<mdz> lamont: what archive do the d-i daily builds point at?
<mdz> lamont: and how can I tell when localechooser 0.04.0ubuntu2 is present there?
<rcaskey_> hidde; why don't you just reinstall the kernel package and run grub again
<mdz> hidde: this is not a support channel; please try #ubuntu
<hidde> mdz, sorry
<elmo> mdz: in terms of appearing on arrchive.u.c, yes
<mdz> elmo: more concerned about little and whatever the d-i builds use at the moment
<ogra> elmo: katie didnt answer the MOTU package i uploaded, could you look whats wrong ? (timer-applet)
<mdz> I think little just needs the rsync unlimiting treatment
<mdz> ogra: how long ago?
<ogra> 20-30 min
<ogra> it seemed ok to me....but probably i missed an error...
<elmo> ogra: you didn't use a whitelisted email in the Maintainer field
<elmo> mdz: I doubt it, but I can do that if you want
<ogra> ouch
<elmo> the load on auckland/mirnyy is 500-800 non-stop atm
<ogra> elmo: so signing MOTU candidate packages wont work ? i.e. i have to touch them ?
<elmo> ogra: if you want to get mail about them; yes
<ogra> heh
<ogra> ok
<ogra> elmo: is changing the address in the dsc and changes enough ? or do i have to rebuild the source package with a new changelog entry too ?
<elmo> ogra: change the address in the Maintainer field of the .changes
<elmo> i.e.  -m to 'dpkg-buildpackage'
<marcin_ant> mako: around?
<elmo> i'd hope you're at least test-building these packages anyway
<ogra> ah, great...easier then i thought 
<ogra> elmo: worked the last two days with the guy on it .... i made about 20 builds.... with this one too...
<ogra> elmo: i'm trying to avoid making errors twice ;)
<ogra> ok, next try...
<maswan> elmo: If you have load isses, want to try and offload it a bit?
<elmo> maswan: I already tried, but I'm being defeated by DNS caching
<elmo> and/or people using !cdimage urls
<maswan> elmo: How about http redirects for the iso downloads?
<elmo> hmm, that's a good idea, but I couldn't redirect them to cdimage.u.c, I'd have to use the real hostname or something, which'd suck if it's visible to the user at all
<maswan> elmo: cdimage-temp.u.c CNAME ftp.acc.umu.se and redirect to the first?
<maswan> or cdimage2 or something
<rubenv> Anyone knows if John Hornbeck is on IRC?
<ogra> rubenv: he is hornbeck if he is here
<rubenv> ogra: thanks
<rubenv> he deleted the part about dbus on the beagle page
<rubenv> but without dbus-sharp, it's quite hard to do beagle
<ogra> rubenv: there is a changelog...
<elmo> maswan: yeah, good point
<rubenv> I know
<rubenv> but as he maintains that page, i'd rather not revert it (given the fact that i don't like to build dbus from source)
<thom> rubenv: libdbus-cil is in universe
<rubenv> thom: really?
<rubenv> now that's new :)
<rcaskey_> ogra: something is still odd in there, it's possible to get beagle installed without getting all the deps for best
<thom> jdub should have beagle in universe by the end of the weekend anyway
<ogra> rcaskey_: i neither did change the page nor do i have installed beagle or use it ;)
<rubenv> jummy :)
<maswan> elmo: Well, I'm putting it up on ftp.acc now, I'll let you know when everything is there.
<ogra> elmo: gah...name collision
* thom &|
<jbailey> jdub: Sure.  Override the configure variable.  You're usually better off to force a call to autoreconf yourself at the beginning though.  Most autogen scripts are horribly broken and a mistake that for some reason can't quite be squished out.
<jbailey> jdub: Assuming you want to calling autogen with the same parameters as you'd call configure with, set DEB_CONFIGURE_SCRIPT = $(CURDIR)/$(DEB_SRCDIR)/autogen.sh
<jbailey> jdub: The extra variables preserve sanity for tarball.mk users.
<mdz> Mithrandir: ping?
<maswan> elmo: feel free to throw a thousand or so iso downloaders this way: http://ftp.acc.umu.se/mirror/temp/hoary/array-3.5-live/
<maswan> elmo: "temp" just means that it isn't properly updated or so, the files will stick for a month or two unless otherwise requested
<zul> uh is the archive overloaded?
<ogra> zul: why ?
<zul> its taking me 11 minutes to download perl-doc its usally faster than that...could be me
* ogra tries
<mdz> yes, it is overloaded
<zul> ok just checking
<mdz> due to slashdot, mostly
<ogra> whee...7k...
<zul> grr.
<ogra> mdz: wow...any statistics ?
<mdz> a fun statistic would be how long it's taking me to build new CD images: about 4 hours and counting
<ogra> woah
<zul> mdz: only? ;)
<ogra> i'm impressed that its still working fine...even if the speed is slow....great work elmo, thumbs up
<hidde> guys, is there any way to fix this:  failed to rmdir/unlink `/var/lib/dpkg/tmp.ci': Input/output error
<hidde> dpkg: failed to open `/var/lib/dpkg/status' for writing status information: Input/output error
<hidde> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<hidde> E: Sub-process returned an error code
<mdz> hidde: as I said earlier, this is not a support channel.  it is for development-related discussion.  you want #ubuntu
<sm> the topic could be worded more clearly actually
<sm> Ubuntu developers' channel | Note, for support and general discussion use #ubuntu instead... 
* ..[topic/#ubuntu-devel:sm] : Ubuntu developers' channel | use #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | Please test latest live CD: http://cdimage.ubuntu.com/releases/hoary/array-3.5-live/ (feedback to ubuntu-devel@lists.ubuntu.com)
<mako> marcin_ant: hey
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development channel | use #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<mxpxpod> is there any chance of getting gtkmm 2.5.5 and some other updated *mm packages into hoary?
<schweeb|work> mxpxpod: I'm guessing the best way to go about that would be to file a bug against the package in hoary, and give your reasons why you need the updated versions
<mxpxpod> schweeb|work: thanks
<abelli> yo everybody
<abelli> smurfix: ding
<maswan> elmo: so, have you fallen off the frontpage of /. yet and the load gone away, or can we expect some traffic this way? :)
<mdz> maswan: we left the front page a while ago
<mdz> but my bittorrent seed is still pushing over 2mbit, so I imagine there are still a number of folks downloading
<elmo> maswan: thanks for the offer, but I don't think I want to start trying to  modify apache now - the load's slowly dropping on archive.u.c, but even so interactive work is near impossible
<ogra> elmo: could you flush timer-applet from new ?
<maswan> elmo: sure
<marcin_ant> mako: hello
<mako> macewan: whats up
<mako> sorry
<mako> marcin_ant: whats up
<mako> macewan: nick completions, bah
<marcin_ant> mako: hi - nice to meet you
<mako> marcin_ant: likewise.. what can i help you with?
<marcin_ant> mako: smurfix told me that you can know something about website competition
<abelli> mako: time for docbooking me?
<marcin_ant> mako: I would like to ask if any previews of already submitted projects will be available?
<mako> marcin_ant: jdub is actually coordinating that
<marcin_ant> mako: hmmm 
<marcin_ant> mako: ok
<marcin_ant> mako: but maybe you know how much projects you already have?
<tritium> did the update to mozilla-firefox install change the default theme to this gnome-looking theme?
<tritium> I just purged mozilla-firefox-gnome-support, and it still looks gnome-like
<mako> marcin_ant: i know there have been a few.. i've only seen one
<mdz> tritium: /usr/share/doc/mozilla-firefox/changelog.Debian.gz
<tritium> mdz, thanks.  should have thought of that
<marcin_ant> mako: few... ok - if few (not thousands) then I'll submit mine 
<marcin_ant> mako: thank you for info
<mako> marcin_ant: not thousands, no. you should definitely submit yours
<YokoZar> Ok, i've heard something about the ia32-libs package - apparently if I include it in the 64 bit version of Wine, Wine will properly depend on the 32 bit libraries it needs to run 32 bit windows apps.  Is this right?
<tritium> mdz, so "enabling" gnomestripe theme blew away the old default, it seems
<YokoZar> The ia32 package doesn't have some things wine needs though, like 32 bit SSL.  What's the best way to handle this?
<lamont_r> YokoZar: it will include the 32-bit libraries needed to run say, openoffice.  not necessarily windoze apps..
<lamont_r> depends on what libs are there - it's nothing but the libraries from those libs
<lamont_r> s/libs$/i386 packages/
<ogra> did anyone see fabio today ?
<YokoZar> Is there a way to specify that Wine needs 32 bit versions of its dependencies (and both 32 and 64 bit on the 64 bit version) then?  Or do I have to create a 32bit wine libs package like the ia32 one?
<YokoZar> Or would the proper way to do it be to split up ia32 into what wine needs and doesn't, make a new package for what wine needs, and depend on two of them?
<tritium> thom, did you intend for gnomestripe to completely replace the default firefox theme?
<giskard> one ubuntu developer alive?
<mdz> all dead
<giskard> bad...btw...there are a kernel-package team for ubuntu?
<mdz> you should subscribe to ubuntu-announce :-)
<mdz> http://lists.ubuntu.com/archives/ubuntu-announce/2005-January/000014.html
<abelli> giskard: fabbione announced the kernel team today
<abelli> giskard: are you interested?
<mdz> smurfix: the LoCoTeamList page needs de-countrification
<abelli> ???
<abelli> mdz: is smurfix around?
<mdz> I don't think so
<abelli> mdz: can you define de-countrification?
<abelli> :)
<mdz> abelli: I just fixed it
<giskard> ciao * ;)
<abelli> mdz: sorry what page?
<haggai> crimsun: you have mail :)
* haggai enables the kubuntu lists
<ogra> do we have any known hungarians around who could sign a key for a new MOTU ?
<crimsun> haggai: thanks :)
* ogra still waits for elmos answer....
<mdz> abelli: don't worry about it
<abelli> mdz: no, its just because it was modifying it, and i stopped when you said you were modifying it tooo
<YokoZar> I'm packaging up a program written for Xdialog that is basically a bunch of scripts (no compilation needed) - what's a good example package with an easy rules file to copy?
<YokoZar> The bittorrent rules file is a bit weird
<mdz> ogra: please be patient and let elmo take care of your package in the next batch, along with any others
<mdz> abelli: <mdz> smurfix: the LoCoTeamList page needs de-countrification
<mdz> abelli: ^^^^^
<mdz> that page
<abelli> yeah.. i mean what does  "decountrification" mean? ;)
<ogra> mdz: ok... i thought he has just to remove it from new to enable me to upload....i dont want to be impatient...
<mdz> ogra: is the package new, or not?
<abelli> too many "mean"
<ogra> mdz: its new, but i didnt change the maintainer mailadress to mine in the MOTU candidate package....so the old one is blocking a fixed upload
<mdz> ogra: it is not blocking; you can upload a new version
<mdz> ogra: but if I understand correctly, you don't need to upload a new one
<ogra> mdz: i tried and katie rejected it : a file with this name already exists in the New directory.
<mdz> ogra: that means that you tried to upload the same version twice (don't do that)
<ogra> ah, ok
<mdz> what elmo was telling you was that you did not get email about it because of the email address that you used
<mdz> you don't need to make a new upload to fix it
<ogra> great... so it will get processed if elmo reviewed it and found it error free ?
<opi> smurfix: ping :)
<jdub> GOOOOOOD MORNING FREEDOM LOVERS
<opi> smurfix: could you remind me an address for a LoCoTeamLeaders mailing list
<opi> jdub: GOOOD NIGTH BEER LOVERS :P
<tseng> jdub: morning.
<opi> smurfix: ok, got it :)
<dholbach> re
<ogra> dholbach: hi
<T-Bone> fabbione: ping, just in case?
<dholbach> hai ogra :-)
<dholbach> now that's a nice email title: "Meet Singles With -Christian- Principles"
<jdub> oh man
<jdub> he's baaaaaaack!
<jdub> https://bugzilla.ubuntu.com/attachment.cgi?id=1207&action=view
<T-Bone> WTF?
<dholbach> jdub: which bug does this belong to?
<hidde> T-bone, my reaction exactly
<mdz> jdub: is sound juicer going to get better for 2.10?
<kent> jdub, who did that? :( its a bit evil to put pictures in bugzilla that dont belong :(
<mdz> just look at the bug
<dholbach> mdz: where do i get the bug number from the attachment id?
<jdub> mdz: what kind of better?
<mdz> jdub: for example, letting me specify quality settings
<mdz> jdub: or defaulting to using the CD-ROM device which has a disc in it
<mdz> jdub: or explaining what things like "Ogg Vorbis" and "FLAC" mean
<jdub> 1 and 3 will be solved when s-j shifts to audio profiles
<mdz> just little things that would make it more enjoyable to use
<jdub> 2 should just work
<mdz> so it's a bug that it doesn't on either of my machines here?
<jdub> i'm tempted to say "of course, because that's sensible behaviour and it didn't do what you expect", but i don't think you mean that ;)
<dholbach> jdub: what did you do about libtheora?
<jdub> dholbach: haven't had ppc test yet
<jdub> i'm assuming it won't work, however
<jdub> talking to andy about it
<dholbach> jdub: what about amd64? does it work now?
#ubuntu-devel 2005-02-09
<jbailey> jdub: I'm on a ppc, need something done>
<jdub> jbailey: http://people.ubuntu.com/~jdub/hoary/
<jdub> dholbach: no
<jbailey> jdub: How do I test it when I build it?
<jdub> mplayer -ao esd http://mirror.fluendo.com:8800/
<jbailey> We have mplayer?  Cool.
<jdub> well
<jdub> use totem :)
<jbailey> Will totem-xine pick it up, or should I switch back to totem-gstreamer?
<jdub> totem xine will be fine
<jdub> meanwhile, i am sad
<jdub> the latest gamin/inotify patch still does not work
<mdz> jdub: by "should just work", did you mean "is implemented", or "ought to be implemented"?
<jdub> but less spectacularly so this time
<jdub> mdz: should be is, but ought to be if not
<jdub> wouldn't be a hairy fix, given that it uses the libbacon stuff
<jdub> WOO!
<jdub> Setting up language-pack-zh-update (20050128) ...
<jdub> Setting up language-pack-zh (20050128) ...
<jdub> Generating locales...
<jdub>   en_AU.UTF-8... done
<jdub>   zh_CN.UTF-8... done
<jdub>   zh_HK.UTF-8... done
<jdub>   zh_TW.UTF-8... done
<jdub> Generation complete.
<jdub> 
<jdub> :-)
<jbailey> China gets Australian English? 
* jbailey hides
<jbailey> jdub: checking for sdl-config... no
<jbailey> jdub: Bad build-dep?
<jdub> jbailey: should say it doesn't care about sdl too
<jbailey> Yeah, just making sure you ahadn't missed something.
<jbailey> FAils to link.  Want me to /msg you the failure?
<jdub> nah
<jdub> that's okay
<jbailey> Something has a bunch of symbols with i386 hardcoded in them.
<jdub> yeah
<YokoZar> my0 kqweyboasrdasg0 juasdt0 gbrokqwe0 iasd0 thweqrqweg0 san 0on0 asdzxcerqweqwen0 kqweyboasrsda
<bluefoxicy> ping
<mdz> elmo: can you byhand the d-i build I'm about to do?
<T-None> huh. FtC has gone down
* robertj is back
<lamont> mdz
<lamont> around?
<lamont> "1027x768 @ 61hz will make me go bonkers, and I'm sure my hardware supports better."
<lamont> go warty!!
<ogra> lamont: at least better the 800x600 @ 50Hz
* dholbach always liked the expression "to go bonkers"
<lamont> yeah
<mdz> lamont: yes
<lamont> "Well, that was the least-effort Linux install I've ever done (even a base Debian install for requires a little bit more, like skipping past dsesect, etc)."
<mdz> source?
<lamont> former co-worker
<lamont> he got a warty CD set today, I believe
<lamont> he's also the source on that 1027x768 comment...
<lamont> so I'm asking for xresprobe and ddcprobe output..
<mdz> lamont: can you confirm that localechooser 0.04.0ubuntu2 made it into d-i- 20041227ubuntu7.0.200501281 ?
<mdz> (initrd.list)
* lamont goes to look
* ogra watches his GF diong her fist warty install completely on her own.... she wants plone !
<lamont> mdz: any particular arch, or do I need to check all 3 or 4?
<mdz> the I'll mail elmo and Kamion so that they can finish up when they come back around
<mdz> lamont: localechooser is arch: all, so if one has it, they all should
<dholbach> ogra: :-)
<ogra> dholbach: yay....
<ogra> dholbach: suse finally goes for CMS after years of html css fiddling
<lamont> mdz: yep.
<lamont> Get:23 http://jackass.ubuntu.com hoary/main/debian-installer localechooser 0.04.0ubuntu2 [61.1kB] 
<dholbach> ogra: i can fully understand that :-)
<lamont> mdz: as it currently sits, the livecd rootfs and debian-installer daily builds happen at the same time on diff machines.  do we need to shuffle things around at all? (/me thinks not...)
<mdz> lamont: thanks
<mdz> rootfs. vs. d-i doesn't matter, as long as ISO builds happen after both
<mdz> not that the d-i build goes into the archive right away anyway...
<lamont> my builds happen at 0615, and take ~30-40 minutes.  the ISO builds happen (IIRC) at 0800, so we're golden
<lamont> although given elmo's schedule, I rather expect that we're always building the ISO with the prior day's d-i build... :-)
<mdz> yeah
<lamont> does anyone know why my machine thinks it's fqdn is 'localhost.localdomain'?
<ogra> lamont: sounds like debian...
<dholbach> lamont: mine did too
<lamont> hehehe
<lamont> dholbach: what exactly do you have in /etc/hostname?
* lamont fixed his machine
<lamont> it doesn't like to have an FQDN in /etc/hostname
<lamont> whic his a bug, in my opinion...
<dholbach> lamont: now is says "bert" :-)
<lamont> hrm..
<lamont> iirc, the code says that when it can't figure out what to say
<dholbach> lamont: i fixed it quite a while ago
<jordi> Treenaks: heh, I just noticed you were the initial maintainer for gtranslaor
<jordi> gtranslator even
<dholbach> binary-or-shlib-defines-rpath  is finishing me off :-/
<thom> jdub: claims on the dashboard list we need a newer gsf-sharp
<dholbach> ok... 1:0 to lintian... but i'll re-appoint the match :-)
<dholbach> good night everyone... i'm off
<zul> hey
<eruin> why oh why are we receiving a broken firefox with the GNOME icon theme in hoary?
<thom> broken how?
* eruin mumbles never mind me
<eruin> a restart was in order
<eruin> but are the gnome icons there to stay? they aren't exactly as snazzy as the default ones
<thom> no, but they are consistent
<thom> point being it actually looks and feels like it's meant to be on the desktop, rather than just bolted on after
<bluefoxicy> has anyone seen pitti lately?
<eruin> I thought the whole idea behind the new firefox theme was to make it look integrated in both windows, gnome and osx ?
<schweeb> eruin: the icons match the ubuntu desktop
<eruin> that theme sure didn't look bolted on, but I'm sure you guys have already had a long discussion about it
<schweeb> eruin: if you don't like the theme, you're able to use one of your choosing
<thom> it's not the same theme on windows and osx anyway
<thom> but, shrug
<thom> we'll let people say what they think; if there's consensus that we shouldn't do it, odds are we won't
<thom> as it stands i think it looks a hell of a lot better
<eruin> atleast provide the standard ff theme in addition
<eruin> that theme isn't available for download anywhere, and the theme manager in ff still says firefox (default) by gerich
<schweeb> thom: man, gnome file dialogues now, that's nice
<eruin> yeah, that's great stuff :)
<thom> eruin: patches cheerfully accepted
<schweeb> thom: and complaints cheerfully ignored, eh :p
<thom> schweeb: not at all
<eruin> I doubt my php/html/css skills will be very useful in that regard
<thom> schweeb: i have a list of bugs as long as my arm; if something is not a priority i'll do it if i can but if someone gets there first great
<thom> complaints without patches just rank lower than those with :-)
<eruin> :-)
<elmo> mdz: done
<bluefoxicy> !seen pitti
<bluefoxicy> guess not
<zul> thom: i thought that sudo patch wouldnt work properly
<jbailey> Wow.  nfs root actually works.  Creepy.
<thom> zul: yeah, it's unfortunate that it's not that easy
<thom> but it's fixable for new installs; old ones will just have to cope
<zul> yep
<thom> g'night
<zul> night
<mdz> elmo: thanks
<zul> goody...i have slmodem almost working in linux-restricted
* lamont bbiab
<mdz> lamont: have you tried hoary-live-ia64.iso yet?
<zul> night..
<thully> I just noticed a significant bug in the live CD's network configuration process
<thully> I have a laptop w/ethernet and wireless - if i'm not connected to ethernet and not in wireless range, the CD keeps prompting me for a WEP key until I back out and skip the network step in debian-installer
<thully> that causes the loopback interfance not to be configured, and things not to work right as I reported in a previous bug
<thully> hi - one quick question - can I label a live CD bug "critical" or "blocker" if it is critical or blocker for the live CD release and not for the standard release?
<thully> As this issue with wi-fi on the live CD seems critical for the live CD - we don't want to be shipping a live CD which doesn't work right without a network
<farruinn> does this sound normal: I'm building gaim from ubuntu source package, I ran dpkg-buildpackage -rfakeroot, and it goes through the ./config process but when that finishes I get a message saying automake-1.8 is too old. It's not a fatal error though because ./configure runs again and apparently successfully because now it's compiling...
<farruinn> I did sudo apt-get build-dep gaim before doing this then double checked that everything was up to date, and it is
<syn-ack> farruinn: sounds like a bug in automake, or maybe a bug in the .config file...
<farruinn> this is warty btw
<farruinn> no backports or anything unusual
<syn-ack> My question is this.... why build if its in the repo?
<syn-ack> still it more than likely is a shoddy .config 
<syn-ack> or makefile.
<farruinn> guifications needs gaim.pc which debian/rules deletes after install
<crimsun> hmm. Isn't that packaged in gaim-dev?
<infinity> farruinn : Sounds like timestamp skew to me.
<syn-ack> infinity: could be that too
<infinity> farruinn : See /usr/share/doc/autotools-dev/README.Debian
<farruinn> crimsun: I did apt-cache search gaim-dev but didn't find anything
<infinity> That'd be because there isn't a gaim-dev.
<infinity> Perhaps there should be. :)
<syn-ack> aye, there should..
<crimsun> right, it's in hoary/universe, and farruinn's using warty.
<syn-ack> I think Im going to build a .deb of gaim 1.1.2 and check it out. heh
<infinity> Ahh, I see.  gaim-dev is brand new.
<farruinn> apt-get source gets exactly the same source that was used to build the binaries available through apt, right?
<infinity> No.
<infinity> apt-get source will get the most recent source listed in your deb-src lines.
<crimsun> farruinn: correct [if you use strictly the warty repo] 
<lamont> mdz: download speed has been rotten today - planning to make another run at it tomorrow.
<crimsun> (btw, you can force apt-get source gaim=someversion)
<lamont> I know that someone tried it (ia64live) today, and had no happiness on that particular machine - didn't detect the CDROM
<lamont> firefox-bin(8312): unaligned access to 0x0000000042a86c74 at ip=0x0000000042a31b9b
<lamont> firefox-bin(8312): unaligned access to 0x0000000042a86c7c at ip=0x0000000042a31bbb
<lamont> firefox-bin(8312): unaligned access to 0x0000000042a86c84 at ip=0x0000000042a31bcf
<lamont> bad firefox
<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 grumbles at thom
<YokoZar> Would it be wrong to have a script in /usr/share/package and then symlink it in /usr/bin ?
<syn-ack> that sounds wrong to me. What would be your purpose for that?
<YokoZar> I'm trying to make a package around what is basically glorified Xdialog scripts, and I'm not sure where to put them
<YokoZar> http://www.von-thadden.de/Joachim/WineTools/
<YokoZar> syn-ack: Where should such scripts go?
<lamont> --- SIGRTMIN (Unknown signal 37) @ 0 (0) ---
<farruinn> would deb-make give me a debianized source suitable for ubuntu?
<lamont> interesting
<YokoZar> Oh I see share is only for read only stuff
<syn-ack> YokoZar: I personally just place them in /bin
<YokoZar> Yeah I think that's the right FHS way
<syn-ack> or /usr/bin/
<YokoZar> (reading it now)
<YokoZar>  /usr/bin is right ;)
* syn-ack just hit a trip point while compiling and his system shut down.
<syn-ack> heh
<farruinn> dpkg-buildpackage shouldn't touch anything outside the source dir, no?
<farruinn> I was running it on guifications source and it tried this: "mkdir -p -- /usr/share/pixmaps/gaim/guifications/conf"
<YokoZar> hmmm...sounds like a bad behaving package
<farruinn> well, I debianized it myself so it's not surprising
<farruinn> I've read the debian new maintainers guide, but I don't know what to do about this
<YokoZar> Directories should only be made by dh_installdirs when it reads a file
<Mithrandir> mdz: pong
<YokoZar> farruinn: you need some files like (package.dirs) that have the directories you need made for you in them
<YokoZar> then dh_installdirs will create them when it gets to that part in the rules file
<farruinn> in debian/tmp, right?
<YokoZar> Yeah
<farruinn> excellent, thanks =)
<syn-ack> hrm
<YokoZar> Is there a standard for what goes in /usr/share/pixmaps?
<sivang> morning all
<Mithrandir> heh, I've pushed out about 40GB of live CDs since last afternoon.
<zenrox> who here can help in #ubuntu have a prob with a user
<zenrox> he pasted a long past and i had ask him to please use pastbin.com  and then he just put me on ignore
<zenrox> witch is ok
<zenrox> but the long past was wrong
<YokoZar> What does dh_installexamples do?
<Mithrandir> zenrox: if it was a one-time thing, ignore it.
<crimsun> YokoZar: see the appropriate debhelper man page ;)
<Mithrandir> zenrox: if he continues to be obnoxious, see if mdz is around.
<crimsun> YokoZar: essentially, it installs [a hierarchy of]  example file
<zenrox> Mithrandir,  ok
<YokoZar> crimsun: I guess my question is why it's uncommented by default when I made my package
<crimsun> YokoZar: a great many of the debhelper templates are uncommented by default :)
<YokoZar> Also should I remove the changelog file from the docs file?  It was put in there automatically
<YokoZar> As it's handled instead by dh_installchangelogs
<crimsun> yeah, I never have changelog in .docs
<YokoZar> Also if I remove a file from a source package will I have to remove it again when I do uupdate?
<crimsun> when you run dpkg-buildpackage, it generates a .diff.gz, which is applied to the new upstream version when you run uupdate
<Mithrandir> but it ignores deletions.
<crimsun> right
<Mithrandir> YokoZar: why do you remove the file from the package?
<YokoZar> Mithrandir: It was a binary version of Xdialog (instead I depend on xdialog package and use that)
<Mithrandir> YokoZar: ok.  You could ask upstream to remove it, though.
<Mithrandir> and you can just remove it in the clean target and ignore the warning from dpkg-source
<YokoZar> That could work but it would make the package needlessly larger, heh
<YokoZar> Well, the source package
<Mithrandir> you need to remove it from the original .tar.gz if you don't want the bloat there
<fabbione> wow
<YokoZar> Oh yeah I see
<YokoZar> Ok, putting a thing into dh_clean
<fabbione> i slept almost 24 hours
<Mithrandir> hi fabbione
<fabbione> hi Mith
<daniels> fabbione: awesome :) 'morning
<YokoZar> People thought you were dead fabbione
<YokoZar> Although, in a way, you were.
<crimsun> 24 is superhuman :)
<fabbione> daniels: there is nothing awesome in having 39/40 of fever :(
<Mithrandir> fabbione: _ew_
<Mithrandir> YokoZar: just rm -f path/to/xdialog in the clean target should be ok
<fabbione> i got a big flu i think
<fabbione> anything important happened?
<daniels> fabbione: ouch :( that's a horror
<daniels> fabbione: fglrx is totally brken, but news at 11
<fabbione> enocare
<fabbione> :)
<daniels> right :)
<YokoZar> Thanks Mithrandir
<fabbione> i think i am back to bed
<crimsun> ciao
<YokoZar> Sleep well.  We'll boil some chicken hearts and newt eyes to help you get well.
<Mithrandir> fabbione: get well
<fabbione> eheh
<fabbione> thanks guys
<fabbione> i might see you on monday
<sivang> YokoZar: this is some kind of chineese tradisiont? ;-)
<YokoZar> sivang: Voodoo, actually.
<sivang> YokoZar: hehe , ok :)
<dholbach> morning
<sivang> dholbach: morning
<YokoZar> Is there a package out there that doesn't actually compile anything (ie: just copies files) that I can look at?
<sivang> YokoZar: if you want to achive that, you need to use dh_install
<YokoZar> I'm trying to figure out a good rules file that doesn't confuse the hell out of debhelper
<Mithrandir> YokoZar: don't use debhelper for the install part there, then.  Just cp stuff into the correct directories in debian.
<sivang> YokoZar: and in the /debian folder, you need to have a file named <pkg-name>.install and list all the files you want to install and to where.
<YokoZar> Well I have a bunch of cp stuff...the trick is figuring out the correct directories
<sivang> YokoZar: well, what are you trying to copy?
<YokoZar> At that part of the rules file it looks like I should be putting them into debian/tmp/usr/bin/ and such
<YokoZar> but there is no tmp directory
<sivang> tmp is created IIRC Only when dpkg attempts at building the sources
<sivang> (or the stuff needs built in the pkg)
<YokoZar> Or, rather, it isn't created by buildpackage then
<YokoZar> Since I have the thing commented out I guess
<Mithrandir> YokoZar: make it, either with mkdir or dh_installdirs.
<YokoZar> And copy the files into the tmp folder then?
<Mithrandir> yeah, or debian/$packagename/$wherever.
<YokoZar> Can I have dh_installdirs do it and prepend tmp/ to the front?
<dholbach> hai sivang :-)
<sivang> YokoZar: no, you can leave the files inside the /debian folder, use dh_installdirs to create the dirs you need, and dh_install to read your pkgname.install file and copy files where needed.
<sivang> dholbach: yo danile, 'sup?
<Mithrandir> YokoZar: dh_installdirs knows where it should make the directories, so don't worry about debian/tmp and such.
<YokoZar> Well what it's currently doing is making debian/package
<YokoZar> And I can copy my files into package/usr/whatever
<Mithrandir> sivang: dh_install installs the files from the tmp tree into the right directories, it doesn't copy them from the source package.
<Mithrandir> YokoZar: yes
<YokoZar> Then when it gets to dh_install -s I get this error:
<YokoZar> cp: cannot stat `./usr/bin': No such file or directory
<dholbach> sivang: i'm trying to package a more recent version of glibmm, but i stumble over binary-or-shlib-defines-rpath
<Mithrandir> YokoZar: don't use dh_install for what you are trying to do, it's the wrong tool.
<YokoZar> Oh ok then
<dholbach> so is anyone of you familiar with  binary-or-shlib-defines-rpath  and  -rpath  being used by Makefiles? there's a huge thread (at http://lists.debian.org/debian-mentors/2002/02/msg00042.html) and people seem to me not to be sure if such a lintian warning was worth messing around with a proper compilation/installation of a library
<Mithrandir> YokoZar: this is fairly basic stuff -- have you read debhelper(7) and the debian new maintainer's guide?
<YokoZar> Yeah I have I've even made the wine packages...I guess by not knowing exactly when dh_install was getting called
<Mithrandir> dholbach: are you using DESTDIR when installing?
<sivang> Mithrandir: it can be used for a couple of file installment no?
<sivang> Mithrandir: (would like to know if I am using the wrong tool ;-)
<dholbach> Mithrandir: yes, it's in most of the Makefiles
<YokoZar> ok I commented out dh_install
<sivang> Mithrandir: it allows me to add how many files that I would like on the .install file, and relieves me from acutally changing the make rules in debian/rules...
<Mithrandir> sivang: it seems you can use it both ways.
<sivang> Mithrandir: could you elobrate? I am not sure I have followed you...
<sivang> *elaborate
<YokoZar> That's odd it didn't ask for my key or anything but spat out a .deb file
<Mithrandir> sivang: read the man page rather than listening to me. :)
<sivang> Mithrandir: okok, mang pages were cool with dh_install so, nm ;-))
<Mithrandir> dholbach: hmm, I seem to have participated in that thread. :)
<dholbach> Mithrandir: yes... and you (as infitiny@#debian-devel) told me something about chrpath, but i'm not sure, if that's of anyuse
<Mithrandir> dholbach: you could just do chrpath -d $binaryname
<Mithrandir> but I wonder why it gets set; can you put your package online somehwere?
<Mithrandir> s/somehw/somewh/
<dholbach> Mithrandir: seems to me that a standard Makefile (for a library) spitted out by auto* uses -rpath
<dholbach> at least it also did in a library, i coded myself
<Mithrandir> not necessarily.
<dholbach> Mithrandir: in the current state the package doesnt build because the linker is confused :-)
<Mithrandir> ok, tell me when you have unconfused it and I can take a look, then
<dholbach> Mithrandir: brilliant :-)
<sivang> Mithrandir: is there a counterpart for dh_install ? I want to be able to remove the files my package put so I won't get a dpkg error when it tries to remove the dir
<dholbach> erm... cool :-)
<dholbach> :-D
<dholbach> libtoolize --force --copy   and the    debian/rules-libtool-is-a-fool--hack   did the trick
* dholbach bounces around Mithrandir happily
<Mithrandir> dholbach: libtool-is-a-fool shouldn't be needed any more -- try without it and see if it works.
<dholbach> Mithrandir: ok
<Mithrandir> sivang: uhm?  I'm not sure I understand what you are talking about
<sivang> Mithrandir: I have used dh_install to install a couple of files into /etc/pkgname
<sivang> Mithrandir: when I remmove the package (purge) I get an error that dpkg couldn't remve the dir because it is not empy, which is right :)
<dholbach> Mithrandir: now i get those lintian-warnings again
<Mithrandir> sivang: uhm, if you install stuff to /etc/pkgname, it's marked as a conffile and dpkg should DTRT when purging the package.  If you can provide the package in question, it's probably easier to see what's going on
<YokoZar> Would it be ok to have symbolic links in /usr/share/package to /usr/bin ?  The scripts that I'm packaging are kinda screwy that way
<Mithrandir> dholbach: hm.  If I may, I'd like to take a look at your package.
<dholbach> right
<Mithrandir> YokoZar: sure, why shouldn't it be ok?
<YokoZar> Because /usr/share is for read only non-executables
<smurfix> YokoZar: a symlink is not an executable. ;-)
<YokoZar> Yeah but what if someone had /usr/share mounted with no execute
<YokoZar> As he is supposed to be able to do
<smurfix> YokoZar: ... though I might suspect that the stuff belongs in /usr/lib if it wants to exec from there
<YokoZar> Wouldn't trying to run a symlink there barf?
<smurfix> YokoZar: I don't know offhand if symlinks are followed before that test
<smurfix> YokoZar: let me check
<Treenaks> jordi: yeah, a long long time ago :)
<smurfix> YokoZar: no, that works
<YokoZar> So I can have the symlink?
<dholbach> Mithrandir: http://moz.gotdns.org/ubuntu/
<smurfix> YokoZar: as I said, it might want to live in /usr/lib instead, but in principle, yes
<sivang> smurfix: Moins :)
* dholbach heads to the shower
<sivang> Mithrandir: on my way, will send you a link in a momnet.
<sivang> Mithrandir: http://sivan.workaround.org/gnome-system-tools_1.1.90-0ubuntu1_i386
<sivang> Mithrandir: did you get my last msg to you?
<dholbach> Mithrandir: wb
<kagou> hi
<dholbach> hi kagou
<abelli> smurfix: ping
<smurfix> abelli: 
<abelli> smurfix: what was it?! ;) i can't read
<smurfix> that's a chinese character. "pong".
<abelli> smurfix: wow ;)
<abelli> smurfix: did you receive the email?
<dholbach> Mithrandir: did you receive the link before you flew out?
<smurfix> abelli: seems not
<dholbach> Mithrandir: http://moz.gotdns.org/ubuntu/glibmm2.4-2.4.5/ (to make sure ;-))
<smurfix> abelli: .. which could mean that I deleted it accidentally :-/
<abelli> smurfix: im forwarding it..
<sivang> Mithrandir: are you back?
<dholbach> sivang: idle:32 minutes :-)
<sivang> dholbach: yeah :) I wonder where he vainshed ;-)
<dholbach> sivang: gives me time to get some appropriate webspace :-)
<dholbach> sivang: i only have 16K/s upstream :-)
<abelli> smurfix: you, should probably, have mail ;)
<sivang> dholbach: hehe, I have 128Kb upstream now, had 96 in the past..
<dholbach> sivang: bit or byte? :-)
<dholbach> Mithrandir: ok... once the upload finished (some minutes), it's all on http://ubuntu.stufenseite.de
<sivang> dholbach: errr, bits :)
<dholbach> sivang: yes... me too :-)
<sivang> dholbach: we'd wish we had Mithrandir *fast* net access :)
<YokoZar> Can someone test a package for me?  It creates a working build, but it never asks me for my password to sign the key file (make has a weird error at the end)
<YokoZar> deb-src http://tuzakey.com/~scott/apt/ source/
<YokoZar> package name winetools
<dholbach> sivang: i rather wish, i'd finished the exam next week and my thesis :-)
<YokoZar> Mithrandir: ping
<dholbach> poor mithrandir... 3 people hopping around him :-)
<YokoZar> Heh, it's the price you get for being helpful and knowledgable :)
<YokoZar> On a Friday night, no less
<dholbach> it's saturday morning ;-)
<dholbach> and i must be off - revision for an exam :-/
<dholbach> so have a nice day, you all
<dholbach> see you later
<Kaloz> morning
<sivang> Kaloz: morning 
<jdub> thom: we *have* gsf-sharp? :)
<thom> apparently
<jdub> $ apt-cache search gsf cil | wc -l
<jdub> 0
<jdub> $ apt-cache search gsf sharp | wc -l
<jdub> 0
<sivang> seb128: Morning :)
<seb128> hello
* T-Bone waves around
<sivang> seb128: you know anything about a g-s-t bug which display the postfix, had, dbus usernames in the user editor?
<Hwolf> Is there any bug known that can cause I/O errors when doing a dist-upgrade?
<seb128> sivang: no idea on what you are talking about
* T-Bone looks for someone with d-i/initrd knowledge (Kamion, fabbione?)
<Mithrandir> Hwolf: hardware errors.
<Mithrandir> T-Bone: what's the problem?
<Hwolf> Mithrandir: I doubt it. I got it dist-upgrading 2 ubuntu-installations yesterday. On 2 different hdd's
<T-Bone> Mithrandir: well, I'm having some issues with zx6000: the MPT fusion drivers isn't properly loaded:
<Mithrandir> Hwolf: same machine or different machines?
<T-Bone> Mithrandir: mptbase gets loaded, but not mptscsih, so that d-i doesn't see any SCSI host, and thus no disk on the box
<Mithrandir> T-Bone: loading it by hand works?
<T-Bone> yes
<sivang> Mithrandir: I don't reckon you recived my link before you were diconnected?
<Hwolf> Mithrandir: same machine, different hdd's
<Mithrandir> sivang: can't see any, no.
<Mithrandir> Hwolf: well, bad memory, bad motherboard, stuff like that.
<Mithrandir> T-Bone: sounds like the discover data files might need updating.  Do you know if it's autodetected by hotplug?
<jdub> hrm, you guys know of any p2p vpn technologies?
<jdub> (stressing the P in VPN, not necessarily security)
<T-Bone> jdub: freenet?
<Mithrandir> jdub: OE+IPSec?
<Hwolf> Mithandir: Isn't it odd that it happens only on a hoary-dist-upgrade?
<T-Bone> Mithrandir: that info can be found in the installer logs?
<Mithrandir> Hwolf: wrong, you have only seen it happen in that particular case.  :)
<Mithrandir> T-Bone: I'm not sure if the installer uses hotplug, which is why I'm asking.
<T-Bone> yeah iirc it uses discover
<Hwolf> Mithrandir: Compiled gentoo on this box without faults, I think it'd have shown up...
<Mithrandir> you can use both, I know it uses discover.
<Mithrandir> T-Bone: I was the guy developing d-i for a long time. :)
<Mithrandir> Hwolf: true.
<T-Bone> Mithrandir: since i have not installed that box yet (and not yet willing to do so) it's gonna be hard to tell
<T-Bone> Mithrandir: hehe, just noticed who you are, thanks to /whois ;)
<Mithrandir> T-Bone: what's the PCI ID of the card?
<jdub> Mithrandir: needs to be a private network, not very interested in encryption; OE ends up being a bit useless there ;)
<T-Bone> Mithrandir: hold on, the box is booting.
<jdub> T-Bone: hrm
<jdub> T-Bone: where would i find out more?
<T-Bone> www.freenet.org iirc
<jdub> ta
<Mithrandir> jdub: you could just use ip tunneling.
<jdub> Mithrandir: mmm, considering it
<jdub> Mithrandir: sorry for doubling up your sounder mail, btw, was replying as you8rs arrived
<Mithrandir> jdub: ip tunneling and possibly do RIP or OSPF on top of it.  I don't know what complexity you are talking about.
<T-Bone> jdub: it has moved to freenet.sf.net
<Mithrandir> jdub: ah, I guess he's just happy about two answers.
<Mithrandir> :)
<jdub> T-Bone: hrm, doesn't sound appropriate ;)
<jdub> so the idea is
<jdub> to have a vpn across the 'net that our xboxes are attached to
<jdub> and possibly dual-use it for private sharing fun
<T-Bone> tunneling is what you want then
<jdub> seems to be the simplest approach
<abelli> whata about tunneling..yeah..
<T-Bone> add a bit of IPSEC for security and you're there
<jdub> security is for people who have something to hide
<Mithrandir> jdub: normal static ip tunneling is dog simple to set up, at least as long as you don't want this to suddenly become a mesh or something.
<jdub> ;-)
<Mithrandir> I should get ipsec up and running on my home net
<jdub> Mithrandir: that's where it breaks down; i predict that being the next step
<T-Bone> hehe
<jdub> and i don't really want all the data going through a central host
<Mithrandir> jdub: daisy-chain?
<jdub> pretty breakable ;)
<Mithrandir> that's also fairly simple, as long as the chain's not too long.
<T-Bone> Mithrandir: come to think of it: there's no way hotplug would _need_ to detect mptfusionh:
<Mithrandir> T-Bone: mhm?
<T-Bone> Mithrandir: the box _can't boot_ if that driver isn't preloaded by the initrd
<T-Bone> (or builtin the kernel)
<Mithrandir> T-Bone: ah, makes sense.  Kindof.  Discover's data files should possibly just be updated, then.
<T-Bone> Mithrandir: PCI ID: 20:01.[01]  SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
<T-Bone> (there are two of these)
<T-Bone> Mithrandir: if you tell me how to do that, I'm ok to do it :)
* T-Bone is clueless WRT discover and friends
<Mithrandir> T-Bone: look at the /usr/share/discover/pci-26.lst file; The format is fairly self-explanatory.  That is generated from somewhere, but I don't remember where offhand.
<Mithrandir> jdub: look at mobilemesh?
<T-Bone> k. lemme boot a ubuntu box :)
<jdub> Mithrandir: looking...
<Mithrandir> jdub: I think it might be appropriate, but I've never used it myself.
<Mithrandir> seems like it was written for 2.2, so it might need a bit of brushing-up.
<ogra> mrning
<Mithrandir> jdub: if you could rely on a single host as a coordinator (not traffic point), you could probably whip something up.
<Mithrandir> hiya ogra 
<Kaloz> hi ogra 
<ogra> Kaloz: hey mr MOTU :)
<ogra> Mithrandir: hi
<Kaloz> :)
<T-Bone> Mithrandir: there is alas one big issue on ia64: 2.6.10 seems to hate udev/hotplug :P
<T-Bone> (or the other way around)
<Mithrandir> T-Bone: that sucks. :)
<T-Bone> indeed :)
<ogra> does anybody know if gparted is making it into sid soon ? i'm just updating the UniverseCandidates page to give some MOTU suggestions...
* ogra whishes his xkb would behave a little nicer ...
<sivang> Mithrandir: would you be in for checking my pakcage? I ahve it online now
<Josephus> hey
<sivang> ogra: hi 
<ogra> sivang: hey ;)
<sivang> ogra: 'sup?
<Mithrandir> sivang: url?
<sivang> Mithrandir: sec
<sivang> Mithrandir: http://sivan.workaround.org/gnome-system-tools_1.1.90-0ubuntu1_i386.deb
<Mithrandir> I need the source package -- the binary package is uninteresting. :)
<sivang> Mithrandir: ah ok :) How do I create a source package from my modified source tree?
<Mithrandir> debuild -S
<ogra> sivang: debuils -S
<ogra> oops
<sivang> Mithrandir: ok , tnx
<sivang> ogra: tnx you too
<sivang> :)
* T-Bone wonders why he gets unreadable chars in the output of man from a ubuntu box over ssh ;P
<sivang> Mithrandir: building..
<T-Bone> Mithrandir: who should I send the patch to? :)
<sivang> Mithrandir: how do I tell it to not try sign the pkg? -ns ?
<sivang> Mithrandir: (I don't have the key at hand)
<Mithrandir> T-Bone: have you tried it yet?
<Mithrandir> sivang: -us
<sivang> Mithrandir: tnx
<T-Bone> Mithrandir: that's the other question: how should i test it?
<seb128> sivang: 1.1.90-0ubuntu1 is already in the archive, better to change the number if you make changes
<sivang> seb128: yes I know, I am just experimenting without dch'ing
<Mithrandir> T-Bone: build a new initrd with the fixed list.
<sivang> seb128: btw, the "bug" I was referring was a strange behavior as I noted, however it may be specific to my system, I hope Mithrandir has a free box to try my crack on see if it also shows him some of the "system" users rather then only the interactive ones.
<seb128> sivang: if you don't describe the bug in a better way ..
<T-Bone> Mithrandir: the easier way is to look at debian's discover data and notices that it has much more stuff than we have, including the patch i was considering
<Mithrandir> T-Bone: hm, ok.  Prod Kamion about it, then?
<T-Bone> Mithrandir: seems we need to update our data
<thom> seby seb! nautilus is doing odd stuff
<T-Bone> Mithrandir: yup, will do
<Mithrandir> thom: of course, it's _nautilus_.
<thom> Mithrandir: weirder than usual
<Mithrandir> thom: it's saturday.  And it's before noon (for you).  Obvious you'll have it do weirder odd stuff than usual.
<Mithrandir> s/Obvious/&ly/
<T-Bone> mail sent to Kamion
<Mithrandir> it was probably out drinking last night
<sivang> seb128: ok, when you just fire up users-admin you get to see only interactive users right, it's not showing you all the system internal use users for all the services and daemons.
* T-Bone investigates on the udev / 2.6.10 issue
<seb128> sivang: correct
<thom> Mithrandir: true enough
<thom> Mithrandir: i think seb128 is ignoring me tho ;P
* seb128 kicks thom 
<sivang> seb128: ok, then I get to see to additional following: postfix, messagebus, hal and 2 more...
<seb128> thom: what did you do to nautilus again ? :p
<seb128> sivang: works here ...
<sivang> seb128: ok, I hope it not something my package breaks...
<sivang> Mithrandir: any luck? ;-)
<thom> seb128: open up an sftp connection, open my home folder, drag and drop from the remote to the local, and the local window gets closed every time
<Mithrandir> sivang: I haven't seen an url from you yet?
<sivang> Mithrandir: http://sivan.workaround.org/gnome-system-tools_1.1.90-0ubuntu1_i386.deb
<sivang> sorry
<seb128> thom: that's weird ... anything in .xsession-errors ?
<seb128> sivang: better to give the package sources than a deb
* T-Bone hails his ISP, has been upgraded again :)
<ogra> is there been any progress on #5870 (evo on amd64) ?
<sivang> seb128: eer ops
<sivang> Mithrandir: sorry, oops
* sivang is uploading a new one
<Mithrandir> ogra: I told seb what was wrong, he bounced it back to me.
<ogra> hmm
<Mithrandir> so I need to whack it a bit.
<ogra> heh
<Mithrandir> it's a shame that the distributed nature of the project means incitations in the form of alcohol doesn't really work.
* T-Bone falls over Ubuntu Update Manager and wonders wth
<T-Bone> feels like OSX' Update Manager :^)
<kent> wow, the new update-manager in Hoary is very nice :)
<Josephus> indeed
<trulux> bluefoxicy: pitti online
<dholbach> re
<rouven> is anyone in here taking part in the website look and feel competition?
<dholbach> rouven: how long will it be until submission?
<sivang> pitti: ping
<dholbach> re ogra
<ogra> hey
<robertj> flash crashed firefox and it took me 5 minutes before I could kill the thing with the gui, where is the appropritae place to file a bug?
<Treenaks> robertj: yes, at Macromedia
<Treenaks> robertj: (flash is not supported)
<robertj> Treenaks: why should a browser crash bring my whole desktop experience to a grind?
<Treenaks> robertj: no, the flash player is buggy and brought your browser down, which brought your desktop down
<Hwolf> Treenaks: Why is a browser able to bring a desktop down?
<robertj> Treenaks: it's a bug, and not a flash problem, deal with it
<Treenaks> Hwolf: well, it could make it slow... add more memory
<robertj> if someone goes and uses your file format to do something it wasn't intended to do, and it crashes, it shouldn't grind the whole desktop to a halt
<Treenaks> robertj: ask on #ubuntu - this is the development channel. not the supoprt channel.
<Treenaks> robertj: so file a bug on the C compiler.. it allows you to write programs that bring down the machine
<Hwolf> Treenaks: isn't there a system to kill rampant memory bloat?
<Treenaks> Hwolf: yes. in the kernel: the oom killer (out-of-memory)
<trulux> robertj: what happens exactly?
<trulux> robertj: anything back from the kernel?
<robertj> trulux: surely not
<robertj> trulux: planet.gnome.org has a link to an swf file which brings down flash because excessive # of objects created by a bug in the vnc2swf socftware bringi t down
<Hwolf> guys: Is there any chance that a software bug starts I/O errors?
<robertj> which is fine, I expected "Flash has crashed. Would you like to restart it?"
<trulux> robertj: OK
<trulux> Hwolf: pretty difficult in my opinion
<trulux> Hwolf: what software are you talking about?
<robertj> I thought things were supposed to be sufficiently niced these days to stop that from occuring
<Hwolf> trulux: i dist-upgraded my hoary installation last night, and I dpkg/apt died on me with I/O errors
<Hwolf> trulux: Then I installed warty on the same machine, other hdd and dist-upgraded it fresh. Again those errors.
<trulux> strange
<trulux> anything runnind under root privileges has at least CAP_SYS_RAWIO capability
<trulux> so, if something running under such privileges is doing weird stuff... a bad thing
<tseng> whats rawio have to do with apt
<Hwolf> trulux: that is alien language to me.
<trulux> tseng: nothing
<robertj> Hwolf: come to #ubuntu-sed
<trulux> tseng: it should be a problem not related with userland stuff
<mjt> hmm. after installing xorg 6.8.1-1ubuntu10, xv stopped working - the picture looks like some green garbage (any app using xv - xine, tvtime, mplayer, ...).  Any pointers?
<mjt> s/6.8.1-1ubuntu10/6.8.1-1ubuntu11/
<ogra> trulux: how about graveman 0.3.4 ?
<ogra> trulux: oops, pardon, i meanr trukolo.... damned autocompletion...
<bluefoxicy> trulux: what pitti where?
<bluefoxicy> trulux:  I made a mistake on those exec-shield tests
<bluefoxicy> I forgot to execstack -c them all, and some had PT_GNU_STACK
<bluefoxicy> so it turs out execshield didn't fail ALL the tests
<bluefoxicy> it passed ONE
<bluefoxicy> (non-executable stack)
<trulux> grrrreat
<trulux> one test of....
<trulux> around 20?
<bluefoxicy> 19
<bluefoxicy> I counted.
<bluefoxicy> also
<trulux> that's a great result man
<trulux> it could even worst
* trulux grins
<bluefoxicy> well anything that can evade propolice can evade their NX stack
<bluefoxicy> so a propolice deployment would probably be "genuinely better"  :P
<bluefoxicy> http://lists.debian.org/debian-devel/2003/11/msg00227.html
<bluefoxicy> and Ingo calls foul on paxtest 0.9.5
<trulux> bluefoxicy: we can write an es regression test , specific for it
<bluefoxicy> so I audited and anylized 0.9.6 and find no such mmap() or mprotect() calls that would disable exec shield, it just sucks
<bluefoxicy> trulux:  I swear they're just going to kill me
<bluefoxicy> trulux: es regression test is easy
<bluefoxicy> int main() {
<bluefoxicy>   printf("Passed.\n");
<bluefoxicy> }
<tseng> funny
<trulux> XD
<trulux> this intentionally calls mprotect(PROT_EXEC) for the highest possible
<trulux> address one can think of. This call has no useful purpose at all. In other
<trulux> words, this is a specific, underhand cheat to trigger 'Vulnerable'
<trulux> messages for all items when running paxtest on exec-shield kernels.  
<trulux> Bravo!
<trulux> Mingo Dixit
<bluefoxicy> trulux:  yeah, I think Ingo had a point about 0.9.5
<sivang> Mithrandir: ping, I have a source pkg
<sivang> Mithrandir: is it still relavent? ;-)
<bluefoxicy> but I used 0.9.6, and it looks OK (even an strace shows nothing nasty)
<trulux> ok
<trulux> listen
<trulux> maybe Ingo is not so wrong
<trulux> paxtest DOES specifical stuff for pax testing
<bluefoxicy> doesn't matter.  I used real tests and got real results.
<trulux> and PaX has a REALLY different mem mapping style
<trulux> so
<tseng> are you guys making a point, or is this #debian-hardend stuff?
<bluefoxicy> uh
<bluefoxicy> tseng has a point
<bluefoxicy> I just woke up
<bluefoxicy> and I was looking for pitti
<trulux> using a mprotect call against a top mem area gets killed on PaX
<trulux> but not on ES
<trulux> it uses a different manner for that, even unsecure when doing so
<trulux> but different in the end
<trulux> anyway this is a bit funny:
<trulux> here are the paxtest-0.9.5 results with that single purpose-less line
<trulux> removed, for the categories that matter to me:
<trulux>  Executable anonymous mapping             : Killed
<trulux>  Executable bss                           : Killed
<trulux>  Executable data                          : Killed
<trulux>  Executable heap                          : Killed
<trulux>  Executable stack                         : Killed
<trulux> paxtest gives Killed if the called test returns 1) exit(0) 2) breaks 3) gets SIGKILL
<trulux> it's just like when you catch up the elf_map() call in the kernel
<trulux> with a file_mmap() syscall returning something but not 0 or 1
<trulux> (0 )
<trulux> so
<trulux> elf_map()->file_mmap()->...
<trulux> if file_mmap() returns -EPERM, -EINVAL, whateverelse rather than 0
<trulux> then it breaks
<trulux> abd gets "Killed"
<trulux> that's what vSecurity does
<trulux> in the TPE engine
* bluefoxicy comes back and blinks.  "Man are you still talking?"
<bluefoxicy> now i know how tseng feels when I do it.
<bluefoxicy> :)
<trulux> so
<bluefoxicy> but heh
<trulux> Ingo is a bit wrong if he thinks that killed means explicitly not vulnerable
<trulux> collision-rts handles the output in a different manner, so, most Killed calls will be because of dirty exits and such
<trulux> caught?
<trulux> :)
<bluefoxicy> heh
<trulux> Please, guys, don't have your discussion here. I don't think we really
<trulux> care about the differences between PaX and exec-shield. Debian is not,
<trulux> and, to the best of my knowledge, will not, choose one for its kernels,
<trulux> so there is no need to prove that one or the other is better.
<trulux> -- 
<trulux> gram
<trulux> lol
* trulux takes the axe
* trulux cuts somebody's head off
<trulux> ;P
<bluefoxicy> trulux:  so pitti isn't online anymore?
<trulux> no idea
<trulux> anyways, I'm starting to loss the faith on Hardened Debian
<bluefoxicy> why, you're doing a good job
<trulux> and if it doesn't give something new out I will continue doing upstream work
<bluefoxicy> upstream work is part of hardening isn't it?
<trulux> bluefoxicy: i dislike being pissed off with stupid things like "trademark uses, etc"
<sivang> Mithrandir: http://muse.19inch.net/~sivan/g-s-t/
<trulux> sure
<robertj> trulux: really the only thing I think really needs to get done is to have pam check for weak passwords on outward-facing daemons
<trulux> robertj: that's cracklib man
<robertj> yeah
<trulux> and it's inside PAM already
<trulux> and not
<trulux> passwords are weak
<azeem> sivang: there's no .orig.tar.gz
<robertj> it's not installed by default thoug hright?
<trulux> passwords are obscurity for security by meaning
<trulux> passwords are pure crap
<robertj> trulux: and they are GoodEnough(TM) for most people
<robertj> krb5 is where it's at though
<trulux> somebody relying on them for system security is really a man in a *nut*shell
<trulux> in a big clue ;)
<bluefoxicy> robertj: http://ubuntulinux.org/wiki/USNAnalysis
<trulux> robertj: krb5 has demonstrated to be not as secure as many people commented in the past
<trulux> or at least it's implmentations
<trulux> but dunno
<sivang> azeem: eh yes, I guess it'd be the same as apt-get source gnome-system-tools
<azeem> sivang: so then the .diff.gz is missing
<sivang> azeem: ok, checking
<trulux> bluefoxicy: I'm going to a start a flame at the LKML
<bluefoxicy> robertj:  security is more of keeping an eye on how many ways someone can log into your system, and getting rid of the non-authenticated ones
<bluefoxicy> trulux:  don't do that :p
<trulux> bluefoxicy: "sys_chroot() broken by design, enhance or die"
<sivang> azeem: strange, that's waht I got debuilding -S
<bluefoxicy> haha
<trulux> "use fscking jail()"
<trulux> "stop arguing that i do shit, I know it already
<trulux> "I don't have pains, I just clear up my terminal with 2.6 oops"
<trulux> bluefoxicy: the other point is that I CAN'T add a new LSM hook for sys:chroot, they WILL NOT accept it
<trulux> so
<trulux> I use my own BSD Jails code base from Serge
<trulux> and send chroot jails out
<trulux> bluefoxicy: we have an userland tool for chroot namespace changing
<azeem> sivang: then you uploaded the wrong files :)
<robertj> blufox: my big security question is, drumroll...
<trulux> as a replacement of chroot
<bluefoxicy> robertj:  no it won't be harder to use.
<mjt> anyone expirienced with X internals around?  Or, maybe, what to do with a particular driver problem I have (trident_drv in 6.8.1ubuntu11 have issues with xv)?
<sivang> azeem: I'll send you my ls output
<trulux> bluefoxicy: anyways, I must finish up the vsec stuff
<robertj> blufox: ready for this...is it possible to secure mod_dav?
<trulux> ajmitch: ping
<bluefoxicy> robertj:  what the heck is mod_dav?  :P  apache module
<robertj> yeah
<bluefoxicy> don't know, i'm not an apache administrator guy
<trulux> robertj: DAV? PUT shit /boo/ :)
<trulux> ajmitch: there?
<robertj> I've been meaning to look over the  OS 10.3 server at work and see how it handles the situation
<trulux> bluefoxicy: back to work, see you later
<robertj> bluefoxicy: you don't like krb5 though?
<bluefoxicy> I dunno..  I don't use kerberos, I don't have a kerberos network
<robertj> it's nice but the docs suck and the gui tools are non-existant
<robertj> and security is very gui-centric
<robertj> at least gnome keyring is getting together
<robertj> sometimes I wonder if the needed info could be stored somewhere in case krb5d was brought online later
<dholbach> can I specify files somewhere in  ./debian/  that are to be ignored?
<T-Bone> dholbach: define 'ignored'
<dholbach> doxygen spits out an empty doxyfile-warnings.txt, which i dont want to remove by some shell hack
<dholbach> T-Bone: where can i specify that?
<T-Bone> that happens during the binary build, i suppose?
<dholbach> T-Bone: yes
<T-Bone> and you don't want to have it in the binary deb?
<T-Bone> if it's not part of the install target, it won't get in. And if it is, then remove it before it actually makes it in  (edit the rules file)
<dholbach> and  WARNINGS = no   doesnt keep it from dropping that stupid file
<T-Bone> dholbach: as long as it is not part of the install target, it's not a problem, it won't be included in the final package
<dholbach> T-Bone: so you suggest some shell-hack
<T-Bone> dholbach: no
<dholbach> T-Bone: i want to get rid of the lintian-warning
<T-Bone> dholbach: i don't actually see why it would be part of the install target. Either the Makefile is wrong, or you need some modifications to the rules file
<T-Bone> what does lintian says?
<dholbach> T-Bone: i guess the latter
<dholbach> T-Bone: W: libgtkmm-2.4-doc: zero-byte-file-in-doc-directory usr/share/doc/libgtkmm-2.4-doc/reference/html/doxygen-warnings.txt
<T-Bone> ah!
<T-Bone> it gets in docs
<dholbach> i guess everyone could live with an empty file, but... :-)
<T-Bone> no
<T-Bone> hmm
<dholbach> but i want lintian-warning-free packages :-)
<T-Bone> sure
<T-Bone> that's a good thing
<dholbach> i could try to turn doxygen to be QUIET
<dholbach> but it'd take me 20 minutes to find out
<dholbach> so i thought some  ignore = ... thingie would be cool
<T-Bone> well i don't know how your package gets build, so i can't tell off hand what to do. In such a case, i'd suggest using the '-X' flag of dh_installdocs
<dholbach> oh yes cool *has a look*
<dholbach> T-Bone: YOU rock
* T-Bone grins :)
* dholbach rebuilds
<Hwolf> I just installed a hoary array, and it did not pick up my sound. a warty-hoary upgrade did.
<sivang> is there anybody interested in testing my bin package? now install and removal works, and you should be getting two profiles for adding users. Also, config data files are now expected to be in /etc/gnome-system-tools
<sivang> http://muse.19inch.net/~sivan/gnome-system-tools_1.1.90-0ubuntu3_i386.deb
<dholbach> sivang: if you'd provide a source "package", i'd do a test on amd64 :-)
<sivang> dholbach: ok, sure :)
<sivang> dholbach: if you could, please test netowrk config also to see if ti stores antying in /etc/g-s-t
<dholbach> sivang: you're doing a   debuild -S  ?
<sivang> dholbach: already did, uploading..
<dholbach> sivang: cool :-)
<T-Bone> Kamion: ping?
<sivang> dholbach: takinhg ages to upload..
<marcin_ant> hello - any zope/plone guru/user available here?
<Nonphasis> I wonder if this is the place to whine about Hoary breakage?
<usual> whats broken
<Nonphasis> sound
<Nonphasis> spdif goes "off"
<Nonphasis> it works ok in the beginning with esd (nhythmbox etc), breaks in beep-media player
<Nonphasis> I wonder if alsa-utils update today broke it
<thully> hi - is the lack of localization on the live CD a known issue - I'm learning Spanish and decided to try using Spanihs from the live CD, but the booted system was still in English.
<mdz> seb128, thom: firefox is stealing my window manager shortcuts now; is this a firefox change or a metacity change?
<seb128> since when ?
<seb128> I doubt that's a change on the GNOME side
<mdz> since I restarted firefox, approximately
<mdz> I use alt+1, alt+2, alt+3 etc. for switching desktops
<mdz> and now they switch tabs in firefox
<seb128> ok, so firefox
<mdz> so when I am switching between desktops, I get to firefox and I can't escape :-)
<seb128> ah ah
<thully> is the lack of localization on the live CD a known issue at this point?  I tested it just for kicks and noticed this, and I think I remember someone saying something about this
<seb128> hum, I've to go now, later guys
<dholbach_dogwalk> bye seb128
<mdz> thully: it is a known issue in array3.5; it should be fixed in the latest daily
<marcin_ant> I cannot login to zope manage application - could someone tell me what is default password and login on ubuntu?
<T-Bone> has someone tried 'man <anything>' on hoary lately?
<T-Bone> i'm getting square chars in the output
<T-Bone> that makes the manpages hard to decypher...
<rubenv> T-Bone: in what page specifically?
<rubenv> and what term?
<T-Bone> rubenv: VT terminal
<T-Bone> man hdparm, man lspci for instance
<rubenv> both gnome term and (u)xterm do great here
<T-Bone> it doesn't do that for all manpages tho
<T-Bone> but it does so with man lspci and man hdparm
<rubenv> aha
<T-Bone> got it?
<rubenv> getting it too on the tty's
<T-Bone> does the same on remote ssh term
<rubenv> that's rather a matter of your local term
<dholbach> T-Bone: btw it worked ;-)
<rubenv> but i guess it's a font issue with the tty
<rubenv> (didn't it change lately?)
<T-Bone> rubenv: i don't see why it'd be a matter of my local term, which works fine with a good 50 remote machines i connect to, including funny OSes such as IRIX, Solaris and HPUX, among a few :P
<T-Bone> and my 'local' term isn't an Ubuntu one, fwiw (running debian here)
<rubenv> T-Bone: it's your local term that displays the weird chars
<T-Bone> rubenv: it's the remote manpage that sends them
<T-Bone> rubenv: it does the same on a VT100 console I have hooked to the serial port
<rubenv> T-Bone: man works great on xterm or gnome term
<T-Bone> which i'm using
<T-Bone> so i'm correcting: it works (presumably, can't test that yet) great with hoary's gnome term or xterm
<rubenv> then you're not getting the same i'm getting :)
<thully_> hi - I lost my connection - so (sorry if you've already seen this) - is the lack of localization on the live CD a known issue?  I tested it for kicks and it didn't work (GNOME was still in english)
<T-Bone> rubenv: you're getting a weird accentuated char followed by two squares in particular for each "-" option listed on the manpage
<T-Bone> right?
<rubenv> yes, but only on my tty, not in an X terminal
<T-Bone> right, tested just now
<T-Bone> it works fine with hoary's xterm
<T-Bone> not with debian xterm
<rubenv> hmmm
<T-Bone> that's definitely a bug
<rubenv> anyone has a warty to test with?
<T-Bone> xterm Xt error: Can't open display: %s
<rubenv> xorgs xterm is quite different
<T-Bone> that's another bug AFAICT
<T-Bone> (localization bug?)
<sladen> UTF-8 is enabled in each case?
<rubenv> localization?
<rubenv> full utf8 here
<T-Bone> rubenv: the "%s"
<T-Bone> it should be the name of the host i'm trying to connect to
<rubenv> T-Bone: that's not necessairly localization :)
<T-Bone> right, just a guess ;)
<T-Bone> man mkfs does the same but not man mkinitrd (both in section 8)
<T-Bone> man less is also fux0red
<T-Bone> well i'm not gonna list them all, i think there's enough for a testcase already :P
<Hwolf> b
<thully> I wanted to test installer clock handling in the case that the clock is set to local time - how could I force the installer to do this (it always goes to UTC without asking, and I've already tested that case to be fine)
<abelli> my gnome-volume-manager just crashed, and it even didnt told me why!?!? 8)
<andrewski> can anyone answer this question: why are the packages in the universe repository not quite current?  can users contribute?
<andrewski> abelli: #ubuntu ?
<rubenv> andrewski: check the wiki if you want to become a maintainer
<andrewski> rubenv: that sounds a bit too extensive; i just want to contribute packages. :)
<crimsun> abelli: hal+udev? ;)
<crimsun> abelli: fwiw, a reboot resolved that for me
<abelli> crimsun: the system is still alive,
<abelli> gnome just told me that gnome-volume-manager went out for a walk
<crimsun> abelli: yes, mine was, too, but the load avg was horrendous. ~18
<abelli> 26%
<thom> mdz: as far as I'm aware, alt+<num> has always changed tabs in ffox; if metacity isn't grabbing those keys first, i guess that's a change in metacity's behavious
<schweeb> o_O
<schweeb> I've never had ffox change tabs w/ alt+num
<schweeb> always used ctrl+pgup/dn
<schweeb> and it suddenly works for me as well
<schweeb> and I'm using fluxbox
<farruinn> erm, in ff it changes tabs with ctrl+kpnum for me
<farruinn> (in warty)
* schweeb uses hoary
<farruinn> maybe firefox has gone from ctrl to alt?
<thom> i've always used alt
<mdz> thom: seb128 already blamed it on firefox :-)
<mdz> thom: it's always been alt, but if they were bound in the window manager, it wouldn't eat them
<mdz> thom: also, alt+tab used to work
<mdz> and continues to work in other apps
<thom> mdz: i can't reproduce alt+tab not working
<thom> nor ctrl+alt+left/right
<thom> which focus mode are you using?
<mdz> mako: ping?
<mdz> thom: defaults
<thom> mdz: click to focus, then?
<mdz> thom: yes
<mdz> hmmm
<mdz> they don't work on that desktop, even when firefox doesn't have focus
<mdz> lemme try closing firefox
<thom> even with click to focus (i use sloppy), i can't reproduce
<mdz> what the hell
<mdz> ok, the problem is redefined as "window manager shortcuts no longer work on desktop #5"
<thom> whacky
<mdz> but continue to work everywhere else
<thom> that's, um, impressive
<mdz> ok, closing all windows on that desktop and diddling about a bit seems to have gotten it back
<mdz> even after reopening firefox
<mdz> so RESOLVED/WTF
<thom> i'm so closing that bug with this chunk of irc log ;-)
<mdz> probably a metacity bug in there somewhere
<mdz> but there is no hope now
<thom> yeah, that's truely a bizarre one
<thom> GAH, HAL is spinning my cdrom drive
<dholbach> thom: and gamin keeps sitting on the cd
<dholbach> i "kill -s SIGHUP"ed it 5 times today
<fabbione> hi guys
<dholbach> hi fabbione
<schweeb> thom: since you're here, I'll consult you before bugzilla, to see if it's fixed... when I click on an XPI in the newest ffox in hoary, it doesn't open it w/ ffox... I have to save as, then go to file->open file to install an XPI extension
<thom> schweeb: is that a change in behaviour recently?
<schweeb> afaik, happened with the last update... been a while since I've installed an extension, I guess
<thom> schweeb: (I have not extensions or translations installed, and have never done so that i can recall. so i'm not familiar with the behaviour)
<schweeb> but usually, I clicked on the link, it'd download it, then I'd get a box that would install it
<schweeb> in older versions
<schweeb> whiprush noticed the same thing
<thom> very strange
<schweeb> thom: yea, I don't usually use extensions, but I tried Jybe last night
<schweeb> which is pretty neat.
<thom> file a minor bug, with a url to an extension and i'll take a look
<schweeb> alrighty
<thom> well, i'll have dinner and then maybe ;-)
<schweeb> thom: hrm, now that I look, it may be a MIME thing... cause extensions from texturizer will install
<andrewski> ogra or haggai... hello?
<Kamion> T-Gone: pong. with regard to your man problem, check your locale on either side; I'll be willing to bet that there's a mismatch between the locale that the terminal's running and the locale environment variables set on the remote end of the ssh connection.
<Kamion> Mithrandir: I've already mailed T-Bone about it, but FYI, Hoary's installer does not use discover any more.
<farruinn> would much come of reporting a bug on warty?
<farruinn> I'm just wondering if there's much point in doing so since most of your efforts are probably focused on hoary
<dholbach> what did you want to report? maybe it's still an issue for hoary
<Hwolf> farruin: ask someone to see if the bug is still in hoary, then report it.
<dholbach> farruinn: warty is closed, just security fixes are pushed back in
<farruinn> Hwolf: would this be an appropriate channel to ask in?
<farruinn> or maybe I'll just post to the mailing lists...
<Hwolf> farruin: ask in #ubuntu. Some people here can be picky.
<farruinn> ok, thanks all =)
<dholbach> farruinn: just tell what the bug was about
<farruinn> the stickies applet doesn't remember the widths I set across logins
<farruinn> I'll see if anyone else has noticed this
<dholbach> farruinn: have a look at bugs.gnome.org too
<farruinn> ah, right, I hadnt' thought of that
<jdub> yo Kamion 
<dholbach> who wants to test some g*mm-packages? :-)
<Hwolf> dholbach: I've had 3 hoary installs give out on me in 48 hours. I'll wait.
<seb128> dear thom, stop reassigning your firefox bugs on epiphany, kthxbye
<jdub> hrm, something wrong with uploads?
<jdub> morning seb128!
<seb128> evening jdub :)
<jdub> i woke up this morning
<jdub> and saw that seb128 had fixed a gtk bug!
<Kamion> jdub: yo, but I have to go again :)
<jdub> hrm
<jdub> do i accept a webcomp entry sent to ubuntu-announce? :)
<seb128> jdub: stop trolling you know that gtk has no bug :p
<jdub> Connection failed, aborting. Check your network (110, 'Connection timed out')
<marcin_ant> jdub: Hi! I have a short question about website competition: are you going to publish previews of already submitted projects?
<jdub> bong!
<jdub> marcin_ant: only once it's closed
* jdub is attempting to upload nicely working inotify gamin
* jdub is being thwarted by the universe
<marcin_ant> jdub: hmmm ok. So, I have to submit my project anyway...
<herzi> jdub: ping
<jdub> yo herzi 
<marcin_ant> jdub: BTW could you give me an answer on short and propably naive question about zope and plone?
<herzi> the link to jimmacs page on planet.g.o directs one to his rss feed (i don't think it's supposed to do that)
<jdz_> marcin_ant: shoot :)
<jdub> marcin_ant: might be able to ;) i'm pretty short and naive about plone ;)
<jdub> herzi: his rss feed possibly provides that link
<marcin_ant> ok - then - what is default username and password to login to manage application?
<jdub> no idea
<jdz_> marcin_ant: there is no default.  you set one when you create a zope instance.
<marcin_ant> first thing is that currently (probably to make website competition more interesting) zope and plone packages for hoary are broken
* jdub notes down jdz_'s interest in zope on his permanent record
<jdub> marcin_ant: might want to ask doko about that when he's aroudn
<jdz_> marcin_ant: The zope package in hoary works fine, I'm using it right now.  I don't use ubuntu's plone though.
<marcin_ant> jdub: I have packages from http://nathan.faho.rwth-aachen.de/debian/zope/
<marcin_ant> jdub: so no problem
<jdub> "no problem"?
<jdub> dude, you just said plone was broken in hoary
<jdub> that is a problem! :)
<jdz_> marcin_ant: how are they broken?
<marcin_ant> jdub: no problem for me because I have packages but not from hoary repo
<marcin_ant> jdz_: no python2.3-xml
<marcin_ant> jdz_: just a moment
<marcin_ant> jdz_: I'll remove, refresh and try to install again
<thom> dear seb, when you fix gtk i'll buy you dinner, love thom
<seb128> ah ah
<thom> (and it _is_ an epiphany bug, since the crash doesn't happen in firefox but does in ephy ;-) )
<seb128> have you read my comments ?
<seb128> happen in firefox here
<seb128> and the bt come from firefox !
<thom> i could not get firefox to break at all
<thom> but ephy did it first time
<seb128> firefox/mozilla/galeon/epiphany crash here
<seb128> every single time
<seb128> hello world
<seb128> bottom
<seb128> right
<seb128> BOUM
* thom boggles
<thom> it did it that time
<thom> i tried it like 10 times early and it didn't break once
<thom> fucken odd
<thom> oh well, my apologies
<seb128> :)
<seb128> that's fine don't worry :)
<sjoerd> thom: he still gets the dinner right ?
<seb128> but I don't know why the bt has no details, I've rebuilt firefox in nostrip nopopt
<seb128> noopt
<seb128> sjoerd: good point :)
<jdub> seb128: 'BOUM' is a french explosion?
<seb128> jdub: correct
<seb128> what's the english version ?
<jdub> "BOOM"
<seb128> BOOM ?
<seb128> right
<marcin_ant> jdz_: I can confirm
<tseng> jdub!
<jdub> probably because most of our explosions are conventional, not nuclear. :-)
<thom> sjoerd: no, he's not fixed gtk yet
<marcin_ant> jdz_: on my system zope requires python2.2-xml but this package is not installable
* thom fofl
<jdub> sjoerd: would you like to make soft, tender debian love to my gamin packages?
<sjoerd> jdub: if they are sweet and nice i will
<jdub> they're tender and juicy!
<sjoerd> bring them on then!
<thom> jdub: are they nicely rounded?
<thom> in all the right places?
<thom> seb128: i guess i'm going bugzilla trawling on monday, then
<dilinger> clearly i'm maintaining the wrong packages
<seb128> ok
<dilinger> mine are all old and crusty, w/ sharp edges that cut me
<dholbach> dilinger: so everyone has different dispositions, it seems ;-)
<tseng> dilinger: meh, -as2 is pretty smooth
<thom> dilinger: linux, php and mod_perl. what more needs saying
<dilinger> tseng: working on -as3 now :)
<marcin_ant> jdz_: how it is available that you have zope installable?
<thom> dilinger: you didn't exactly pick loving upstreams ;-)
<dilinger> heh
<jdz_> marcin_ant: I apt-get'ed it a few months ago, and have been using it daily ever since.  I'm kind of suprised it would be broken.  Do you get an error of some sort I could look into?
* thom ambles back to Grosse Point Blank
<jdub> great film!
<jdub> thom: btw, greeno says thanks very much
<thom> and, aaaargh, I just tried to put Michael Banck into IMDB when I meant ben affleck. CURSE YOU ELMO
<jdub> thom: he mailed, but wasn't sure if he had the right address
<thom> jdub: i need to reply to his email
<thom> yes
<jdub> ah
<jdub> we visited yesterday
<jdub> the sprog seems to be human
<thom> cool! how are they doing?
<thom> heh
<marcin_ant> jdz_: what error do you want?
<jdub> good, "life is substantially different all of a sudden"
<jdub> :)
<dilinger> john cusack can do no wrong
<jdz_> marcin_ant: how is it broken?  maybe you should just file a bug ;)
<marcin_ant> jdz_: it's like I said - apt-get install zope and you simple cannot install this
<marcin_ant> jdz_: because there is no python2.2-xml
<marcin_ant> jdz_: just problem with dependencies
<marcin_ant> jdz_: of course I can paste error message for you but I have system with polish locales 
<marcin_ant> jdz_: so you propably don't want error message in polish?
<thom> marcin_ant: ok, so we should change the defaul to point at zope2.7, which installs fine
<thom> please file a bug
<thom> jdub: heh, surprise
<thom> dilinger: *nod*
<jdz_> ah, yes!  right.  I have zope2.7 intsalled.
<jdz_> marcin_ant: yes, the zope package seems to be broken ;(  zope2.7 works :)
<marcin_ant> jdz_: sure - but then remember about plone
<sjoerd> jdub: just lemme know where they are when your done
<marcin_ant> jdz_: because I can currently install zope-2.7 but then plone is not installable
<jdz_> marcin_ant: right.  sounds like plone's dependencies need to be fixed up to use zope2.7.  file a bug like thom sugested :D
<marcin_ant> jdz_: ok - but then... how to create skin for ubuntu website contest?
<jdub> marcin_ant: see the announcement, you don't have to create a skin
<jdz_> marcin_ant: go to http://plone.org/downloads/ and grab the Plone Core tarball :D  - untar it into your zope instance's products directory, and bingo!
<marcin_ant> jdz_:  so I should install zope-2.7 and unpack plone core, right?
<jdz_> marcin_ant: thats what I do :D
<marcin_ant> jdub: yes I know but I prefer working on something "real"
<dholbach> cooool: i never saw this one: We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:     #1) Respect the privacy of others.       #2) Think before you type.      #3) With great power comes great responsibility.    (sudo on debian)
<jdub> marcin_ant: puts you at a serious disadvantage :)
<jdub> sjoerd: http://www.gnome.org/~jdub/debian/
<marcin_ant> jdub: :)
<mdz> jbailey: ping?
<thom> dilinger: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=110683815626149&w=2
<thom> dilinger: seriously, please get involved on that thread :-)
<jbailey> mdz: Here.
<mdz> jbailey: since you happened to be working on hotpluggish stuff, I was wondering if you had an opinion on #1763
* jbailey needs to setup epiphany with a smart toolbar for bugzilla.
<mdz> I just always have bugzilla tabs open, so the upper-right box on most bugzilla pages serves the purpose for me ;-)
<thom> by the way, bugzilla.ubuntu.com/1763 DTRT
<jbailey> mdz: Yup, this is hotplug suckage.  It doesn't actually probe the IDE bus, which is pretty much what you'd need.
<jbailey> And whoosh, I see that further down.
<jdub> thom: see the mails re: default firefox theme on ubuntu-user?
<jbailey> mdz: ide-generic is necessary still.
<jdub> thom: gnomestripe is nowhere near as good as industrial, either :|
<dholbach> brb
<jbailey> mdz: I'd far prefer to see Marco's patch included in hotplug.  It would be correct, I think, to just probe the bus that way.  SCSI might need the same thing for tape devices, too.  I haven't run a pure udev hotplug system with a scsi tape.
<sjoerd> jdub: did you try the gamin packages on a debian box ? my nautilus hangs on startup with them..
<sjoerd> jdub: still checking what the problem is.....
<mdz> jbailey: SCSI dtrt already
<mdz> jbailey: I guess there are two  issues
<mdz> jbailey: one is that the ide-* modules aren't loaded based on devices found on the bus (that bit is addressed by marco's patch)
<mdz> jbailey: the other bit is ide-generic needing to be loaded at the right time
<jbailey> Lemme do a quick check, but I don't think ide-generic needs to be loaded in any particular order, I think it just needs to be loaded.
<mdz> I'm fairly certain it needs to be loaded after the chipset-specific driver
<mdz> after _all_ chipset-specific drivers, even
<jbailey> Right now, my initramfs setup is loading piix, ide-disk, then ide-generic.  Lemme drop in ide-generic first and see what happens.
<jbailey> mdz: While that's rebooting, I got a full nfs boot setup working yesterday and confirmed today on #ltsp that there isn't a 2.6 swap over NFS patch around.
<T-Gone> Kamion: i'm sorry but my locale is C in both place, and I don't see how there would be a 'locale mismatch' on the own machine's tty
<T-Bone> Kamion: last but not least, manpages are in english, and the troubles doesn't happen everywhere
<T-Bone> and f*ck i can't write proper english anymore :P
<mdz> jbailey: what about nbd?
<jbailey> mdz: Haven't tried it yet.  The ltsp pages I had found first mentioned swap over NFS.  Since I was already using NFS, it made sense to try and minimise the number of protocols I was working with.
<T-Bone> s/everywhere/in every manpage/ that is
<T-Bone> +s
<T-Bone> damn i got a problem with plural forms :P
<mdz> T-Bone: it sounds an awful lot like UTF-8/iso-8859-1 mismatch
<dholbach> can any one give me some gdb-superpowers to get coaster going in ubuntu? :-)
<T-Bone> mdz: well i tend to think about that, but then I'm pretty puzzled by the fact that it only affects a few manpages
<mdz> T-Bone: which ones?
<T-Bone> mdz: besides, i don't see how/why that would mess with things both on local ttys and on remote logins
<T-Bone> mdz: a few examples are: lspci, less, mkfs...
<mdz> which part of the lspci man page?
<T-Bone> mdz: i've tried a few at random and it happened several times
<T-Bone> all parts
<T-Bone> mdz: it doesn't affect gnome terminal or xterm on hoary
<jbailey> mdz: At a quick glance it appears that ide-generic can be loaded before the piix driver.  My other machine is an sis5513.  I'll try that too.
<T-Bone> mdz: try them on your local VTs
<T-Bone> mdz: you'll immediately understand what i'm talking about
<mdz> T-Bone: ok, I didn't see that you were talking about the console
<mdz> that's an entirely different set of issues
<mdz> probably the unicode hyphen character is missing from the font, or some such
<T-Bone> mdz: but wth would that affect only a few manpages?
<mdz> T-Bone: it will affect any man page which uses '-'
<mdz> jbailey: hmm...you're using an Ubuntu kernel?
<T-Bone> mdz: no
<T-Bone> mdz: try man ls
<T-Bone> man man
<jbailey> mdz: Yes.
<T-Bone> or whatsoever
<mdz> T-Bone: try looking at the source for those man pages
<mdz> T-Bone: they use '\-' not '-'
<T-Bone> o_O
<mdz> they are two different characters
<T-Bone> /o\
<T-Bone> mdz: well it's sort of a bug anyway you put it
<T-Bone> mdz: some one remotely logged from a non hoary machine will get all messed up
<mdz> T-Bone: yes, it certainly is a bug.  if you can confirm the cause and help to fix it, that would be fabulous
<T-Bone> and not being able to use local VTs properly is definitely not a good thing imho (consider the server-side of things, no pretty-GUI thingy there)
<T-Bone> err
<mdz> my guess is that it's a font problem
<T-Bone> can I behave like a normal user every once in a while? :)
<T-Bone> like "i report a bug, not my problem" :P
<mdz> not in this channel :-P
<T-Bone> *sigh*
<mdz> jbailey: hmm, let me try this
<mdz> hmm, there's no way to unload the chipset-specific driver, is there
<T-Bone> mdz: the only thing i can tell so far is that it's something new, and definitely a regression from warty (just checked, it doesn't happen)
<mdz> T-Bone: hoary uses utf-8, warty doesn't
<T-Bone> that's a hint
<jdz_> T-Bone: I can confirm in, I have the same issue :)
<mdz> I expect the same bug would exist in Warty if you use a UTF-8 locale
<T-Bone> jdz_: ok then i pass it to you! Find and fix the bug :)
* T-Bone runs away screaming
<jbailey> mdz: You mean forcably unload?
<jbailey> mdz: otherwise, they can be rmmod'd fine.
<thom> jdub: i don't agree, actually. I much prefer gnomestripe
<mdz> jbailey: hmm, something is holding a reference to mine
<mdz> and I can't see what
<mdz> via82cxxx              13852  1
<jbailey> mdz: That's what the current initrd does at startup.  It loads all the ide drivers, mounts the filesystem, and tries to unload them all.  Whatever is left is yours. =(
<mdz> I've unloaded ide-* (except ide-core, which is used by via82cxxx)
<jbailey> IF your partition is mounted on it, it'll hold the reference internally.
<thom> jdub: also, someone (schweeb or eruin?) asked about getting winstripe as an option, so i'll look at doing that later
<jbailey> Interesting. It looks like ide-generic itself is finding the ide bus on my boxes, and that the chipsets are then saying no bus'.
<mdz> jbailey: yeah, that's the thing
<jbailey> Feh.
<mdz> ide-generic needs to be loaded last
<jbailey> Nasty.
<mdz> we could load it at the end of hotplug startup or something awful like that
#ubuntu-devel 2005-02-10
<jbailey> It needs to be loaded in the initrd on IDE root systems, though.
<jbailey> I had to add ide-generic to get my laptop to boot, anyway.
<mdz> oh, you aren't using hotplug in your initrds?
<jbailey> No, the plan had been to have hotplug in userspace give me a list of the drivers, and then I loaded all of those manually.
<jbailey> That way hotplug at bootup got the coldplugging events.
<mdz> hmm
<jbailey> Or rather at sysvinit time.
<mdz> proper hotplug in the initrd has many benefits
<jbailey> (I tend to think of boot up being after I've chained to the proper init)
<mdz> like not having to mangle the initrd if your root device moves
<jbailey> Yup.  The downside is that it means all the boot drivers and stuff need to be in the initrd.
<jbailey> Doable, though.
<jbailey> That would actually make my task so far way easier.
<mdz> storage drivers and network drivers should be there
<mdz> (network to support NFS-root)
<jbailey> and usb keyboard.
<mdz> yeah
<mdz> that would address another class of bugs too
<jbailey> Yup
<mdz> it'd do two coldplugging rounds, one with the initrd modules only, and a second one with all modules
<jbailey> Cool.  Id' been chatting with dilinger about various ways to convince hotplug to give me a list of the devices that it would need for any given kernel version.  This saves that hassle at the cost of a larger initramfs.
<mdz> this is what I thought you were talking about earlier
<mdz> when you said you were doing it so as to replace initrd-tools
<jbailey> mdz: Nope.  I wanted to keep the initramfs small so do it at generate time.
<jbailey> Doing it at boot time is a simpler version of it.
<mdz> so either way, using the hotplug infrastructure rather than mkinitrd's hacks
<jbailey> Yes. =)
<mdz> but we were thinking of two different approaches
<mdz> we're already using hotplug in d-i
<mdz> so we've got its dependencies down to a manageable level
<jbailey> Yeah, saw that on the hoary goals.
<mdz> it basically works with busybox-cvs + module-init-tools, I think
<jbailey> *sigh* hotplug doesn't apply all of its patches cleanly on a fresh apt-get source.
<mdz> oh?
<jbailey> I've been using the tools that come with klibc, but I've seen that other people have gotten hotplug running with klibc.
<mdz> unstable or hoary?
<jbailey> hoary
<mdz> they all apply for me in hoary
<jbailey> ppc box.  The only non-ubuntu thing on here is dvdcss and the debian ppc kernel (Hoary's doesn't boot on the pegasos box.  The grub2 update on Monday should fix)
<jbailey> Applying patch debian/patches/./blacklist2-eepro100 failed!
<mdz> how weird
<mdz> it's possible that it's never been built on powerpc before
<mdz> but I see no reason why that should matter
<mdz> Applying patch debian/patches/./blacklist2-eepro100 successful.
<jbailey> Nothing in the hotplug Makefile or the spec file about klibc, but hopefully it's not too much elbow grease to beat it into shape.
<mdz> hotplug doesn't have any binaries
<mdz> it's all scripts
<jbailey> Oh, is it all shell?
<mjt> btw, as of 2.6.10, there's no /sys/bus/pci/devices/xx/driver symlink - helps with coldplug
<jbailey> Nice. =)
<mjt> s/no //
<mdz> the only C bit is grepmap, which is 1) in a separate package, 2) extremely simple (should be fine with klibc), and 3) optional :-)
<mdz> it really helps performance, though, so I recommend bringing it into the initrd
<mjt> when you have only few modules in initramfs, performance does not matter
<mjt> (or initrd, whatever)
<mjt> and, using modules.alias instead of modules.*map for most things speed things up further
<mdz> I'm not sure how few we'll end up with
<mdz> hotplug doesn't seem to have any support for modules.alias whatsoever
<mjt> mdz: i think we talked with you about this very stuff a while back, no? ;)
<mdz> yes
<mjt> modules.alias works for pci - the most important thing. inputmap (where modules.alias does not work) is small
<mdz> but you're arguing a nonexistent solution against an existent one, and the existent one always wins :-)
<mjt> non-existing?
<mdz> hotplug does not use modules.alias
<mdz> it uses modules.*map only
<mdz> the version we're using, anyway
<mjt> while read alias module; do case $deviceid in $alias) echo $module;; done < modules.alias -- that's all that is needed
<mjt> dash rocks, btw
<mjt> or, rather, while read junk alias module; do ...
<mdz> that, getting deviceid into the right format, and testing it for a few thousand user=months, yeah, that's all :-P
<mdz> s/=/-/
<mjt> eh?
<mjt> printf "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02X" $vendor $device $s_vendor $s_device $baseclass $subclass $if
<mjt> that's the $deviceid
<mdz> for PCI devices
<mjt> vendor etc are from /sys/bus/pci/device/xx/vendor etc directly
<mjt> yes
<mjt> the main case
<mdz> I see no incentive whatsoever for us to switch to using modules.alias, honestly
<mjt> usb is even simpler
<mjt> that switch makes grepmap even more optional
<mdz> I'm not entirely convinced of that
<mdz> just doing a while/read loop over the pcimap took longer than running grepmap
<mjt> note modprobe handles wildcards for you, so that while.. loop is not needed
<jbailey> mdz: At 200k uncompressed, I don't want to use more than I have to. =)
<mjt> but that loop is fast - much faster than current cruft in pci.agent etc
<mdz> jbailey: I don't see much choice about adding busybox to that, if we're going to use hotplug
<mdz> that's ~128k
<mjt> btw, module stuff in busybox is sorta broken 
<mdz> yes, that's why we don't use it
<mdz> not even in the installer or initrd
<mjt> and busybox is a very good thing to have in an initrd
<mjt> helps alot if something goes wrong
<jbailey> mdz: There are reports on the hoplug list that maked it look like udev, hotplug, klibc, and modprobe should be enough.
<mdz> we need busybox for a shell toolbox, not for module utilities
<mjt> (saved my ass several times with broken root raid stuff ;)
<mdz> jbailey: the hotplug scripts use cut, all sorts of stuff that's not built into dash
<mdz> some of them even use awk, but those are not needed in initrd
<mdz> grep
<mjt> cut - where? in tape.agent?
<mjt> grep - in net.agent?
<mdz> grep is used _everywhere_
<jbailey> Yeah.  The utilities in klibc doesn't have grep or cut.
<mdz> sed is used _everywhere_
<jbailey> cat false insmod ln mkfifo nuke run-init true uname chroot fstype ipconfig minips mount pivot_root sh udev dd gzip kinit mkdir nfsmount printf sleep umount
<mjt> in hotplug.functions, really
<mdz> mjt: in functions in hotplug.functions which are called from _everywhere_
<mjt> yeah
<jbailey> http://sourceforge.net/mailarchive/forum.php?thread_id=6319817&forum_id=3157 is the email that I'm looking at.
<mdz> busybox gives you everything needed to run hotplug at a small cost
<mdz> though if you're doing initramfs rather than initrd, that would make busybox a build-dep of the kernel, no?
<mjt> grep $MODULE /proc/modules - ugh, isn't it simpler to use [ -d /sys/module/$MODULE ]  ?  Or just let modprobe to do its work? ;)
<mdz> the former is portable across 2.4 and 2.6
<mdz> hell, 2.2
<mjt> is 2.4 supported in ubuntu?
<jbailey> mdz: No.  initramfs can be generated anytime after.  You can just make a cpio image and hand it to the kernel the same way you hand it an initrd.
<mdz> no
<mdz> but it's supported by hotplug
<mdz> hotplug is not specific to ubuntu :-)
<jbailey> mdz: If we *did* make it a dependancy of the kernel, we could just ship an already configured initrd.  Apparently (I haven't tested) you can hand in multiple cpio files and it'll unpack them all.
<mjt> initramfs works the same way as any other sort of initrd. except of the way you do final pivot_root/whatever stuff - for initramfs, there's special utility in klibc for that.
<mdz> a preconfigured initrd would be pretty fly
<jbailey> mdz: So that way the only bit to be done is just light config files (mostly for sane net booting), but those can also be handed in on the command line.
<sladen> jbailey: is cpio like tar;  you can just concatrenate stuff?
<mdz> jbailey: there's so much potential for weird bugs generating the initrd on the fly
<mjt> neither tar nor cpio can be concatenated ;)
<jbailey> sladen: Eh?
<mdz> you can concatenate new files to a tar
<mdz> s/concatenate/append/
<sladen> mjt: okay, remove the 2kB of zeros from the end :)
<jbailey> New files, yes.  Not multple tars.
<mjt> after removing the trailer, yes
<jbailey> Yeah.
<mjt> both tar and cpio have a trailer record
<jbailey> mdz: Ayup
<mjt> btw, generating initramfs (the cpio part) is umm.. not easy
<jbailey> mdz: So...  I'll need to do a version of busybox that's built with klibc.
<jbailey> mjt: http://people.ubuntu.com/~jbailey =)
<mdz> jbailey: we would need to build-dep on non-kernel stuff anyway, I guess; klibc seems to lack a shell ;-)
<jbailey> mdz: klibc has ash.
<mjt> i've written something in shell to do that (cpio) -- pretty fun stuff
<mdz> oh?
<mdz> in how many places do we need to duplicate this stuff? :-)
<jbailey> BTW, you really want a newer version of the mkinitramfs than is there.  I found a bug a minute or so ago. =)
<jbailey> mdz: As few as possible, ideally. =)  But we don't live in an ideal worls.
<mjt> jbailey: can yours be used as non-root?
<mdz> we already fork loads of stuff into busybox
<mjt> btw, why klibc?
<jbailey> mjt: Yes.  (cd ${TMPDIR} && find . | cpio --quiet --dereference -o -H newc | gzip -9 >${outfile})
<mjt> there's nothing that stops using other stuff (dietlibc, uclibc, even glibc but it's large) in initramfs
<jbailey> mjt: The difference is that klibc is eventually being targetted to be integrated in with the kernel build anyway.
<jbailey> mjt: udev is already prewired for udev, as is the replacement for pivot_root
<mdz> what does the pivot_root replacement do differently?
<mjt> jbailey: hmm. that cpio example - 2 probs. first of all, it packs ./ instead of / - last time i checked kernel chocked on that (that's why i wrote "my own cpio" in shell - pretty easy really); and 2), that way requires mknod, which is root-only
<jbailey> mdz: It cd's into the mounted root directory, deletes everything on the parent filesystem, overmounts the mounted directory as /, unmounts the previous one.
<jbailey> mdz: So it's all done in userspace, no in kernel magic.
<mjt> mdz: take a look at kinit in klibc
<jbailey> mjt: It's working fine on two systems here with the ./, and there are no devices in there.
<mdz> jbailey: hmm, I hope that doesn't mean pivot_root(2) is going away
<jbailey> mjt: The kernel provides /dev/console automatiically.  Everything else is done with udev.
<jbailey> mdz: I beleive that it does.
<mjt> pivot_root isn't needed with initramfs
<mdz> what about kernel threads?
<mdz> they find their way to the new root ok?
<jbailey> mdz: I'm using run-init.  kinit isn't quite useful yet.
<mjt> er.. how it's not useful?
<mjt> oh /me bad
<mdz> kinit in klibc 0.198 seems to use pivot_root
<mjt> i really meant run-init, not kinit ;)
<mdz> oh, run-init is the example
<jbailey> mjt: It's a conglomerate tool that basically just combined run-init and nfsmount.  It doesn't have anything in the way of extra magic.  I think I had another concern about it, but it's not coming to mind.
<mjt> utils/run-init.c
<mjt> yeah - sorry for the noise
<mdz> I would not have expected mount(".", "/", NULL, MS_MOVE, NULL) to work :-)
<jbailey> mjt: No, all good. =)  I'm still learning the new initramfs stuff.  I went to a workshop at OLS on it and come out with more questions than I went it with.
<mdz> but I can certainly adapt casper to that when pivot_root goes away, assuming kernel threads dtrt
<mjt> what's wrong with kernel threads and that initramfs/run-init stuff?
<jbailey> Oh!  Something that occured to me.  If we build the initramfs right into the kernel, would could probably still do thge DSDT update by handing it in using the initrd= method.
<jbailey> mdz: Casper?
<mdz> jbailey: the live CD magic
<mdz> it uses pivot_root(8)
<mjt> so just replace pivot_root(8) with run-init(to-be-8) ;)
<mjt> pretty easy to integrate into busybox, btw
<mdz> more likely replace pivot_root(8) with similar mount/chroot stuff
<mdz> it needs to do a few more things before execing init
<mdz> and it doesn't exec init, even, it lets init do that
<mjt> yes - deleting old stuff
<mdz> no, I meant casper needs to do more things
<jbailey> mdz: I need to bug off to a dinner engagement...  Anything else you need before I run off?
<dholbach> sleep tight guys... i'm off
<mjt> i once tried to pivot_root and umount /initrd with initramfs - the kernel freezes... ;)
<mdz> jbailey: nah, I need to run myself
<mdz> jbailey: you want to take on #1763 for Hoary?
<mdz> it would clean up a lot of mess
<jbailey> mdz: Yeah.  I've just assigned it to me.
<mdz> ok, thanks
<mdz> I've been pretending to get around to it for too long
<sladen> jbailey: the DSDT updates can be done at the moment by appending it onto the initrd
<jbailey> sladen: If we're talking about shipping a pre-generated config, though, it would be nice to not muck with the shipped kernel at all, and have grub hand it in.
<sladen> jbailey: from what I remember the initramfs includes a more formal way of doing that
<jbailey> sladen: That way it's completely independant with no magic.
<sladen> jbailey: I was originally thinking of hacking grub to do the appending at load time, but I think other people were keener on doing it in mkinitrd
<jbailey> sladen: I don't know enough about it yet.  I'm lucky.  Aside from being fubar with 2.6.10, my laptop's acpi Just Works(tm)
<mdz> Kamion: how much of a headache would it be to rename /install to /boot (or some such) on the CDs?
<jbailey> sladen: I gotta run, sorry.
<jbailey> *poof*
<mdz> jdub: when the about ubuntu page moves into yelp, will we be able to translate it then?
<YokoZar> Hey, can someone help me with a packaging problem I'm having.  It seems like it's a simple thing I'm overlooking (a make error) but, strangely, the .deb file builds and works fine (although it bugs out before it can ask for my password)
<mjt> .deb file should not ask for any passwords...
<YokoZar> Err yeah it gets there and then bugs out before signing the dsc
<mjt> if there's a "make error", it should not build.  error in signing (as dpkg-buildpackage performs) is non-fatal
<lupus_> would enabling extended attributes on the home directory by default
<lupus_> inpact performance
<lupus_> impact
<mjt> just enabling EAs makes no difference
<lupus_> beagle needs it :)
<lupus_> so I wonder if it be worth while for ubuntu to enable it
<mjt> enabling and *using* ACLs (which are built on top of EAs) will impact performance a little
<lupus_> does ubuntu create a seperate partition for /home if you select default install?
<crimsun> lupus_: no
<mjt> your question was like  "if i put this dir there, will it impact on peformance?" -- the answer is "yes, if you will hit the dir hard" ;)
<sivang> rehi all
<lupus_> isn't it safer for the user if ubuntu would create a seperate partition for /home and maybe /var
<lupus_> I remember my slackware box not working anymore after 8gig of logs :) in /var hehe 
<lupus_> gig = GB
<thully> I can officially say that the timezone bug is GONE!  Just tested w/system clock on local time (and Windows installed) and everything seems to be working fine
<lupus_> nice :)
<mjt> which $TZ bug it was?
<jdub> mdz: when the about ubuntu page is docbook based, the doc team can set up i18n infrastructure for it
<jdub> mdz: yelp will handle i18n/docbook
<mako> mdz: you still need me?
<mdz> mako: no, I was looking for a copy of the keyring from Mataro, but I ended up finding them all on keyservers anyway
<mjt> . o O { don't throw away please }
<sivang> I am posting this link again :) if anyone has remarks or other stuff, mail me and I'd appriciate it : the new g-s-t pkg should have ubunut's 2 default profiles for creating users, default (unprivileged) and Desktop , link:
<sivang> http://muse.19inch.net/~sivan/g-s-t/
<mako> mdz: i think it's at people.u.c/~mako/ksp-mataro/
<mdz> mako: that page lies and says that it will be there by the time of the keysigning
<mdz> but there's no link
<mako> ok.. i forgot to turn on the link
<mako> i did upload it
<mako> let me fix that
<mjt> speaking of repeating "postings".. what to do with videocard driver problem in xorg package? Just file a bugreport?
* sivang is out for the night. Night all!
<mako> mdz: fixed
<daniels> mjt: bug report on xserver-xorg
<mjt> (i've a prob with trident_drv - xv extension does not work; while using that driver from xfree-4.3 helps - surprizingly it works with xserver-xorg)
<mjt> er
<mjt> so the next question is - how to file a bugreport against ubuntu package?  I've a mix of debian/ubuntu right now, and don't even know where's the ubuntu bug tracking system... ;)
<mdz> if you have a mix of Debian and Ubuntu, try reproducing your problem with only Ubuntu first
<mdz> that is not a supported configuration
<mjt> it does not really matter in this case
<mdz> booting a Hoary daily live CD would be a good test
<mdz> don't be so sure
<mjt> eh-heh.. I't be nice to have live CD here... ;)
<mjt> for some reason it isn't available in russian stores ;)
<mdz> it is available on russian Internet
<mdz> http://cdimage.ubuntu.com/daily-live/current/
<mjt> sure it is
<mjt> 497Mb / 3Kb/s = 165666 sec = 46 hours ;)
* mjt hides...
<mdz> gah, openGL apps are still hanging my laptop
<mjt> speaking of benig sure -- what else, except of the xserver package (well, all packages from xorg source, really) can be a problem in this case?
<mjt> i see no other possibility
<mdz> it is inappropriate to file bugs based on a mixed system
<mdz> it is documented extensively that we neither recommend nor support this
<daniels> mjt: you have no idea the amount of weird problems that can spring from Debian with half the Ubuntu X.Org packages on them, trust me
<mjt> i think i do have that idea... ;)
<mjt> been there myself ;)
<mjt> this very prob is driver-vs-hardware, not software-vs-software issue
<schweeb> mjt: your request would be better received if you partitioned, ran a pure ubuntu hoary system, and THEN checked for the problem, and filed the bugreport
<mjt> ok
<mdz> you should choose whether you want to run Debian or Ubuntu; neither project will want to receive bug reports from a system with both sets of packages
<mjt> i really just wanted to know whenever i can solve the prob directly, with a help from someone more expirienced with that area 
<mjt> for now it works for me, after "downgrading" the driver to xfree-4.3, so i'm all set
<mjt> no "broken" bugreports (from mixed install/whatever), that is.
<mjt> maybe someday i will have some time to debug/fix it myself, who knows..
<mdz> thanks for understanding
<mjt> oh well
<YokoZar> mdz: email sent to ubuntu-devel
<mdz> YokoZar: I hope that you don't intend to notify me of each message sent to ubuntu-devel ;-)
<YokoZar> ehh, nah.  Just the first big one we were talking about last night
<mdz> there are quite a few of them, and I am subscribed to the list, so they are sent to me automatically
<robertj> mdz: is there going to be an install updates automatically option on update-manager?
<robertj> i see the download option all there by it's lonely self
<jdub> robertj: very tentative maybe once some other bits fall into place
<mdz> no, I don't expect there will be
<mdz> it isn't wise to install Ubuntu updates unattended
<jdub> robertj: but vveeeerrrryyy tentative
<mdz> especially not on a development branch
<robertj> mdz: well on the dev branch I understand, but for stable it seems like a good idea
<jdub> mdz: once we've got "you need to re-login" and "you need to reboot" flags for upgrades, letting users turn automagic installs on stable systems would be fairly sane
<robertj> jdub: might I add that XP does not behave smartly in this regard
<mdz> I disagree; packages are not designed with that in mind
<robertj> if you don't respond to the dialog it will automatically reboot your system, which is just great when you are playing a game
<HrdwrBoB> haha
<jdub> nice one.
<mdz> the user takes an explicit action, saying "it is OK if things get a bit weird until I am finished with this operation"
<mdz> and things do get weird
<HrdwrBoB> auto download is a nice (and already implemented in apt) option
<robertj> mdz: security updates should minimize wierdness though
<YokoZar> Perhaps we should incorporate more XP annoyances like that into Wine, to make it more compatible.
<jdub> firefox upgrade == weird!
<jdub> YokoZar! DUDE!
<jdub> man, i've been trying to catch you :)
<YokoZar> Ah
<YokoZar> hey
<robertj> installing during an idle time might be nice
<HrdwrBoB> what's an idle time?
<jdub> mdz: you can answer the autopackage question :)
<jdub> HrdwrBoB: when does your screensaver start? :)
<robertj> yeah, it's good enough for most users
<HrdwrBoB> jdub: yes, but when I come back to my desk and firefox is all bizarre because it updated while I was at lunch
<HrdwrBoB> or all the windows have closed
<jdub> or you get those wonderful xul errors
<jdub> "you can't quit because <!--- OSIUDFOIjdjjjdjdjj cccccxssssshhhhhh..."
<robertj> jdub: I just know none of my users run their softwareupdates
<robertj> they go out of their way dragging the dialog to the bottom of the screen because they have forgotten their passwords
<HrdwrBoB> that's an inherent user problem though
<robertj> it is, but there is no good way to remedy it I'm afraid
<jdub> lobotomy
<HrdwrBoB> big stick
<robertj> I can't crond softwareupdate because quicktime has graphical prompts
<jdub> electric shock therapy
<HrdwrBoB> graphical prompts suck
<jdub> there was some dude
<robertj> it's great, it even does it on quicktime
<jdub> who turned up on the gnome lists a few years ago
<jdub> who thought that tamagotchis were the future of user interfaces
<robertj> err even does it on 10.3 server
<HrdwrBoB> but the problem there is up to the sysadmin locally, not really ubuntu
<HrdwrBoB> wtf?
<jdub> and encouraged us to use emotional blackmailing as a user interface device
<robertj> jdub: haha
<robertj> "Do your updates or we will sodomize this hackergotchi"
<HrdwrBoB> hahahaha
<mdz> jdub: it solves all problems, who can argue with that?
<jdub> "i'm sad, you should upgrade me!"
<jdub> "i made a mess! fsck this!"
<robertj> I swear, I wish there were viruses specially designed to mess with stupid people
<HrdwrBoB> there are
<robertj> not this lame stuff like we have now, but stuff that really ruined careers by editing word documents andspreadsheets
<HrdwrBoB> except smart people have to fix it
<robertj> If it was good they could fix it when they took their job ;)
* robertj needs to start looking for another job
<robertj> has pam_keyring been given a oneover?
<lupus_> hmm gtkmm 2.5.5 seems to be the only thing missing for using coaster in hoary
<YokoZar> How long does it take the wiki to email me after I ask for an account?
<jdub> YokoZar: shouldn't take long
<YokoZar> jdub: thanks
<YokoZar> Ah, it's in there now
<jdub> Kamion, lamont, elmo: is there anything useful a normal human can do to help sarge's mipsel woes?
<srbaker> are there any prerelease hoary cds?
<jdub> cdimage.ubuntu.com
<srbaker> excellent.  thanks
<srbaker> going to install from the current cd
<thully> just closed that annoying timezone bug for good
<thully> also, btw - if anyone before remembers my troubles with conflicts between snd-intel8x0m and hsfmodem drivers from linuxant - the latest versions of these resolve the problem without blacklisting anything!
<sivang> thully: cool, migh solve the problem for me and my dell lappi ?
<aj> daniels: around? (or any other X types?)
* fabbione yawns
* fabbione starts to feel a bit better
<fabbione> aj: ?
<aj> 915g chipset support on warty?
<sivang> anyone have an abiword installation? I have a light emeregency, I need to save an abiword doc (which is in XML) to a .doc or .rtf (shush, god forbid) so it would be printable in a uni's lab...
<aj> daniels indicated there was 2d support, but i810 doesn't seem to see anything?
<fabbione> iirc no, you need Xorg and 2.6.10 for dri
* sivang I'd be THANKFUL for this :)
<fabbione> probably the flgrx driver can manage it
<aj> don't seem to have such a driver?
<aj> do i need to switch to hoary, or?
<fabbione> aj: it's in l-r-m
<aj> l-r-m?
<fabbione> aj: fglrx is the ati binary driver (restricted -> linux-restricted-modules)
<fabbione> otherwise you can grab X.org from hoary
<sivang> all that I need is for someone to open the file, save it as RTF and that's it ;-)
<fabbione> sivang: i can do it
<fabbione> sivang: put the file somewhere
<sivang> fabbione: Can I send you it using email? they block anything but smtp and pop3 and http here :-(
<fabbione> sure
<sivang> fabbione: fabbione@ubuntu.com ?
<fabbione> yup
<aj> modprobe fglrx just says "No such device"
<fabbione> aj: i am not 100% sure.. i hate binary crap, but iirc you need to rmmod r128 or something like that
<aj> r128's not loaded  
<sivang> fabbione: sent
<fabbione> aj: according to https://www.ubuntulinux.org/wiki/BinaryDriverHowto there is nothing special you need to do...
<fabbione> aj: i am afraid you need more recent stuff
<aj> so xserver-xorg from hoary?
<fabbione> aj: you need a bit more than the server
<aj> ?
<aj> beyond what apt pulls in with it?
<fabbione> clearly you need the libs too
<fabbione> just upgrade the x-window-core virtual package
<fabbione> (or something like that)
<fabbione> it will pull in everything you need
<fabbione> x-window-system-core
<fabbione> this one should be enough
<sivang> fabbione: lemme know when you've sent , sorry for the troulbe
<fabbione> sivang: done.. mail is coming back
<sivang> fabbione: thank you!
<fabbione> no problem
<fabbione> i am back to bed
<aj> fabbione: yay, 130M download :(
<fabbione> fever is going down but not that much yet
<fabbione> aj: only?
<fabbione> put the fonts on hold
<fabbione> i am pretty sure they get updated too
<aj> fabbione: it's mostly python, i think
<fabbione> it might reduce a few MB
<fabbione> are you dist-upgrading?
<sivang> fabbione: get well soon!
<aj> fabbione: nah, that's a 400MB download
<fabbione> Xorg does
<aj> fabbione: easier to wait 10mins than futz more
<fabbione> Xorg doesn't need python updated
<aj> *shrug* seems to
<fabbione> at least... NOT when i packaged it
<aj> probably have some python-gnome module installed that wants the old X and the old python or the new X and the new python
<fabbione> right
<fabbione> that's possible due to the lib split
<fabbione> good catch
<aj> well, hopefully this'll work; thanks and get well :)
<fabbione> aj: good luck.. :)
<fabbione> welcome and cya around
<sivang> fabbione: c'ya soon, and well :)
<fabbione> thanks sivang 
<aj> err, that almost worked, except the 1024x768 modeline doesn't seem to exist after a dpkg-reconfigure xserver-xorg?
<syn-ack> Man, I thought seb128 was going to be here.
<syn-ack> I wanted to thank him for getting that bug fixed in Rhythmbox so quick. I thought that since I filed it as "trivial" it would be on the bottom of the list.
<dholbach> morning
<syn-ack> good morning.
<sivang> dholbach: hey daniel, morning :)
<dholbach> sivang: hello sivan!
<dholbach> sivang: how did g-s-t go?
<sivang> dholbach: I have a source pkg for you ;-) http://muse.19inch.net/~sivan/g-s-t
<sivang> dholbach: I have to go now, be online again later, let me know if you managed to use it :)
<dholbach> sivang: right, i'll give it a go
<sladen>  /whois aj
<sladen> it is that aj
<Riddell> sladen: no it isn't, it's the other aj
<Mithrandir> depends on which aj is the other aj for you.
<Kaloz> morning
<Kamion> mdz: I don't really see a good reason to rename /install to /boot, and on some architectures it would cause me considerable confusion in the CD scripts, so I'd rather not
<Kamion> mdz: I'd rather not conflate directory names on the CD with directory names on an installed system that have a sort-of-similar but not-quite-identical meaning
<dholbach> hello seb128
<seb128> hi
<Kamion> mdz: 12:13 < svenl> Kamion: can you ask Matt to look at the mail titled "Re: Ok to commit ubd patch ?" from december 19 ?
<Kamion> mdz: (parted)
<thom> jdub: how is beagle, slacker
<thom> and where is my netapplet list?
<jdub> are you sitting down?
<thom> yes
<jdub> i attempted to relax this weekend :)
<thom> HFSNW!
<jdub> it was not all out proper relaxation
<jdub> tony put star wars battlefield in pipka's handbag before we left
<jdub> oh yes
<jdub> btw
<jdub> pipka has a handbag
<mjg59> Bugger. All the LCA accommodation has gone.
<jdub> YokoZar: :-)
* thom 's mental image struggles with pipka carrying a handbag
<thom> sorry, don't believe you
<jdub> i'm serious!
<jdub> dude, i can get photos
<jdub> hold on
<thom> you'll have to
<mjg59> Serious as cancer?
* mjg59 goes to the pb
<mjg59> pub
<mjg59> Argh
<thom> mjg59: dude, you've obviously been drinkin' already ;p
<dholbach> *grrrr* why does  gnome_program_init()  crash *cry*
<jdub> nah, it would just not be the same if it weren't pipka+handbag
<jdub> (she's asleep now)
<thom> ahr
<thom> oh well; i'll continue to disbelieve you then
<dholbach> hai ogra
<Kamion> elmo: can http://people.ubuntulinux.org/patches/ be made to work again, please? It used to work, and I mailed some patches to Debian on that basis; now I'm getting grief because they don't work any more.
<ogra> dholbach
<ogra> hi
<Kamion> or for that matter
<Kamion> thom: ^---
<thom> i'll take a look post breakfast
<Kamion> ta
<thom> (and yes, i know it's getting on for 1pm :-) )
<ogra> hehe...
<Kamion> not as if I've had breakfast yet ...
* ogra lies still in bed....
<dholbach> anyone who would like to test if coaster-0.1.4 just crashes on my box (amd64) or anyone would like to provide a manpage, while i battle gdb? ;-)
<T-Bone> Kamion: hi, got my last message?
<dholbach> brb
<ogra> i have very bad news....
<ogra> to make this work: http://www.grawert.net/hal_cpu_patch.png http://www.grawert.net/hal_acpi1.png http://www.grawert.net/hal_acpi2.png .....
<ogra> acpi has to be stared before hal.....which extends the bootime by a second :(
<ogra> mdz ^^^
<Kamion> T-Bone: which one?
<T-Bone> Kamion: the one i sent yesterday, summarizing what's up with ia64 and the 'hal bug'
<Kamion> T-Bone: did you get my mail saying that I think it's architecture-independent?
<thom> ogra: yeah, that's total crack, i've been following the threads on the hal list
<ogra> thom: i backported it to our hal ;)
<thom> ogra: i suspect we'll be taking a different approach :-)
<T-Bone> Kamion: nop
<ogra> thom: before hoary ?
<thom> ogra: we'll see
<T-Bone> Kamion: ah bummer. You sent it to @parisc-linux.org ?
<dholbach> re
<Kamion> T-Bone: yeah, think so
<T-Bone> Kamion: FtC (*@parisc-linux.org and a few debian machines) is down for the week end. Can you resend it to varenet@esiee.fr please?
<Kamion> T-Bone: bounced
<T-Bone> Kamion: got it, thx
<Mitario> hi everyone
<T-Bone> Kamion: i'm definitely _NOT_ running in expert mode
<T-Bone> the amd error occurs in non expert mode 3 times
<T-Bone> and networking was up. It downloaded a few Releases/Packages files but took an error at the end
<T-Bone> and i have NFC what needs to be done to get a driver hotplug-capable :P
<T-Bone> for the rest I'll look at it post-breakfast
<T-Bone> (and yes it's 2PM) ;}
<Kamion> T-Bone: huh, weird
<T-Bone> Kamion: was mostly looking like it couldn't fetch some release/package file actually
<T-Bone> i'll try to find out in a bit
<T-Gone> Kamion: the problem being that aptitude starts immediately, thus making it impossible to read the message
<T-Gone> (that's imho a bad thing (tm))
* T-Gone is off now
<Kamion>   rhythmbox: Depends: gstreamer0.8-mad which is a virtual package.
<Kamion>   libopenh323-1.13.2: Depends: libpt-1.6.3 but it is not installable
<Kamion>   libpt-plugins-v4l: Depends: libpt-1.6.3 (= 1.6.6.4-5.1) but it is not installable
<Kamion> anyone working on that lot?
<Kamion> T-Gone: the message is logged in /var/log/base-config.log
<zopi> Hi
<zopi> is it plan to add gst-ffmpeg on Ubuntu ?
<zopi> http://freshmeat.net/projects/gstreamer/?branch_id=55564&release_id=183840
<zopi> there is a package for Debian already on alioth
<tseng> zopi: its a legality issue, I believe
<zopi> pkg-gnome.alioth.debian.org/debian/pool/g/gst-ffmpeg/
<zopi> huh ?
<dholbach> does anyone know, who Jakob Schurdak is? or if he's on IRC?
<Kamion> ah, finally, working networking on the OQO
<Kamion> we need linux-wlan-ng in main
<jdub> Kamion: woo :)
<Kamion> I don't get to use the CD-ROM and networking at the same time, but hey ...
<jdub> oh?
<Kamion> well, DVD-ROM
<Kamion> USB DVD-ROM and USB network adaptor; only one USB slot.
<jdub> ahr
<Kamion> don't think I have a hub either
<jdub> how's everything else? mouse?
<Kamion> haven't got the mouse working yet, but one of the guys mailed me an xorg.conf which I'll try in a moment
<Kamion> just installing ubuntu-desktop over ssh
<jdub> rad!
<Kamion> until I had networking working, it was too painful to do any significant text-mode development
<Kamion> the keyboard is usable for short periods, but hacking on it sucks
<Kamion> just fixed up base-installer for it, since it didn't know about transmeta CPUs
<jdub> whoa
<Kamion> (wasn't a showstopper, it fell back to 386 anyway, so didn't make a difference on cdrom installs)
<trulux> mdz: ping
<Kamion> so, are we removing -mad support from rhythmbox, or what?
<Kamion> it seems a shame not to have it able to play MP3s if gstreamer0.8-mad is installed; does it have the ability to use plugins?
<Kamion> it doesn't seem to actually link against the gst backends ...
<tseng> right now muine uses the libs directly to read metadata, and gst/xine for playback
<tseng> i think the other gst players are in the same boat
<rubenv> Kamion: heh?
<rubenv> still plays mp3 here :)
<Kamion> I'm really just wondering if rhythmbox can be made to work without gstreamer0.8-mad installed, yet still have the added functionality if gstreamer0.8-mad is installed
<Kamion> rubenv: yes, it still depends on gstreamer0.8-mad
<Kamion> rubenv: the problem is that rhythmbox is in main while gstreamer0.8-mad is in universe, so it can't stay that way
<rubenv> seems like the whole file formats thing should be made modular
<tseng> rubenv: thatd be fine, when everyone switches to using gst for reading metadata
<rubenv> ain't the xine metadata horribly broken on RB?
* rubenv remembers pleas on the mailing list not to use xine for metadata
<jdub> Kamion: rhythmbox doesn't need the gstreamer plugin installed
<jdub> Kamion: without it, it doesn't do mp3; with it, it does
<rubenv> so basically there's nor problem at all
<Kamion> jdub: in that case I'll fix our package to stop depending on it
<tseng> oh, i thought he wanted to remove mp3 support more
<jdub> Kamion: (this is exactly what we did for warty)
<jdub> Kamion: hrm, bad merge?
<tseng> jdub: tomboy today? sorry to sound like a broken record
<jdub> tseng: ahr!
<jdub> tomorrow
<tseng> its nearly freeze
<jdub> it is very near to bed time here
<tseng> alright dude, have a good one.
<Kamion> jdub: could be, looking
<daniels> fabbione: er, i915 is intel, dude
<aj> hoary's xorg with a manually added horizsync/vertrefresh worked fwiw
<Kamion> jdub: yeah, looks like a plain merge glitch, fixing
<thom> gar, I want mono on amd64
<jdub> thom: mint doesn't work?
<thom> jdub: bootstrap hell
<jdub> heh
<jdub> eek
<jdub> ah, bedtime.
<thom> jdub: 1.1.3 would be the right solution ;-) 
<thom> g'night
<daniels> aj: bong.  please send over xorg.conf and Xorg.0.log.
<daniels> jdub: yes
<jdub> thom: my desktop is 2002:dad6:43e3:0:230:1bff:feb3:cd1 :-)
<jdub> but my gateway is not routing to it atm
<thom> that's something of a show stopper ;-)
<thom> my ISP has native v6 support on it's dsl, but i need a new router to cope
<thom> uh, its
<jdub> shorewall is a showstopper :|
<thom> shorewall needs to burn in the utmost fires of hell ;-)
<jdub> got a suggestion for a replacement?
<thom> unfortunately not
<jdub> (i don't write firewall assembly, btw)
<jdub> oh
<jdub> same problem here whenever i go looking for something
<thom> i write firewall assembly when necessary
<T-Bone> Kamion: my guess is that there's little chance that making mptscsih hotplugable is a good idead actually: you need it to boot the box no matter what after the installation, and some machines ship with SCSI CD drives
<T-Bone> Kamion: imho the right thing to do is to have it preloaded at initrd time
<Kamion> T-Bone: we are using hotplug for hardware detection in general
<T-Bone> as mptbase is already
<Kamion> T-Bone: there's a project in the works to have hotplug running in the initrd to figure out what to load
<Kamion> so mptscsih should be made hotpluggable
<T-Bone> Kamion: well then you have to tell me how to do that
<Kamion> there are others around here far more qualified to do that than I
<T-Bone> Kamion: are we trying to increase boot time on ubuntu?
<Kamion> mdz knows the basics
<Kamion> at least
<Kamion> T-Bone: er, no
<Kamion> we're trying to make hardware detection not a screaming nightmare
<T-Bone> Kamion: well then even tho i can imagine why you want to hotplug everyhting, you'll end up increasing it anyway I'm afraid ;P
<Kamion> not significantly
<lupus_> is gaim default download folder pointing to Desktop?
<Kamion> the number of modules in the initrd is not large, and grepmap speeds it up enough
<T-Bone> depends on the hardware
<lupus_> like it is ubuntu policy
<thom> Kamion: p.u.c/patches/ works now
<Kamion> thom: thanks
<T-Bone> Kamion: loading the initrd is already a slow operation on some machines
<Kamion> look, we're committed to hotplug; none of the other hacks were sufficiently maintainable
<Kamion> so the solution to any gripes with hotplug is to fix hotplug. :)
<Kamion> I am *certainly* not going back through the installer and undoing all the changes I made to make it use hotplug
<Kamion> even if it weren't a hoary goal
<T-Bone> heh
<T-Bone> that's fine by me. I know how to disable initrd/hotplug when i want to :)
<Kamion> look for MODULE_DEVICE_TABLE sections in other drivers; that should be a good starting point
<T-Bone> (and i usually do)
<Kamion> T-Bone: jbailey is the one working on hotplug in initramfs
<T-Bone> Kamion: the base-install.log is absolutely cripled. Is that a dump of what's actually displayed on the screen? It's barely human readable
<Kamion> it's generated by 'script'. Yeah, it's hard to read
<T-Bone> yeah i'll ask jeff asap
<Kamion> doesn't matter though 'cos you're generally only looking at it for debugging :)
<T-Bone> i'm surprised since I'm finding error messages there that I haven't even noticed during base install
<Kamion> T-Bone: anyhow, hoary's boot with hotplug almost throughout is already faster than most other distributions
<T-Bone> There was a prm installing the selected software  One or more packages failed to install. This may be due to bugs in the  packages, or you may be ouof disk space or experiencing some other  problem.
<T-Bone> this is what it says
<Kamion> right, probably uninstallable ubuntu-desktop
<Kamion> this happens a fair bit I'm afraid :(
<Kamion> I'm fixing up one of the problems right now, that's the rhythmbox thing
<T-Bone> doh
<T-Bone> found the culprit
<T-Bone>   openoffice.org-debian-files: Depends: openoffice.org-bin (> 1.1.2+1.1.3) which is a virtual package.
<T-Bone>   openoffice.org: Depends: openoffice.org-bin (> 1.1.2+1.1.3) which is a virtual package.
<T-Bone>   ia32-libs-openoffice.org: Depends: lib32gcc1 (>= 3.4.2-2ubuntu3) which is a virtual package.
<T-Bone> now that suprises me alot; i ran apt-get install ubuntu-desktop by hand and it worked just fine
<Kamion> oh, um, argh, that's going to be complicated
<Kamion> elmo: around?
<T-Bone> lol
<Kamion> elmo: does your stuff that generates Task: ubuntu-desktop lines use current germinate / otherwise take account of architecture-specific seed entries?
<Kamion> elmo: openoffice.org* shouldn't have Task: ubuntu-desktop on ia64
<Kamion> T-Bone: if you used 'aptitude install \~tubuntu-desktop', you'd see the problem
<T-Bone> correct
<T-Bone> just reproduced it
<Kamion> T-Bone: we have 90% of the infrastructure for fixing that though, in germinate (colin.watson@canonical.com--2004/germinate--mainline--0 if you want to look); looks like it just needs to be pushed out to one more place
<T-Bone> what's that URL?
<T-Bone> oh
<T-Bone> that's an arch thing?
<Kamion> yeah; install bazaar
<Kamion> then 'baz register-archive http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2004'
<Kamion> then 'baz get colin.watson@canonical.com--2004/germinate--mainline--0'
<T-Bone> gah
<Kamion> (or tla works too)
<T-Bone> yeah but it's "arch" you know
<T-Bone> ;P
<aj> daniels: ?
<aj> daniels: what do you want to conf/log for? (is the one that worked useful?)
<daniels> aj: if you have to think about touching xorg.conf, it's a bug -- non-working (default) conf/log is useful to me so i can hopefully fix it
<thom> seb128: nautilus/gamin is hosed
<daniels> night kiddie-winks
<dholbach> thom: even with jdub's new upload?
<thom> dholbach: how new is new
<thom> night daniel
<dholbach> thom: 2-3 hours
<dholbach> thom: 0.0.21-0ubuntu2
* dholbach thought his nautilus/gamin was nice
<Kamion> T-Bone: (of course, fixing OOo on ia64 would be good, too ... :-) but that may be beyond the resources you have, OOo being the monster it is)
<T-Bone> you damn betcha :)
<T-Bone> and i hate java
<T-Bone> ;)
<thom> dholbach: lets try that
* Kamion wonders why openoffice.org2 failed to build on powerpc
<seb128> thom: what ?
<tseng> morn mxpxpod 
<dholbach> hi mxpxpod
<mxpxpod> tseng: mornin'... what's up?
<mxpxpod> hey dholbach!
<tseng> mxpxpod: nm dude, see priv
<mxpxpod> tseng: got it :)
<Kamion> haggai: seems to be a missing include of <stdio.h> or <cstdio> or whatever in src680-m66/desktop/source/m
<Kamion> igration/services/jvmfwk.cxx
<Kamion> haggai: (sorry for broken line), judging from the powerpc build log
<Kamion> haggai: (openoffice.org2)
<mxpxpod> tseng: what has improved in tomboy 0.3.1?
<tseng> mxpxpod: see .changes
<mxpxpod> tseng: ah, ok
<mxpxpod> dholbach: thanks for the translation
<mxpxpod> dholbach: I'm going to make a 0.1.4.1 release today
<dholbach> mxpxpod: cool! :-)
<dholbach> mxpxpod: just wrote a manpage for coaster and got a fully-compiling package without any lintian-warnings - bad thing is: still a segfault in gnome_program_init() :-(
<mxpxpod> dholbach: I have a fix for the egg libraries from bugzilla
<mxpxpod> dholbach: that's strange... I'd like to see a backtrace
<dholbach> mxpxpod: it's very short, i'll send it in a query
<rubenv> dholbach: when trying to build coaster pkgs a while ago, i got the same probs
<mxpxpod> dholbach: ok
<mxpxpod> that's really really strange... I'm on ubuntu hoary and it works fine for me compiling from source
<thom> seb128: nautilus doesn't appear to be updating the Desktop when files land in ~/Desktop; I have to open Desktop as a folder and reload it
<dholbach> rubenv: were you able to fix it?
<rubenv> dholbach: because of upcoming exams i didn't start to look into the source :)
<dholbach> rubenv: hmmm, i'll have an exam next week monday too (in fact my last ;-))
<mxpxpod> dholbach: could you file a bug?
<mxpxpod> in coaster's bugzilla with that trace?
<mxpxpod> rubenv: what arch are you on?
<rubenv> thom: click on desktop, ctrl-r, saves you time when gamin doesn't do it ;)
<rubenv> i386
<mxpxpod> hmm
<seb128> thom: blame gamin/inotify :)
<mxpxpod> powerpc works fine ;)
<dholbach> mxpxpod: of course... just wasnt sure, if i broke the libraries or something
<thom> rubenv: shrug, i don't really care, i'm just reporting the bug :-)
<thom> seb128: heh
<thom> seb128: not gtk+, then?
<rubenv> dholbach: me tuesday, also last
* rubenv back to study :)
<dholbach> mxpxpod: but inkscape and regexxer worked fine with those g*mm packages
<seb128> thom: gnome-session-remove nautilus && GAM_DEBUG=1 nautilus
<dholbach> rubenv: i'll have my fingers crossed
<mxpxpod> dholbach: hmm
<rubenv> dholbach: thx, will do the same
<mxpxpod> dholbach: file a bug and I'll take a look at it
<mxpxpod> dholbach: that really confuses me
<dholbach> mxpxpod: i can easily imagine
<mxpxpod> because it's usually powerpc that has problems :)
<dholbach> mxpxpod: just the same with amd64 ;-)
<mxpxpod> dholbach: what's your repo's address again?
<thom> *sigh*; once i g-s-r'd nautilus and reran it, it works. 
<dholbach> mxpxpod: http://ubuntu.stufenseite.de
<thom> killall nautilus however hadn't cured it
<mxpxpod> is gamin replacing fam finally?
<dholbach> mxpxpod: but i'll move another coaster package to it later (when i figured that *grmbl* manpage out)
<dholbach> mxpxpod: yes, since 0.0.21-0ubuntu2
<mxpxpod> dholbach: you should really set up a repo that people can apt-get from
<dholbach> mxpxpod: if you tell me how...
<tseng> dholbach: second
<mxpxpod> dholbach: we can work on it tomorrow
<dholbach> mxpxpod: i dont want it to be a lasting institution
<tseng> dholbach: ill msg you a quick script
<mxpxpod> rubenv: did you build coaster from source or did you use dholbach's pkgs?
<rubenv> from source
<rubenv> but it's quite some time ago
<mxpxpod> rubenv: did you build the *mm libs from source too?
<rubenv> (the coaster that still had bakery)
<rubenv> mxpxpod: no
<mxpxpod> rubenv: ohhh
<mxpxpod> rubenv: the reason that crash didn't work was because bakery 2.3.11 had a different virtual method API than 2.3.10
<mxpxpod> s/crash didn't work/crashed/
<mxpxpod> dholbach: so, rubenv's crash is different from yours
<mxpxpod> yours still puzzles me
<dholbach> mxpxpod: one guy in the gnome BTS said, he had 0.1.4 working on hoary
<mxpxpod> dholbach: yup
<dholbach> mxpxpod: but he didnt have the libraries
<mxpxpod> dholbach: try building the *mm stuff from source and then building coaster and tell me if you still get that crash
<mxpxpod> if you don't, it's something with your libs
<mxpxpod> :)
<dholbach> strangely enough, it's /usr/lib/libgnome-2.so.0
<dholbach> nothing i covered in the packages at all
<mxpxpod> bbiab
<dholbach> well guys... see you later (in an hour or two)
<kent> on the hardwaresupport section of the wiki, I added a page for webcameras. Can some one check it and tell me if i did the right thing? I think I did the right thing, but I can remove it if it was wrong of me.  :)
<rubenv> looks fine to me
<marcin_ant> hello - short question - is Beagle installable/buildable (from cvs) on hoary?
* thom pokes mjg59 idly towards his query window
<mx|gone> tseng: has tomboy changed their notification area icon yet?
<mjg59> thom: Oh, hi
<rubenv> marcin_ant: i heared that jdub was making pkgs somewhere
<dholbach> re
<srbaker> anyone here doing the ubuntu thing on an ibook?
<srbaker> i'm thinking about trading these two notebooks for an ibook g3
<marcin_ant> rubenv: ok - thanks - I just was trying to follow procedure described on this page: http://www.ubuntulinux.org/wiki/BeagleInstallHowto
<marcin_ant> rubenv: but it doesn't work
<sladen> srbaker: tonnes of people
<tritium> seb128, did rhythmbox used to say "Paused" when playback is indeed paused?  It looks like fix for #5926 prevents "Paused" from ever being indicated.
<srbaker> sladen, what's the verdict on speed?
<srbaker> i'm thinking of going from a p3-750/192M to a g3 500/640M
<sladen> srbaker: only you can be a judge of that.
<mjg59> thom: Yeah, that looks good
<srbaker> sladen, that doesn't help much.
<seb128> tritium: dunno, the fix has been to drop the broken patch
<thom> mjg59: anything to add?
<sladen> srbaker: this is probably a question that belongs on #ubuntu (this is a development related channel)
<tritium> seb128, I don't recall the behavior from before either
<mjg59> thom: Nothing that springs to mind
<mjg59> I'll play with the apm stuff later today
<seb128> tritium: the current one, since the package has been patched and now the patch has been dropped
<seb128> tritium: so it's back to the previous one
<tritium> okay, thanks.
<seb128> np
<srbaker> sladen, i'm interested in hearing it from developers.  i know the difference.
<titoo> Hello, any IBM laptop users? Ubuntu is not supporting my internal modem (t41p), I can use my laptop for testing if you have an idea but not the same hardware.
<Mithrandir> titoo: I use an IBM laptop, but I couldn't care less about the internal modem. :P
* rubenv recently noticed you could remove the modem
<rubenv> laptop now 2grams lighter :)
<Mithrandir> ooh, I should do that. ;P
<Mithrandir> (as I have an x40, so anything to get it lighter)
<rubenv> dell here
<Mithrandir> ew.
<Mithrandir> I _seriously_ don't like dell due to personal experiences.
* rubenv hugs his dell
<rubenv> Mithrandir: what happened?
<Mithrandir> rubenv: I wore out two in less than a year, got fucked over a couple of times and wasted a lot of time on trying to fix it.
<Mithrandir> (basically)
<rubenv> :)
* rubenv hugs his backup policy
<rubenv> (just in case ;))
* dholbach wonders, what's wrong with getting fucked a couple of times. :-)
<titoo> Mithrandir: :( I am only needing 1 week a year... forced to use Windows 
<Mithrandir> titoo: buy (or just get) a real modem?
<titoo> Mithrandir: I am looking at what is done on the Debian side, I may find
<Mithrandir> titoo: there are supposed to be some solutions for those stuck with mwave modems, but I've never looked at it myself.
<titoo> Mithrandir: True that I can get my old USRobotics out of the dust :)
<Mithrandir> titoo: I'd do that if I were you -- probably less work. :)
<mjg59> rubenv: It's an hsf modem
<mjg59> There's no open driver
<mjg59> Uh, s/rubenv/titoo/
<titoo> mjg59: Thanks for the info, I understand the support pb...
<dholbach> WOOOOOOHOOOOOOOO!!!!!
* dholbach shakes his derrire:        http://ubuntu.stufenseite.de/coaster.png
* rubenv wants those pkgs
<dholbach> just a sec
<dholbach> have to upload it
<rubenv> *poke* *poke* *whip* faster i tell ya
<dholbach> rubenv: start building the g*mm-libraries unless you have amd64 :-)
<rubenv> source debs anywhere? :)
<dholbach> http://ubuntu.stufenseite.de 
<rubenv> jummy :)
<dholbach> i'll try to make  tseng 's script work later; so you'd at least be able to  deb-src  them
<rubenv> wget -r for now ;)
<dholbach> rubenv: you'd just need the .dsc and .gz files :-)
<smurfix> dholbach: isn't the volume name used by ubuntu these days, too?
* rubenv is a barbarian ;)
<dholbach> smurfix: ask mx|gone - it's his code :-)
<smurfix> That's not code, that's a string in a .po file. ;-)
<dholbach> smurfix: you're right, tomorrow there'll be 0.1.4.1 which has german translation :-)
<dholbach> i'm so happy that it works :-)
<dholbach> s/that//
<dholbach> rubenv: you won't need the timer-applet :-)
<rubenv> yeah, i noticed it slipping in ;)
<dholbach> rubenv: i'll do an 0.1.4-2 upload, which is proper
<rubenv> take your time
<rubenv> mm stuff first ;)
<dholbach> rubenv: nice to have you testing :-)
<rubenv> with pleasure :)
<rubenv> bleh, my puilder chroot is hopelessly outdated :)
<dholbach> rubenv: i never got mine working actually :-(((
<rubenv> dholbach: what's the problem?
<dholbach> rubenv: it complains about gcc not being able to compile executables
<rubenv> eh?
<rubenv> i'll tell you what mine does in a sec :)
<rubenv> it's been a while since i used it
<dholbach> rubenv: but it's the same with each and every .dsc i feed it :-(
<thom> bet you don't got build-essential installed 
<dholbach> thom: but i wonder why
<dholbach> thom: i even told it    EXTRAPACKAGES=build-essential
<rubenv> ah i hate ide :)
<dholbach> rubenv: ide?
<ubernoob> i upgraded to horax, and now x-screen wont start :( i just get a blank screen. anyone know what the problem might be?
<ubernoob> *horay
<rubenv> dholbach: the beloved hard disk interface we all like ;)
<thom> ubernoob: users questions in #ubuntu, please :-)
<ubernoob> thom: ok. sorry
<dholbach> rubenv: be sure to grab  coaster_0.1.4-2*   - i'm cooking something
<rubenv> glibmm is building
<rubenv> glibmm builds perfectly :)
<Nigelenki> pitti:  ping
<rubenv> hmmm, i wonder how to make pbuilder pick up my freshly built pkgs
<dholbach> rubenv: pick up?
<rubenv> yeah, how to get pbuilder to use my freshly built glibmm
<rubenv> must be first time i'm building a fresh dep tree
<dholbach> rubenv: i use  debuild && sudo debi
<rubenv> normally my libs were in universe
<dholbach> well   dpkg-source -x <bla>.dsc; cd <bla>; debuild && sudo debi
<rubenv> yeah, but i'm trying to build em in chroot
<rubenv> normal building then :)
<dholbach> rubenv: you were on i386?
<abelli> sladen: ping
<abelli> or ding
<rubenv> dholbach: yes
<dholbach> rubenv: so we'd need someone on powerpc to test it too ;-)
<sladen> abelli: is 'ding' the sound a bicycle makes?
<abelli> sladen: could be yeah
<thom> yay, elmo is doing NEW
* dholbach yays too! :-)
<mdz> jdub: ping?
<YokoZar> jdub: You asked me something earlier (roughly 8 hours ago) ?
<sid77> hi
* Mithrandir twaps pam_env
<Mithrandir> Kamion: http://err.no/patches/pam_env_per_user.diff ; what do you think of something along those lines to have an ~/.pam_environment which could be touched by the utf8 migration tool (and anything else that wants to handle such a file with a somewhat-predictable format)
<Kamion> Mithrandir: going out soon so I haven't reviewed it in detail, but the spirit looks fine; I assume it has the same format as /etc/environment, that an assignment in ~/.pam_environment supersedes any assignment of the same name in /etc/environment, and that if a name isn't mentioned in ~/.pam_environment then the value from /etc/environment is used?
<Kamion> I think that'd basically be my spec
<mdz> Kamion: what would be the consequences of skipping the location question on the live CD?
<mdz> bad keyboard layout defaults?
<Mithrandir> Kamion: yeah, that's the idea at least.
<Kamion> mdz: you wouldn't get a full locale. I don't want en_US ...
<Mithrandir> Kamion: I had to whack pam_env a fair bit to make it suck in different ways -- the code should be completely rewritten, but that's for another day.
<Kamion> mdz: language and location are a single udeb now, partly to emphasise the fact that they really can't be split up
<mdz> Mithrandir: I don't remember if I heard from you regarding evms-udeb; did you have a chance to look into it?
<Mithrandir> mdz: I've looked at it a bit and if we want to support all of what evms is capable of, it's a fair chunk of work (and frankly, I'm not sure we should do it, as the UI will be horrible).  If we just want to do what partman-lvm is doing (and which should be enough for a lot of the use cases we're interested in, it's a couple of days of work.
<Mithrandir> mdz: so the answer is "it depends".
<mdz> Mithrandir: I think trying to do everything EVMS does through a cdebconf UI would be horrific
<Mithrandir> mdz: yes, I agree.
<robertj_> hey mdz: do you know anything about gecko#?
<mdz> we should provide the basic types of configurations that people want to use on their root filesystem
<mdz> robertj_: nope
<mdz> e.g., RAID, LVM and RAID+LVM
<robertj_> the dashboard guys said jdub was giving it some TLC to work with beagle .5+
<Mithrandir> mdz: that ought to be doable with, somewhere around a week of work, I think.
<mdz> Mithrandir: could you email me a quote based on this basic spec?
<mdz> Mithrandir: how is the utf8 migration tool going?
<Mithrandir> mdz: I've found out how to do it and begun hacking the surrounding stuff (like, we probably want http://err.no/patches/pam_env_per_user.diff to have pam_env support ~/.pam_environment.  Else, we'd have to migrate the whole system at once.
<mdz> Mithrandir: migrating the whole system at once is fine for the desktop, really
<Mithrandir> mdz: I'm designing it to work in two modes -- per user and whole-system.  Whole system will convert all users' home directories, change locale in /etc/environment, stuff like that, while per-user will just do it for one user.
<Mithrandir> most of the code will be shared, so that shouldn't be a problem.
<Kamion> mdz: (oh, note that if there's only one sane country to pick for that language, then the country question will already be skipped; try e.g. Greek)
<mdz> Kamion: oh, ok
<Kamion> well, s/skipped/asked at medium priority/
<mdz> Kamion: do we use 'high' now, or still 'critical' by default?
<Kamion> high
<Kamion> fixed some automatic install issues that way
<Kamion> mdz: oh, did you see http://people.ubuntu.com/~cjwatson/kickstart.png?
<mdz> I was thinking that casper's needs probably correspond fairly closely to what I imagine 'critical' ought to be
<Kamion> mdz: yes, very possibly indeed
<mdz> re: kickstart.png, no, I hadn't
<Kamion> although critical is kind of intended to be used in conjunction with a tuned preseed file, at the moment
<mdz> is that a modified version of RH's kickstart tool?
<Kamion> yep
<Kamion> getting there; should have *something* in by feature freeze
<Kamion> though not everything will work yet in that timeframe
<mdz> speaking of which, could you make a quick pass over HoaryGoals and make any appropriate status updates for your items?
<Kamion> then I have a piece that sits in the initrd, reads kickstart files, and sets the corresponding debconf questions
<Kamion> ah, yes, been meaning to do that
<mdz> so the output from that tool is a kickstart file, which will be read by some kickstart-aware d-i component and used to provide answers to debconf questions?
<Kamion> right
<mdz> neat
<mdz> what's the normal way to provide the file?
<Kamion> should I take myself off the UTF-8 goal, or leave myself there as documentation?
<mdz> (the latter)
<Kamion> various, you boot with ks=<stuff>
<mdz> the documentation team guys will be going through that list at some point to write up the release notes
<Kamion> pretty much the same modes of operation as preseed
<mdz> and they'll want to contact people for more information
<Kamion> there will be a small amount of suckage with regard to things that run before hardware detection; I'm not sure if I'll be able to fix those or whether we'll just have to tell people to add some extra bootloader options for hoary
<mdz> ah, hmm
<mdz> language/location/keyboard fall into that category, right?
<Kamion> yeah
<Kamion> preseed has the same problem, so it's not new
<Kamion> anaconda basically runs appropriate hardware detection early in kickstart mode
<Kamion> which is not necessarily infeasible in d-i, if you accept some messages being untranslated; I haven't tried it out though
<Nuak> hi all
<Nuak> i want to collaborate in the rosetta project
<Nuak> translating into spanish
<Kamion> mdz: HoaryGoals updated
<Nuak> do you know where i can register myself into the rosetta project?
<mdz> Nuak: there is a channel specifically for Rosetta questions/discussion, #rosetta
#ubuntu-devel 2005-02-11
<Kamion> mdz: I'll do that udevstart change tomorrow
<mdz> thanks and thanks
<Kamion> ta for the idea
<mdz> untranslated messages sound OK for unattended installs
<mdz> I guess it only sucks if some detection step fails
<Kamion> I tend to agree. The only issue is if it has to stop and wait for keyboard input
<Kamion> but most people can probably cope in an emergency
<HrdwrBoB> unless they have a usb keyboard
<Kamion> anyway, time for !work
<HrdwrBoB> with no legacy emulation
<HrdwrBoB> eg:mac
<Kamion> HrdwrBoB: that's already set up before the keyboard chooser runs, or you would not be able to select your language.
<HrdwrBoB> true
<Kamion> we're not talking about not doing keyboard hardware probing
<mjg59> What's the situation with respect to the kernel at the moment?
<HrdwrBoB> apparently thought he low memory detector runs before hotplug
<Kamion> this is purely layout
<mdz> Kamion: did smurfix talk with you about integrating the keyboard layout selector?
<Kamion> mdz: yes, I gave him some hints
<mdz> ok, good
<Kamion> HrdwrBoB: it runs before hw-detect, but hotplug does stuff well before that in practice.
<Kamion> HrdwrBoB: there's also usb-discover, which runs in debian-installer-startup.d
<mjg59> There's a couple of patches I could do with getting in
<Kamion> really gone
<YokoZar> Hey, can someone help me out with a package?
<YokoZar> It's sort of half compiling (gets to the .deb file, but errors before asking for my key)  The deb file works though
<YokoZar> deb-src http://tuzakey.com/~scott/apt source/
<dholbach> YokoZar: what does it say? what error messages?
<YokoZar> The package is winetools
<YokoZar> It's a make: clean error - "no package"
<dholbach> YokoZar: and before that?
<YokoZar> Before that it finishes the build package step I think
<dholbach> YokoZar: the build-depends are surely wrong
<dholbach> YokoZar: i mean debian/control
<dholbach> brb
<srbaker> doesn't ssmtp do what sjr wants?
<tseng> srbaker: having only read the summary in ubuntu traffic, i believe ssmtp does
<srbaker> good
<tseng> its the default mta in gentoo to fill the same niche as described
<tseng> /usr/bin/sendmail w/o listening daemon
<srbaker> excellent
<srbaker> the unfortunate thing about gentoo is that there are a few smart people wasting their time on it :(
<srbaker> those people would have their efforts better spent on Debian, Ubuntu, Fedora, or FreeBSD.
<tseng> i spend time on both, incidentally
<srbaker> tseng, ahh.  you're wasing some of your time, then ;)
<tseng> srbaker: the hardened gentoo project is currently a fair bit ahead of anyone else in the area.
<tseng> unless you count security-by-marketability ala redhat
<srbaker> fedora is pretty good at security
<tseng> erm, not at hardening
<tseng> ill not discuss it too much here, but there are several glaring flaws in ES, and their use of PIE is limited
<tseng> and they ignore SSP entirely.
<srbaker> not ES.  Fedora.
<tseng> i assume you are talking about reactive security, which im not talking about
<srbaker> ?
<srbaker> no, i'm talking about preventative security
<tseng> so whats good about it
<srbaker> the default selinux policy is quite good
<tseng> you mean the targetted policy?
<tseng> it only protects a select few apps, same as their PIE strategy
<tseng> but anyway, fedora is OT here, and ubuntu can do better.
<dholbach> good night guys... i'm off to bed :-)
<tseng> cya dholbach.
<dholbach> and be sure to check out the new  coaster  packages :-)
<dholbach> and be sure to check out the new  coaster  packages :-)
* tseng plays the jdub theme song
* jdub cries for his firewall
* HrdwrBoB says the last rites
<dholbach> tseng: damn, now i didnt look after the script you gave me
<dholbach> *fiddle around*
<tseng> i looked at your site
<tseng> and that script wont help you much
<tseng> it assumes all packages are in one dir
<dholbach> tseng: every *.deb *.dsc *.orig.tar.gz *.diff.gz - everything?
<tseng> heh, yes
<dholbach> i erm... see
<tseng> you could split deb and source
<tseng> or use a more complex method
<dholbach> no... it's complex enough for me... given the time ;-)
<tseng> i havent experimented with multi dir repos
<dholbach> i hate my internet connection :-/
<dholbach> but it works... thanks tseng :-)
<dholbach> so when this upload should *ever* be over... 
<dholbach> the upload will still take like 15 minutes, but if anyone of you is interested in (1) amd64 binaries:   deb http://ubuntu.stufenseite.de/Repo ./   or  (2) sources:   deb-src http://ubuntu.stufenseite.de/Repo ./
<dholbach> (of coaster and g*mm & co :-))
* jdub boggles at 6024
<mdz> it's a bug, dude
<jdub> that's why it's in the bug tracker!
<mdz> which aspect of it triggered the boggle?
<mdz> did you get my email about gnome-bt?
<jdub> someone finding it and bothering to report the bug
<jdub> yes
<mdz> I installed it; the package seems quite sane
<mdz> installed, clicked on .torrent in firefox, everything went
<marcin_> jdub: sorry that I'm asking you a question about website contest, again - but are you really going to judge skins and mockups equally? even when these mockups won't be usable (to hard to implement as real skins or too "heavy" and require too much bandwidth) but just pretty?
<jdub> marcin_: sure
<jdub> marcin_: they'll be judged on their appropriateness for the ubuntu website
<marcin_> jdub: i just have some projects as images and don't know if just send them as they are or work on html...
<jdub> the announce says you're welcome to send images
<tseng> jdub: tomboy! :P
<marcin_> jdub: hmm ok - than I'll have them ready for tomorrow
<jdub> tseng: i will put it on my list for today :)
<marcin_> jdub: thanks :)
<tseng> jdub: yay!
<crimsun> (as an aside, mono* 1.0.5 builds on sid now; the build problem was resolved)
<tseng> crimsun: yay some more
<tseng> except i cant get to alioth currently..
<crimsun> try http://www.meebey.net/debian/mono-suite, though it's currently not responding for me
<tseng> yeah not much luck here either
<mdz> jdub: any reason not to put gnome-bt into hoary and run with it?
<jdub> mdz: i'll look at it today
<mdz> ok
<thom> mdz: is this week of the weird firefox bugs?
<thom> :-)
<jdub> i doubt i'd say no; we need one, even as a transition to something much nicer
<jdub> thom: you've seen the weird text highlighting / overlap stuff?
<thom> jdub: only with a really teeny font in a text entry box
<jdub> hmm
<jdub> i wonder if it's screenshottable
<jdub> so there's two things i'm seeing:
<thom> and then, only on our bugzilla
<jdub> text seems to run outside right boundaries
<jdub> like on my tabs atm, text runs off the right side (that's shottable)
<thom> please screenshot and bug
<jdub> second thing is when editing, the cursor appears a couple of letters to the left, and i don't see all the text i've typed
<thom> i've seen that, and caillon has mentioned it also
<mdz> thom: this has been happening to me for a while; I only just got around to reporting it
<jdub> hmm, might try two at once
<mdz> I just assumed it happened to everyone
<thom> mdz: i blame squid (even if you don't have a squid proxy)
<mdz> thom: I do use squid, but it happens without it, and even so, I can't think of any way that squid could cause that
<mdz> why the hell would it use anything other than the URL to determine the filename to use?
<thom> neither can i, but i can't imagine why firefox would append .tar.gz to everything
<thom> it might be trying to be smart with the mime type
<mdz> it's not everything; only .gz
<jdub> thom: people.ubuntu.com/~jdub/screenshots/
<mdz> so .orig.tar.gz -> .orig.tar.gz.tgz
<mdz> and .diff.gz -> .diff.gz.tgz
<mdz> I N S A N E
<mdz> jdub: we're talking about #6020; any idea?
<jdub> on sec
* jdub waits for bz
<thom> mdz: that's pretty amazing, really
<dholbach> upload finished
<jdub> mdz: can't reproduce
<mdz> wtf
<mdz> it is "weird firefox bugs that only happen to mdz" week
<mdz> I don't even know where to look for this bug
<jdub> certainly a special one
<mdz> that file saving dialog is gtk, right?
<thom> mdz: yes
<thom> EZ GTK BOOG
<thom> ahem
<mdz> it also seems odd that the "save in folder" selector is blank; is that also only me?
<dholbach> good night guys... now i'm off
<dholbach> *wave*
<thom> mdz: mine comes up with Home by default
<ajmitch> good afternoon all
<thom> so yeah, seems like another one specially for you
<mdz> thom: I have "save all files to this folder: /tmp" in my firefox prefs
<mdz> though switching to "ask me every time" gives exactly the same results
<mdz> I blame file-roller
* ajmitch digs back into hacking
<mdz> or some other random GNOME component
<thom> mdz: even with that setting, i don't get a blank Location
<ajmitch> mono 1.0.5 in universe yet? meebey fixed the build failures with 1.0.4
<mdz> maybe seb128 will have an idea
<thom> mdz: OOI, if you move your .mozilla/firefox directroy out the way, do all these things still happen?
<mdz> ajmitch: http://www.ubuntulinux.org/wiki/UpstreamVersionFreeze
<thom> (and restart mozilla)
<mdz> will try
<mdz> it would be nice if firefox would restore my tabs
<ajmitch> mdz: yes, I've been told it's a bit more flexible with universe
<mdz> like galeon did about 5 years ago
<ajmitch> especially as it gets a package building properly
<mdz> ajmitch: yes, the policy is more relaxed, but no updates happen unless explicitly requested
<thom> mdz: yes, well
<ogra> thom: is this better ? http://www.grawert.net/hal_cpuinfo.png (no more /proc/acpi)
<thom> mdz: firefox doesn't have xsm support yet, tabs are way more advanced ;-)
<ajmitch> mdz: may I request it then? 
<mdz> thom: still happens
<thom> ogra: cool!
<ogra> :)
<mdz> though all my preferences are clearly still there
<ajmitch> I don't think they've been uploaded to sid yet
<mdz> maybe I need to move all of ~/.mozilla?
<mdz> ajmitch: yes
<thom> they shouldn't be. give it a whirl
<mdz> ah, it's using ~/.firefox
<ajmitch> nope, not in sid, just in meebey's local archive
<mdz> is that abnormal?
<thom> mdz: you *have* a .firefox?
<mdz> of course
<tritium> thom, the changelog says that gnomestripe theme is "enabled".  In fact, it seems to have completely replaced the default theme.
<thom> tritium: yes
<thom> tritium: bug already filed
<tritium> thom, okay, thanks
<thom> mdz: um, i think that's somewhat abnormal
<mjg59> So, by hacking the cardbus driver, removing the ACPI processor module and doing some setpci calls on resume, I can get my old Thinkpad to have ACPI love
<mjg59> thom: We're going to have to hack acpid. /etc/init.d/acpid stop only works by accident
<mjg59> On slower machines, acpid is never stopped
<mjg59> Or rather, it only gets stopped after resume, so it comes back up and acpid is no longer running
<mdz> nuking my profile seems to fix the .tgz thing
<mjg59> We need acpid to read a lock file and refuse to execute any events if it exists
<mdz> but the folder selector is still blank
<mdz> and I don't _want _ to nuke my profile ;-/
<thom> interestingly, my laptop has a .firefox, my desktop does not
<mdz> I have files in both ~/.firefox and ~/.mozilla/firefox with recent mtimes
<mdz> it's clearly using both
<mdz> I seem to have one profile in ~/.mozilla/mdz/nthoe233423 and one in ~/.firefox/default/udn2h34oue
<thom> mjg59: lovely. agree on using lock file, will you file a bug?
<mdz> my ~/.mozilla/firefox has only a couple of files in it
<mdz> ~/.mozilla/firefox/profiles.ini says: Path=/home/mdz/.firefox/default/zw3md3kx.slt
<mjg59> thom: Yeah, will do
<mdz> thom: what does your ~/.mozilla/firefox/profiles.ini say in both places/
<mdz> ?
<mjg59> thom: 6026
<mdz> my laptop has no ~/.firefox, and profiles.ini points to a relative path in ~/.mozilla
<thom> mjg59: thanks
<mdz> hell, I have a ~/.phoenix on my desktop
<thom> my desktop is the same as your laptop
<thom> holy crap, .phoenix is OLD SKOOL
<mdz> this home directory goes way back
<thom> and my laptop is the same as your desktop
<mdz> I don't suppose you get cracked out .tgz behaviour on your laptop
<thom> nopd
<thom> uh, that was an attempt at nope
<tseng> mdz: what do you mean by cracked out?
<tseng> i have some pretty odd behaviour
<tseng> opening a tgz in file-roller that ive already opened once.
<tseng> from firefox
<thom> tseng: this is firefox appending .tgz on the end of anyfile ending .gz
<tseng> thats almost as gross.
<tseng> but havent seen it
<lupus_> fabbione, ping
<thom> g'night folks
<ogra> night
<daniels> thom: 'night dude
<tritium> goodnight thom
* daniels beats xserver-xorg.postinst.in with the ugly stick:
<daniels>     if [ "$DEVICE_IDENTIFIER" = "ATI Technologies, Inc. Rage Mobility M3 (AGP)" ]  || \
<daniels>        echo "$DEVICE_IDENTIFIER" | grep -q "Rage 128"; then
<mjg59> Hahaha
<mjg59> daniels: I ought to have a T42 with radeon power consumption issues to play with this week
<tritium> mjg59, and if you can get your hands on a Dell C840, the double-power-button resume issue too ;)
<daniels> mjg59: nice
<tritium> mjg59, or, I'd make time to investigate with your assistance, if you're up for it.
<zul> daniels: ping
<daniels> zul: sup
<jdub> mjg59: is there a useful way of figuring out which devices are sucking power?
<zul> daniels: i saw your bug about the slmodem stuff, i thought the drivers were for the usb modems
<bob2> btw, using udevsendfor /proc/sys/kernel/hotplug has broken ipw2100 as predicted
<jdub>    * Remove speedo and v4l from the list of modules loaded per default.
<jdub> daniels: yay!
<daniels> glcore and dri gone, too
<daniels> since all the dri drivers load dri if they want it
<daniels> and that simplifies the nvidia process somewhat
<jdub> elite :)
<tritium> daniels, good idea
<fabbione> morning guys
<daniels> morning fabbione
<fabbione> hi dani
<mdz> daniels:    * Also from Mesa 6.2.x branch, grab fix for lockups on Radeon M7-class chips     (fd.o#2361).
<mdz> daniels: that sounds like maybe the lockup I was experiencing?
<daniels> mdz: ya-huh
<mdz> yay, I'll give it a try once it's built
<mdz> I had just downloaded the whole set of xserver/xlibmesa/etc. packages you suggested and was dreading having to trial-and-error my way through them
<fabbione> ah there is a fix for the amd64 ia32 emulation crash
<fabbione> good.. 
* fabbione fixes and heads to bed again
* daniels goes to vacuum.
<jdub> daniels: photos please.
<sivang> Morning everyone
<fabbione> mdz: is there anything important i need to look at before i go back and crash?
<mdz> fabbione: you are still feeling sick, eh?
<mdz> fabbione: no, nothing urgent
<fabbione> mdz: fever is going down (to 38 today)
<fabbione> but i don't feel good enough to spend the day in front of the pc
<mdz> it must have been high
<fabbione> mdz: top was 40,4 saturday night
<pitti> Morning!
<pitti> fabbione: still fever?
<fabbione> pitti: yes :(
<fabbione> rmdz: ok.. i am just fixing the amd64 ia32 emulation so that Kamion can test more and i am off again
<sivang> morning pitti , fabbione 
<fabbione> hi sivang 
<pitti> Hi sivang!
<pitti> sivang: What does g-s-t do? :-)
<sivang> fabbione: feeling better?
<fabbione> sivang: a bit, yes.. but still not good enough
<sivang> pitti: trouble? ;-)
<pitti> mdz: oh, thanks for signing my key
<pitti> sivang: still? /msg me...
<sivang> fabbione: thne you should rest until you're better, without the proper resting it could get longer..
<fabbione> sivang: that's what i am going to do :-) but i had to get up a bit from the bed.. my gf is changing sheets and air :)
<sivang> fabbione: eh, that's important when you're ill :) good
<pitti> fabbione: hmm, would some kernel bugs cheer you up?
<pitti> fabbione: (not that I had some...) :-)
<fabbione> pitti: you mean fixes for some bug? yes :-)
<dilinger> pitti: i bet not as much as some kernel security bugs
<pitti> dilinger: hmm, mostly I talk about security bugs :-)
<sivang> pitti: some people reported problem with reading parts of a website in hebrew, notebaly due to /usr/lib/mozilla-firefox/firefox having a variable MOZ_ENABLE_PANGO = 1 , you have any idea?
<sivang> (the hebrew letters were presented backwards)
<pitti> sivang: hmm, no
<pitti> sivang: that means pango is somehow broken?
<jdub> means that pango/firefox integration has issues
<sivang> pitti: might be, because this wasn't apparent until a couple of upgrades a go..
<pitti> ogra: ping
<pitti> doko: here?
<doko> pitti: yes
<dholbach> morning!
<sivang> dholbach: morning
<dholbach> hi sivang
<dholbach> sivang: i tested your g-s-t yesterday - it ran just fine :-)
<dholbach> sivang: but the packaging needs a bit of love - shall i send you a couple of notes?
<sivang> dholbach: cool, I am still working on it , have some quality stuff to fix :) 
<sivang> dholbach: working already with pitt, no need :)
<dholbach> ok
<sivang> dholbach: but tnx
<sivang> dholbach: if you have made them already, feel free to send them thought won't hurt more critisism :) It's always good to be better
<dholbach> sivang: your mail adress is?
<dholbach> hai mvo_
<mvo_> hi dholbach 
<mvo_> morning all
<sivang> mvo_: morning
<pitti> Hi mvo!
<mvo_> hi sivang, hi pitti 
<pitti> mvo_: what is required to build a package with bzip2 compression?
<mvo_> pitti: never done it, but I think dpkg-deb --build on the .bz2 files
<pitti> mvo_: no, I mean compressing the debs with bzip2 instead of gzip
<pitti> mvo_: i. e. foo.deb -> control.tar.gz + data.tar.bz2
<mvo_> I don't know if there is a automatic way yet, but repacking the data+control.gz to .bz2 and call dpkg-deb --build on it
<pitti> bah
<mvo_> pitti: keybuk is not around :) ?
<pitti> no, not yet
<pitti> mvo_: I wanted to catch him already last week, but he was on vac
<mvo_> yes, I noticed. I wanted to ask him stuff about hct
<pitti> I wanted him to fix a dpkg bug :-)
<mvo_> hehe :)
<Kamion> pitti: use the '-Z bzip2' flag to dpkg-deb
<pitti> Kamion: ah, cool
<pitti> Kamion: so, dh_builddep -- -Z bzip2 ?
<Kamion> think so
<pitti> elmo: ping
<d3vic3> pitti, elmo is not around 
<pitti> hmm
<ogra> morning guys
<ogra> pitti: seen this ? http://www.grawert.net/hal_cpuinfo.png :-D http://www.grawert.net/hal_meminfo.png
<pitti> Hi ogra!
<pitti> ogra: today there was an interesting thread on hal@fd.o
<pitti> ogra: a guy presented his procfs code
<pitti> ogra: and it will very likely be merged into hal cvs
<pitti> ogra: however, not in the 0.4 branch
<ogra> pitti: its already beckported ;)
<pitti> ogra: oh, cool
<ogra> back even
<ogra> look at the screenshots above :)
<pitti> looks great
<pitti> ogra: also for powerpc?
<ogra> thom convinced me to use /proc/cpuinfo istead of all this acpi ...
<ogra> yup
<ogra> tested on all 3 warty arches
<pitti> dmidecode will follow?
<ogra> i got a test package up (no clean patch yet) you can try it: http://www.grawert.net/hal_0.4.7-1ubuntu1_powerpc.deb
<pitti> ogra: ahem, shouldn't that be 1ubuntu2?
<pitti> ogra: or, even better 1ubuntu1ogra1 or so? :-)
<ogra> pitti: just for a test ? 
<pitti> nevermind :.-)
<ogra> pitti: i dont want to steal it from sjoerd (will just send in patches) 
<pitti> ogra: sjoerd will include this into sid?
<pitti> that's even better...
<ogra> ah, and this one: http://www.grawert.net/hal-device-manager_0.4.7-1ubuntu1_all.deb
<ogra> pitti: dunno, if he likes....
<pitti> would be cool
<ogra> pitti: currently i'm struggling a bit wih th dmidecode idea... you know that it needs direct access to /dev/mem ?
<pitti> ogra: uh, read-only?
* ogra wonders if the same data isnt available elsewhere with ess restrichted rights...
<pitti> ogra: that would mean that you need the kmem group for hal
<ogra> pitti: nope, but it needs definately uid=0 or group kmem .... both not nice for hal
<ogra> pitti: is this secure ?
<pitti> ogra: could you create a separate kmem-sgid binary "hal-dmidecode-detect"
<pitti> ogra: and call this from hald?
<pitti> this would separate the privileges 
<ogra> yup
<pitti> and confine kmem rights to a minimum
<ogra> i'll try...
<pitti> running hald proper in kmem wouldn't be so nice
<ogra> gah,i made a mistake in uploading glibmm ....
<ogra> pitti: thats what i thought
<ogra> pitti: the patch code of this guy was sent from heaven, its a really nice code testbed :)
<pitti> ogra: so you indeed could use Richard Hughes' code
<pitti> ?
<ogra> pitti: thats what i'm talking about ;)
<elmo> pitti: ?
<pitti> elmo: mdz asked me to build the langpacks with bzip2 compression in the future
<pitti> elmo: however, that requires the hoary version of dpkg in the langpack dchroot
<pitti> elmo: is it possible to upgrade to this?
<elmo> see this kind of crack is exactly why the bzip2 compression thing is so ridiculous
<elmo> what would you do if we weren't using a chroot?  ask me to upgrade rookery to hoary?
* infinity raises his brow.
<infinity> Ubtuntu is moving to bzip2 debs without a skip-a-release policy?
<aj> but bzip2 barely ever makes any difference anyway?
<mjg59> jdub: Nope
<elmo> infinity: pre-depends on relevant version of dpkg
<elmo> and it's only being used where it does make a difference
<infinity> elmo : Ugly.
<elmo> and presumably pitti has figures to show it does for language packs
<elmo> pitti: (right?)
<elmo> infinity: *shrug* it fits more stuff on the CD - which is more of an issue for us than it is for Debian
<infinity> A deb pre-depending on a versioned dpkg is sick.
<infinity> <nod>.. Fair nuff.
<pitti> elmo: 
<pitti> -rw-r--r--  1 martin martin 2723900 2005-01-31 10:46 language-pack-de_20050128_all.deb
<pitti> -rw-r--r--  1 martin martin 3173814 2005-01-31 10:45 language-pack-de_20050128_all.deb.gzip
<elmo> btw, pre-depending on a versioned dpkg has plenty of precedent
<aj> that doesn't work though does it? dpkg --unpack dpkg.deb foo.deb # will satisfy the pre-dep, but use the old dpkg to unpack the foo.deb with the pre-deps
<infinity> I wonder if this "you can use -Z bzip2 if you predepend on dpkg >= foo" would fly in Debian as well.
<pitti> 2.7 MB vs. 3.1 MB
<elmo> infinity: it won't, you need the right dpkg on the katie machine too, which newraff doesn't have
<elmo> there's checks in katie to enforce the pre-dependency tho
<infinity> Check.
<elmo> aj: err, unpacked doesn't satisfy pre-deps?
<pitti> so it saves 15%
<aj> elmo: ?
<pitti> Morning seb128!
<elmo> aj: I thought definition of pre-depends was that it must be installed _and_ configured?
<aj> oh, i didn't think that applied to essential packages?
<seb128> hello!
<mvo_> hi seb128 
<dholbach> hi seb128
<ogra> morning seb128
<seb128> pitti: you DOSed my box with udev, bad guy
<seb128> pitti: I had to reboot :p
<pitti> seb128: hmm?
<aj> (note that apt never invokes dpkg like that anyway, so this isn't terribly important)
<pitti> seb128: I did not even touch udev recently
<mvo_> did the same to me at friday :)
<pitti> seb128: ah, did your cpu go to 100% on hal upgrade?
<infinity> aj : Won't your scenario just fork a new dpkg-deb for the second unpack anyway, thus using the newly installed binary?
<seb128> pitti: friday I updated hal and after that load ~9 and a ton of udev stuff moving in the ps list
<ogra> pitti: same here (only on amd64) ...
<pitti> seb128, ogra: we are reasonably convinced that his is a kernel bug
<seb128> pitti: and you were hidding from IRC :p (I should probably blame your ISP for this one :p)
<ogra> pitti: udev freaks out after the update (cant verify it on ppc or i386)
<pitti> it happens with older hal versions too, and it doesn't happen in Debian
<seb128> pitti: so that's fabbione's fault ? :)
<ogra> pitti: but they may be not up to date currently...
<elmo> aj: debootstrap does tho, I guess?
<pitti> seb128: yes, I was mostly offline friday morning :-(
<pitti> ogra, seb128: were any of you able to identify the culprit?
<aj> elmo: debootstrap assumes dpkg and other stuff is tar/gzip/ar'ed too
<pitti> ogra: this is an udev issue?
<elmo> aj: really?  neat
<aj> elmo: it has to unpack dpkg before dpkg is installed
<ogra> pitti: my log shows udev trying to create /dev/ramXX
<elmo> aj: ok, but it doesn't make that assumption in general?
<pitti> ogra: and it went mad on this one?
<infinity> But once dpkg is installed, it uses dpkg-deb for the rest, right?
<aj> elmo: it doesn't make any assumptions for stuff outside base, obviously
<ogra> pitti: it does it over and over
<elmo> if anyone suggests bzip-ing the data.tar of dpkg, I'll beat them senselesss
<aj> elmo: it makes that assumption for, hrm, essential/required; probably nothing else
<ogra> pitti: always the same devices....
<infinity> elmo : How about you bzip2 the data.tar of dpkg?
<seb128> pitti: http://rafb.net/paste/results/ofl3gX45.html
<infinity> pitti : How good do you feel about that php4-curl patch?
<seb128> pitti: this was moving a lot (ie: ps and ps again one second after and the totally different processes)
<ogra> elmo: can you give me a hint for glibmm2.4 ? why is the sig not accepted ? i rebuilt the source package...so it should carry my sig, or am i wrong ?
<aj> iU  dpkg           1.9.21         Package maintenance system for Debian
<aj> aj@labrador:~$ sudo dpkg --unpack /var/cache/apt/archives/vim_6.1.018-1_i386.deb 
<aj> Unpacking vim (from .../vim_6.1.018-1_i386.deb) ...
<aj> aj@labrador:~$ dpkg -s vim | grep Pre-Dep
<aj> Pre-Depends: dpkg (>= 1.6.8)
<elmo> ogra: glibmm2.4 is in main
<elmo> aj: score
<ogra> elmo: oh ?
<elmo>  glibmm2.4 |    2.4.5-1 |         hoary | source
<ogra> elmo: sorry...
<infinity> aj : Uhm.  1.9.21 is higher than 1.6.8, no? :)
<elmo> libglibmm-2.4-1                                   | glibmm2.4                       | inkscape                                        | Bradley Bell <btb@debian.org>                                             |          113746 |             376
<infinity> aj: Oh, I didn't notice dpkg was only unpacked.
<aj> yeah
<aj> it was previously configured at 1.9.21; but i don't think dpkg would've noticed that
<ogra> elmo: ok, so we need a more uploader for the fixed pakages then :)
<ogra> more potent...
* dholbach tries to drag  seb128 's attention to  ogra  and  elmo 's conversation. ;-)
<ogra> seb128: would you like to be able to use gtkmm again ? dholbach prepared packages ....
<pitti> seb128: hmm, thanks. I try to reproduce it.
<infinity> aj : Still, in your "dpkg --unpack dpkg.deb foo.deb" scenario, doesn't dpkg fork an instance of dpkg-deb for each of those successive unpacks, and therefor the second dpkg-deb forked would be from the new dpkg.deb?
<aj> oh, right
<pitti> infinity: which patch? the one which respects open_basedir restriction?
<infinity> pitti : Is there another one? :)
<elmo> does dpkg even order the unpacking tho?
<seb128> dholbach: hum, main, different issue ...
<elmo> or just respect the order on the command line
<pitti> infinity: well, I think I already explained in the BTS followup
<pitti> infinity: if upstream does not want to support it
<infinity> elmo : It's supposed to order complete operations for pre-deps, but I suppose only testing would confirm.
<aj> i think it does the cmd line ordering; but it'd error if you tried it the otherway, so no big deal
<pitti> infinity: then Debian and Ubuntu either should maintain it on their own
<pitti> infinity: or drop it
<seb128> dholbach: I'll have a look on the package 
<pitti> infinity: but if nobody else actually uses it, then I think we should rather say the truth
<infinity> pitti : I'm okay with maintaining it if you're more or less happy with the patch itself.
<pitti> infinity: and tell that the open_basedir restriction is mostly bogus
<dholbach> seb128: yes... unfortunately - i consulted configure.in and made sure the API wasnt broken - i tried inkscape/regexxer, which use it - but it 'd be great if some one else 'd have a look
<pitti> infinity: I'm fine with the patch, it works well for me
<aj> hrm, dpkg-deb is invoked, so it might be fine anyway
<dholbach> seb128: deb-src http://ubuntu.stufenseite.de/Repo ./
<pitti> infinity: it might have holes, but then again the whole open_basedir thingy has holes :-)
<seb128> dholbach: thanks
<infinity> pitti : open_basedir, basically, is guaranteed (modulo bugs) to work with zend and ext/standard.  Anything else is up in the air.  They have too many extensions to police.
<ogra> seb128: there is also a working coaster package ;)
<pitti> infinity: then I'd think, take it for now and drop it as soon as it causes trouble (new code and you have rejections, etc.)
<pitti> infinity: what would you do with it?
<infinity> pitti : On the other hand, patches have been recently submitted and accepted for fixing open_basedir issues in other extensions.  So it might just be the curl extension maintainer whose head is firmly up his ass.
* ogra thinks dholbach just becomes a really famous MOTU
* dholbach blushes crimson and stares at the floor. :-)
<infinity> pitti : I'll add it in the next Debian upload.  If I find a spare moment to argue with the 12-year-olds I call "upstream", I'll see about getting it where it belongs.
<pitti> infinity: no chance that the php4 core maintainers accept it?
<infinity> pitti : The core guys are some of the aforementioned 12 year olds...
<pitti> argh
<infinity> pitti : You want a good laugh, check out recent CVS and see how they'r ebreaking the build system right now.
<pitti> infinity: so half of the web application world depends and relies on a bunch of 12 years old who refuse to accept security patches?
<infinity> pitti : Bundling (an old, broken) libtool, making it harder to relibtoolize yourself if you don't like it, etc...
<elmo> pitti: are we sure this language pack stuff isn't going to break debootstrap?
* pitti becomes REALLY scared of PHP
<elmo> pitti: and this means you have to do another en-mass upload doesn't it? :/
<aj> what's the language pack stuff?
<pitti> elmo: I won't do another base upload just for that
<ogra> pitti: you weren't before ?
<pitti> ogra: not that much...
<ogra> heh
<pitti> elmo: _can_ it break debootstrap?
<pitti> elmo: i. e. is anything of it part of the base system?
<infinity> pitti : The latest addition to the team of 12 year olds seems to be an "if it compiles on my system, it ships" guy.  Several others have been cleaning up portability issues behind him.
<elmo> aj: http://www.ubuntulinux.org/wiki/LanguagePacks
<pitti> elmo: I really don't know about the internal workings of debootstrap
<aj> i think dpkg-deb does make dpkg safe anyway
<infinity> pitti : And here I am, trying to do a CVS snapshot release that isn't broken (because 4.3.10 /is/ broken)... Yay.
<pitti> elmo: but AFAICS debootstrap shouldn't install language packs, should it?
<pitti> infinity: I don't envy you...
<aj> it'd be odd to have a language pack in base/debootstrap afaics?
<elmo> aj: yeah, but as you say, it hardcodes the name of the data.tar.gz for 'required' packages - my concern is at least one language will become required
<infinity> pitti : It's okay.  I have enough self-pity this week, I probably don't need any from third parties. :)
<elmo> well I find it more odd that we'd strip _all_ translations from all packages, but maybe that's just me
<aj> it's easy to install a language pack after base (same time as grub)?
<pitti> elmo: what's odd about stripping the whole main section?
<aj> warty doesn't do language packs, right?
<elmo> aj: right
<pitti> aj: right, this is all Hoary stuff
<aj> gar, dpkg-reconfigure looks like it makes xserver-xorg work now
<pitti> elmo: if you don't have any pack, you will just get plain "C" translations, i. e. none
<pitti> elmo: that should usually result in English-ish
<pitti> elmo: but AFAIUI the installer apt-get's the langpack after installing the base system
<pitti> Kamion: ^ that right?
<infinity> "English-ish"... Heh.
<infinity> "Programmerlish"?
<pitti> infinity: well, British guys might find some odd "colors" and so on... :-)
<aj> doh, how do i make dpkg-reconfigure regenerate /etc/X11/xorg.conf?
<ogra> aj: read the md5sum hints in the head of the file ;)
<aj> ogra: hrm, too late; i already read /var/lib/dpkg/info/xserver-xorg.config :-/
<aj> yay, there we go
<elmo> pitti: meh, ok, done
<aj> arrg, it worked
<pitti> elmo: thanks
<daniels> aj: if you have 6.8.1-1ubuntu12, there's a boatload of debconf tweaks in there that should make lots of stuff work
<dholbach> brb
<aj> daniels: upgrading from warty/xserver-xfree86 to hoary/xserver-xorg gave me an xorg.conf that didn't have horizsync/vertref, and a log that said "no such mode 1024x768, ..." and reverted back to 800x600 and 640x480 defaults. adding the horizsync/vertref lines fixed it; but i can't duplicate the behaviour now that i've fixed it to give your proper logs/config :-/
<daniels> aj: heh, ah well
* daniels scampers for a bit.
<abelli> fabbione: ding
<elmo> doko: 
<elmo> doko: ?
<elmo> fabbione: ?
<thom> fabbione is still ill, i think
<elmo> ok
<thom> Mithrandir: you need to reply to the last post on u-devel
<dholbach> hi tseng
<tseng> hiya, dholbach 
<dholbach> i hope i'll win the lottery to have enough money to sue every lottery-lot-selling "$&)/"$"$& that calls me on the phone
<smurfix> dholbach: The real problem is to weasel any kind of contact info out of them. They *know* it's illegal.
<dholbach> smurfix: i resorted to telling them that i'm absolutely happy at the moment and don't need *anything* at all
<dholbach> smurfix: they give in fast that way :-)
<elmo> there's still no way to relocate X clients across hosts, right? [</madly wishful>] 
<mjg59> elmo: gtk has support for it
<Mithrandir> elmo: xmove, or nx.
<mjg59> But there's no authentication code written yet (AFAIK), so it's not widely supported
<rburton> there are gtk "issues" with it, and you need full acccess to both servers to make it work
<elmo> rburton: issues with which?  mjg59's comment or mithrandir's?
<elmo> 'cos xmove looks semi-perfect
<rburton> xmove is a hack :)
<rburton> gtk apps can seamlessly disconnect from one display and re-connect to another
<elmo> okay, so xchat's a gtk app.. how do I move it from my laptop to my desktop? :)
<rburton> but its a bit buggy, xlib doesn't like the old screen being disconnected
<rburton> elmo: you hack xchat to add a "move to other display" button. it's all a mess atm :(
<rburton> elmo: never fear, there is work to make it just happen if an atom is set on the window
<elmo> duh
<mjg59> xmove doesn't support most of the X extensions that clients are likely to use
<elmo> unless it's something old school like GNU Emacs, I guess
<elmo> hmm, I don't suppose my network connections would survive the switch of hosts, anyway, in xchat
<thom> gnu emacs supports migration anyway aiui
<rburton> yeah, emacs can create frames on other displays
<elmo> kind of
<thom> certainly it's an oft-quoted example
<elmo> I mostly brought up emacs as an example of a client that probably doesn't use new X extensions, unlike xchat or a web browser
<elmo> so, we know dircproxy isn't a good plan - are there any good IRC proxies?
<thom> elmo: just run irssi in screen?
<Mithrandir> elmo: ask what joeyh uses?  ISTR he uses an IRC proxy.
<elmo> thom: I really prefer xchat to irssi
<elmo> I suspect joey uses irssi or another text-base client too
<Mithrandir> I think he uses xchat.
<thom> elmo: http://www.garion.org/irssi/irssi-proxy.php
<Mithrandir> 04:57 -!- joeyh [joey@kitenet.net]  has quit ["Terminated with extreme prejudice - dircproxy 1.0.5"] 
<thom> use irssi as the proxy! ;-)
<Mithrandir> seems like he uses dircproxy.
<elmo> meh, if that as bad as keybuk says, he really should, like, warn people
<Mithrandir> what's so bad about it?
<elmo> thom: how cute - and disturbed.  do you use it?
<elmo> Mithrandir: he's upstream for it and abandoned it long ago, he reckons it's full of potential security holes
<Mithrandir> elmo: oh, ok
<thom> elmo: no, i just run irssi in screen
<elmo> hmm, irssi isn't too bad, except for the moronic package name, the fact that it's in universe and that it doesn't have the anti-pasto feature of xchat
<Treenaks> elmo: it does have an anti-paste feature
<Treenaks> elmo: it'll ask "You pasted X lines, do you really want this?"
<aj> elmo: irssi rox0rs, you lame gui-fed n00b
<elmo> giggle
<Mithrandir> we should probably move it into supported, IMHO.
<Mithrandir> it's the irc client if you don't do GUI IRC.
<elmo> do we have a hoary+1ProposedPackages yet?
<elmo> Treenaks: ok, cool.. even for one line?
<Treenaks> elmo: configurable
<Treenaks> elmo: so, yes
<Treenaks> (/set paste_verify_line_count 1)
<elmo> gar, having laptop/desktop keyboards with ~ and | reversed from each other is a receipe for (increased) insanity 
<infinity> My laptop's ~/` key is between [space]  and [alt]  on the right side.
<infinity> And the keycap is missing.
<Treenaks> infinity: yuk!
<infinity> I'm finally starting to get used to the missing keycap, after a year.
<smurfix> elmo: so swap them
<elmo> smurfix: yeah, I am, I'm trying to decide which I prefer
<Mithrandir> elmo: which is why a Norwegian keyboard layout is nice, since you then just lose the |, while the tilde stays in the same place.
<Treenaks> Mithrandir: losing the | is nice?
<elmo> boggle, what treenaks said
<daniels> elmo: 'swhat you get for having a US keyboard
<Mithrandir> Treenaks: no, not losing ~ is nice.  Half the lossage.
<daniels> s/Us/UK/
<elmo> my laptop has | next to return, which is nice for shell pipe-fests, and ~ next to z which is less nice when I (infrequently) use it
<Treenaks> I have 3 keyboards.. one with "\|" between ENTER and Backspace, one with "\|" right of the right shift(!), and one with it next to ENTER (but there, the ENTER button is wide at the top instead of at the bottom..)
<infinity> I may be an old skool IBMer, but I'm firmly of the opinion that ~/` belongs next to 1, and | above [enter] 
<infinity> Treenaks : I had one with it next to the right shift.  That was a Zenith server keyboard.  Nice keyboard, weird layout.
<smurfix> The Enter key is a desaster in itself. Just how many ways to shape the thing so that you hit something else instead are there??
<Treenaks> infinity: yeah, me too.. have that on my Logitech here as well
<thom> infinity: above enter? you're not one of those people who like vertically challenged enter keys, are you? :P
* smurfix has a small keysonic keyboard. The keys are a bit on the small side, but the Enter key is *huge*, and Control is on the far left where it belongs
<Treenaks> smurfix: I have one "-"-shaped one (like shift), one which is wider at the top, and one which is wider at the bottom
<smurfix> none of the "hit Fn instead" crap
<Treenaks> smurfix: ugh. laptops
<infinity> thom : Yeah, I prefer enter to be long, but short.
<infinity> thom : Blame IBM.
<infinity> thom : They broke me.
<smurfix> Treenaks: No, it's an USB keyboard
<infinity> thom : Compaq too.
<Treenaks> smurfix: USB keyboard with an Fn key?
<smurfix> Treenaks: Yeah, I don't understand what the KeySonic people smoked when they designed it either, the only key you actually *need* is for is numlock.
<Treenaks> smurfix: numlock is crack anyway
<elmo> thom: meh, this proxy stuff doesn't seem to work
<Treenaks> smurfix: (the LED is nice to show alternate group.. but that's another story :))
<thom> elmo: blame JD in #debian-uk
<daniels> infinity: Is there anything else?
* smurfix agrees with Treenaks 
<elmo> thom: his suggestion, or ?
<daniels> Treenaks: alternate group?  wassat?
<thom> elmo: he's maintainer
<smurfix> even though I don't do alternate groups.
<Treenaks> daniels: oh, I use numlock to switch between "US" and "US International" layouts :)
<Treenaks> daniels: US is nicer when coding, US Intl is nicer when writing long pieces of Dutch text :)
* thom hopes for some drive by figletting from elmo
<smurfix> daniels: Other, more sane, people use it to switch between ASCII and Crillic. For instance.
<smurfix> *g*
<smurfix> Cyrillic
<daniels> woah.
<infinity> Sane people type in Cyrillic?
<Mithrandir> thom: my response on -devel being scary enough?
<smurfix> infinity: If they're Russians, most probably.
<smurfix> OK, on the other hand, scratch that.
* smurfix notes that that was an example. ;-)
<rubenv> welcome to the none ascii world :)
<thom> Mithrandir: that's about what i was hoping for
<rubenv> try typing on a kedmanee thai keyboard, you'll hug your english for the rest of your life ;)
<Mithrandir> thom: it's certainly possible, I did it with vawad.  I broke something in the process, though; glibc doesn't compile right any more.
<thom> Mithrandir: suer
<thom> sure, even
<daniels> Mithrandir: what'd I miss?
<Mithrandir> daniels: ubuntu-devel.  Guy asking how to upgrade from i386 to amd64.
<daniels> heh
<ogra> hehe, just reading that one :)
<Mithrandir> this was actually the first time I've switched both distribution and arch at the same time, not just one of them.
* decko foi almoar
* dholbach doesn't understand. :-)
<zul> hilo
<toresbe> Does ubuntu have a packages.debian.org equivalent?
<toresbe> nm
* lamont_r idly wonders if fabbione and daniels are conspiring to tank his bandwidth
<zul> ooh...can i join lamont ;)
<Mithrandir> lamont_r: I think there was an X upload last night?
* lamont_r finds a wet noodle to whap zul with
<lamont_r> Mithrandir: _AND_ linux-source
<zul> heh
<Mithrandir> lamont_r: yeah, true.
<Treenaks> lamont_r: and seb with another load of GNOME
<lamont_r> mirror-missing| more
<lamont_r> # ubuntu 226
* thom searches for an excuse to do an OOo upload
* lamont_r is sitting at the coffee shop
<Mithrandir> thom: you could do an OOo-amd64 upload as there was a minor bump on the normal OOo a few days ago.
<Treenaks> thom: typo fix?
<Mithrandir> that's the single biggest package we have, I think.
<thom> i doubt lamont mirrors amd64 tho
<lamont_r> Mithrandir: I don't mirror *amd64*
<Mithrandir> sad :(
<lamont_r> and linux-source is good for a ~220 MB hit
<Treenaks> lamont_r: how about ia64?
<Mithrandir> thom: we should get lamont an amd64.
<lamont_r> yeah, i386 and ia64 and source
<Mithrandir> or we could make an ooo-ia64.
<lamont_r> Mithrandir: that'd be cool
<thom> really we should make OOo2 build
<lamont_r> Mithrandir: that'd be a seed change....
<thom> heh. so pwgen on freebsd builds with "-DDEBIAN"
<lamont_r> thom: heh
<Mithrandir> lamont_r: is ooo on the seed page limited to amd64, ppc and i386?
<lamont_r> yes
<Mithrandir> ook
<lamont_r> _and_ germinate/ubuntu-meta knows how to deal with arch-specific things now.
* lamont_r thanks Kamion agin
<lamont_r> again, even
* lamont_r needs to find a fatter pipe than the coffee shop...
<lamont_r> gonna have to find someone to get to know in the CS dept of the uni here.
<Treenaks> lamont_r: the coffee shop downstairs from here has some fat pipes..
<Treenaks> lamont_r: but I think it's not the kind of pipe you're looking for 8)
<lamont_r> feh
<Kamion> elmo: did you see my query about Task: ubuntu-desktop on ia64?
<lamont_r> actually, I'm seriously contemplating paying for DSL for the fire dept, so that I can work from there...
<lamont_r> (the remote terminal for the area is at the firestation... should make for good bandwidth... :-)
<elmo> Kamion: nope ?
<lamont_r> Kamion: me neither.. :)
<Kamion> elmo: openoffice.org still seems to have Task: ubuntu-desktop in binary-ia64/Packages.gz, despite being [amd64 i386 powerpc sparc]  in seeds/hoary/desktop
* lamont_r idly wonders if OO.o would build on hppa
* Mithrandir idly wonders if lamont_r could get him an ia64 for multiarch fun.
<lamont_r> Mithrandir: you really want one?
<Mithrandir> lamont_r: yes.
<elmo> Kamion: err, you know the task overrides are arch inspecific, right?
<Kamion> elmo: erm. can they not be?
<lamont_r> Mithrandir: I'll shake the bushes later today and see what falls out
<elmo> Kamion: not really
<Mithrandir> lamont_r: in a desktop/tower size, preferably, I don't have a rack yet.
<Mithrandir> lamont_r: thanks a lot. :)
<Kamion> that seems like a fairly major bug
<lamont_r> Mithrandir: most of what they've had lately have been towers, I'd have preferred a rackable one, but...
<elmo> well, either someone fixes apt, or I suppose I could run apt-ftparchive <n> times for <n> architectures
<Kamion> it'll bite whenever libraries have different sonames between arches or something
<Mithrandir> lamont_r: it's standard ATX or something, isn't it?  So it could be remounted in a rack case?
<Kamion> well, only if both old and new sonames are available I guess
<lamont_r> Mithrandir: really cute rounded corners - not so rackable
<Kamion> mdz: do you have any idea what's needed for architecture-specific task overrides in apt-ftparchive?
<Mithrandir> lamont_r: I thought about taking the mobo out of the box.
<lamont_r> Mithrandir: there's some serious cooling engineering there, as well as an 800W power supply... it _WANTS_ to stay in the case it shipped in....
<Mithrandir> lamont_r: ah, ok. :)
<lamont_r> including some neato foam pieces inside the chassis with dire warnings about how they're needed for normal operation, and must not be removed...
<Treenaks> lamont_r: sounds hackish
<lamont_r> Treenaks: nah - it's called channelled air cooling - the alternative was going liquid...
<Treenaks> lamont_r: or reduce CPU wattage
<lamont_r> when it first came out, itanium was the hottest chip on the market.
<lamont_r> kinda fast, too.
* Treenaks pets his fanless 1GHz Via C3
<Mithrandir> isn't the itanium still the hottest chip on the market?
<lamont_r> Mithrandir: could be
<Kamion> xfree86-driver-fglrx should be moved from restricted to multiverse, shouldn't it?
<Kamion> daniels apparently wants to keep on supporting it, but xserver-xfree86 is in universe
<elmo> umm, speaking of firegl, rene thinks fglrx-driver, fglrx-driver-dev are NBS
<elmo> daniels: ?
<thom> Kamion: hrm, current hoary installer doesn't find the usb keyboard on this powermac
<thom> NBS?
<Kamion> +  * Kill off fglrx-driver altogether, and have x{org,free86}-driver-fglrx
<Kamion> +    Conflicts/Replaces/Provides it; ditto fglrx-driver-dev (closes:
<Kamion> +    Ubuntu#5630).
<Kamion> thom: hm, suck
<elmo> oh, ok, looking at the changelog would actually make sense tho
<Kamion> thom: can you have a look at the PCI class id-handling stuff in usb-discover and see what's going on?
<thom> Kamion: how? no keyboard
<Kamion> thom: serial console?
<Kamion> tweaked initrd?
<thom> Kamion: this is a graphite g4
<thom> guess it's tweaked initrd
<thom> no serial port
<Kamion> you could do the evil open firmware telnetd trick; can't remember if it works that far into the installer
<thom> Kamion: got a reference for the telnetd trick?
<pitti> abelli: ping
<abelli> pitti: dong when you want
<pitti> abelli: I just uploaded new hardened kernels 
<pitti> abelli: using wireless drivers now works for me
<pitti> abelli: (on powerpc at least)
<ogra> pitti:  ./dmiwrapper /dev/mem: Permission denied
<ogra> # dmidecode 2.5
<thom> nm, found it
<ogra> sudo chmod g+s ./dmiwrapper
<pitti> abelli: now I test the i386/k7 images with framebuffer
<ogra>  ./dmiwrapper /dev/mem: Operation not permitted
<ogra> pitti: suid group seems not to work :(
<pitti> ogra: sudo chown root:kmem dmiwrapper
<ogra> i did :(
<pitti> ogra: sgid root could not work
<zul> pitti: whats new in the hardneded stuff?
<ogra> i know
<pitti> ogra: did you mount your /home with nosuid?
<pitti> ogra: (I did :-) )
<pitti> zul: I updated to our latest Ubuntu Hoary kernel, and also to the latest grsec
<zul> cool
<ogra> pitti: is this a default ?
<pitti> zul: now the wireless drivers seem to work, too
<pitti> ogra: not really
<abelli> ogra: mm.. dont think so..
<pitti> ogra: but paranoids like me always so nosuid,nodev :-)
<Kamion> thom: IIRC you type this at OF:
<ogra> pitti: i can run it with suid root, but not with suid group kmem
<Kamion> " enet:some-ip-address" io
<pitti> ogra: btb
<pitti> ogra: brb, even
<Kamion> thom: then telnet to some-ip-address
* pitti tests new kernel image now
<thom> Kamion: yeah, it drops out as soon as the cdrom boots though :(
<Kamion> mdz: shouldn't casper-reconfigure, er, actually chroot?
<Kamion> thom: hm, damn
<pitti> abelli: darn, vesafb is still broken
<thom> Kamion: want me to try last array cd and see if works there? that at least may give me a working machine (it's new and OS-less atm)
<Kamion> thom: yeah, please
<Kamion> thom: was this warty?
<pitti> abelli: other stuff works fine
<Kamion> oh, no, you said hoary
<abelli> pitti: can i try breaking it?
<abelli> :)
<pitti> abelli: sure, go ahead and beat me up :-)
<ogra> pitti: -rwxr-s--x  1 root kmem 20060 2005-01-31 16:31 dmiwrapper
<ogra> ./dmiwrapper /dev/mem: Operation not permitted
<Hwolf> guys: sorry to bother here, but I've just set up printing on my warty box as I did previously, same driver etc, and I'm getting very erratic printing. Half the time it works in OO.o, and I haven't been able to print from firefox.
<ogra> no way....
<pitti> ogra: hmm, odd
<pitti> ogra: ah
<ogra> pitti: only suid root works... :(
<pitti> ogra: wait, I think I know what's missing
* pitti verifies
<pitti> ogra: hmm, could be that you need CAP_SYS_ADMIN for that, too
<pitti> ogra: however, this capability is essentially root
<ogra> pitti: regard the error, without suid group i get "permission denied", not "Operation not permitted"
<pitti> right
<pitti> that means that you can open the device node
<pitti> but not read from it
<ogra> pitti: gah
<pitti> ogra: I think that's exactly the same as /proc/klog
<pitti> ogra: the kernel restricts access to these files to processes with CAP_SYS_ADMIN 
<ogra> pitti: so i'm doomed to use suid root ?
<pitti> ogra: I'm afraid so
<ogra> arghl
<pitti> ogra: hmm, you will write this in C?
<pitti> s/will write/have written/
<ogra> i already did....its just parsing the output fron dmidecode
<pitti> ah, you call dmidecode?
<ogra> yup
<pitti> then your own code does not need any privileges
<pitti> ogra: do it like this:
<ogra> you mean i shold set dmidecode suid root ?
<pitti> no
<pitti> - your program is suid root
<pitti> - immediately at start you fork()
<ogra> ok...
<pitti> - one process execv()'s dmidecode and opens a pipe to it
<ogra> is popen ok too ?
<pitti> - the other process drops all privileges: setgid(getgid()); setuid(getuid());
<pitti> - other process reads dmidecode output
* pitti never used popen() in C
<sivang> rehi all
<pitti> ogra: lemme have a look
<pitti> ogra: bah, no
<pitti> ogra: popen() is like system(), it invokes the shell
<ogra> oh, ok
<pitti> ogra: please rather not use it
<ogra> then execv
<pitti> ogra: use dup2() to redirect stdout
<pitti> ogra: try to close stdin and stderr (or redirect stderr, too, if you need to)
<ogra> ok, let me try.... you will have to review that anyway for security reasons ;)
<pitti> ogra: sure, I will :-)
<pitti> ogra: no, even better
<pitti> ogra: CAP_SYS_RAWIO is sufficient
<pitti> ogra: so you can drop everything but this cap
<pitti> ogra: but we can do this afterwards
<pitti> seb128: yay, gvfs hal is back?
<lamont_r> pitti: I thought popen only invoked a shell if there were shell meta characters in the command
<pitti> DESCRIPTION
<pitti>        The  popen()  function  opens a process by creating a pipe, forking, and invoking the shell.
<seb128> pitti: yeah, the lock is fixed and was not due to hal
<lamont_r> pitti: hrm.
<seb128> pitti: and since hal rocks :)
<pitti> lamont_r: ^ I did not check the code, just looked at the manpage
<lamont_r> ok
<lamont_r> ok
<pitti> lamont_r: if it doesn't use the shell, then it's probably fine
<_elmo> btw, is the udev SNAFUness known?
<pitti> _elmo: using 100% CPU after hal upgrade?
<_elmo> yeah
* pitti sighs
<_elmo> well, I dunno actually, I just upgraded for the fist time in several weeks and when I came back the next day hal and udev were sitting there beating the machine to death
<lamont_r> _elmo: you mean that's not just hoary/ia64?  cool
<pitti> _elmo: I encountered this too. but the odd thing was that no single process used up the cpu
<pitti> _elmo: all processes were quiet, but the cpu in general was 100%
<_elmo> pitti: I had something different then, when I found it, it was creating devices in a loop, again and again
<pitti> _elmo: /dev/ramXX ?
<smurfix> pitti: Hmmm... I see that too, something seems to be forking off small stuff like crazy.
* pitti tries to reproduce it
<ogra> pitti: if i reboot in this state, i get a message about a hanging process in the shutdown messages...
<_elmo> pitti: a whole bunch of different ones, scsi, loop I remember
<pitti> but after reboot everything works fine?
<ogra> yup
<pitti> (it did for me)
<ogra> pitti: btw.... was quite time consuming to test my hal patches yesterday ;)
<pitti> ogra: ?
<ogra> every test a reboot....
<pitti> ogra: you can reproduce it reliably?
<lamont_r> very bad to require a reboot...
<pitti> ogra: I can't
<lamont_r> pitti: does dpkg --reinstall do it?
<pitti> I was able to reproduce it once, but never again
<ogra> i can, everytime i install hal and dbus/hal restarts
<pitti> lamont_r: I currently do "sudo dpkg -i hal_0.4.7-1ubuntu1_i386.deb" over and over again
<seb128> is LIBTOOL_IS_A_FOOL still needed ?
<ogra> pitti: i have this only on amd64... my ppc and i386 work fine
<lamont_r> t-bone saw it on a fresh? install on ia64, iirc
<pitti> ogra: so what is the culprit exactly?
<Kamion> yeah, T-Bone can reproduce it every time on install I think
<pitti> lamont_r: --reinstall does not work (or, rather, does), too
* lamont_r hasn't seen the problem yet
<Kamion> 'bterm': unknown terminal type
<smurfix> pitti: udevd and udev (three instances) seem to be unkillable in that situation
<Kamion> any idea what program might be emitting that message
<Kamion> ?
<ogra> pitti: dunno, as i said, udev tries to create /dev/ramXX wildly and i get a message about a hanging process on reboot then... after reboot everything is fine
<ogra> pitti: i'm at the office currently, i can make more tests this evening...
<smurfix> the fact that it amnages to do that at all is somewhat remarkable, much less that it still forks off stuff :-/
<lamont_r> Kamion: make /usr/lib/terminfo/b/bterm a symlink to /etc/terminfo/b/bterm, and make that a named pipe....
<pitti> now I down- and upgraded over and over again, I cannot reproduce it
<lamont_r> Kamion: of course, that turns it from a nasty warning into a hang, but... :-)
<pitti> ogra: if you encounter this again, please try to stop hal before upgrading
<pitti> ogra: sudo /etc/dbus-1/event.d/20hal stop
<Kamion> lamont_r: :-P
<ogra> pitti: i will...i'll report back tonight
<pitti> ogra: might help; if it does, I change the init scripts for a quickfix
<ogra> yup
<lamont_r> Kamion: that's the longwinded way of saying 'NFC' :)
<pitti> lamont_r: can you reproduce the hal hang?
<smurfix> Why doesn't "kill" (the command, not the syscall) report an error if the PID 'm killing doesn't exist??
<lamont_r> pitti: haven't seen it yet
<pitti> hrm
* smurfix thinks that's a (somewhat nasty) bug
<pitti> I now down-, up- and sidegraded the complete set of hal debs several times...
<ogra> pitti: is your system upgraded from warty or a new hoary install ? (mine was an upgrade)
<pitti> ogra: I freshly installed about a week ago
<ogra> smurfix: and you ?
<pitti> ogra: however, my ppc is a warty upgrade
<pitti> ogra: and it works fine, too
<ogra> hm
<smurfix> Mine was a warty upgrade. Last reboot a week ago.
<pitti> Hi Keybuk! Nice to see you again!
<pitti> Keybuk: there is a pretty nasty dpkg bug (#184635) that we need to sort out soon
<ogra> pitti: as i said before, i cant confirm the bug on ppc
<Kamion> ah, it's 'clear'
<pitti> Keybuk: (asymmetric Replaces:)
<pitti> smurfix: and you can't reproduce it either?
<pitti> Keybuk: do you think this can be handled soon? it's critical for the langpack updates
<smurfix> pitti: I haven't rebooted yet. It's still happening (as soon as I kill -CONT udevd).
* smurfix can strace the beast if that helps
<pitti> smurfix: that'd be cool
<pitti> smurfix: so as soon as udevd runs, it creates devices over and over again?
<pitti> seb128: tried to reproduce the hal hang?
<pitti> smurfix: $ sudo ps aux|grep udev
<pitti> Password:
<pitti> root     27062  0.0  0.0   2808   648 ?        S<s  16:39   0:00 udevd
<pitti> smurfix: sleeps like a baby...
<smurfix> pitti: It forks off udev over and over again, whcih then proceeds to call various interesting scripts
<pitti> smurfix: so udevd forks off udev?
<pitti> hmm, I guess the hal upgrade is just the trigger for this bug
<ogra> looks like
<smurfix> pitti: send me a ssh key and I'll let you onto my system, that'd be easiest
<smurfix> What's a reasonable pasetebin? pastebin.ca is *slow*
<pitti> smurfix: http://www.piware.de/mpitt-ssh.pub
<seb128> pitti: no, get a disk access issue, had to reboot ...
<ogra> smurfix: #flood ?
<seb128> pitti: I'm pretty confident that the patch for the lock is correct
<smurfix> ogra: xchat doesn't do multi-line paste well
<seb128> Keybuk: is LIBTOOL_IS_A_FOOL still needed ?
<Keybuk> shouldn't be
<Keybuk> libtool 1.5 hasn't linked library deps in a while
<ogra> smurfix: ah, true 
<Keybuk> (at least the Debian libtool)
<seb128> k
<seb128> thanks
<smurfix> pitti: @kiste.smurf.noris.de. The interesting part (repeating strace output) is in /tmp/logsnippet.
<pitti> smurfix: read(3, 0xbffffc54, 4)                  = -1 EAGAIN (Resource temporarily unavailable)
<pitti> smurfix: ^^ that's because there are already too many children?
<pitti> smurfix: are there already lots of udev childs?
<smurfix> No, that's because fd3 is nonblocking and doesn't have data
<pitti> hmm, now we need to know what fd's 3 and 4 are...
<smurfix> pitti: it's a pipe
<smurfix> pitti: ls -l /proc/31924/fd
<pitti> smurfix: no permission :-)
<smurfix> one that udevd uses to send data to itself
<pitti> but I believe you :-)
<smurfix> pitti: use sudo
<sivang> pitti: back on the pkg
<pitti> smurfix: hm, your cpu is at 40%, but most processes are quiet...
<pitti> smurfix: is that still udev?
<pitti> smurfix: or did you stop it again?
<smurfix> pitti: check out "pstree -p | grep udev"
<pitti> smurfix: hmm, already did that. okay
<smurfix> pitti: it's forking off a new process every time through that loop
<smurfix> pitti: to it twice and look at the pids
<smurfix> that's a *lot* of processes, but they don't live long enough to register with top
<pitti> smurfix: hmm, gdb'ing the parent process does not yield anything useful
<pitti> smurfix: I think we need a debug-enabled udev for this
<pitti> smurfix: may I ...?
<smurfix> pitti: may you do what? Kill udevd? Not possible.
<pitti> smurfix: rebuild udev with debugging and install it
<pitti> smurfix: then you need to reboot and reproduce the situation again
<smurfix> pitti: ... assuming I manage to do that. *Somehow*. Given that it's my work system.
<pitti> smurfix: hmm, as you like. I don't want to disturb you
<smurfix> pitti: Give me a debug package anyway
<smurfix> pitti: My laptop hasn't been updated yet
<smurfix> pitti: Maybe installing a debug udevd first, then rebooting, then updating will exhibit the problem
* pitti bets that udevd will run fine with a debug version
<smurfix> pitti: No argument here, but we need to try anyway
<smurfix> Anyway, how does udevd manage to block SIGKILL?
<Keybuk> whoah, when did we hit #1 on DW?
* smurfix thought that wasn't supposed to be possible
<smurfix> Keybuk: What's DW?
<thom> distrowatch
<smurfix> ah
<pitti> smurfix: so far the only unkillable process that I encountered was a hald in kernel sleep (state 'D')
<pitti> smurfix: but that isn't the case...
<smurfix> pitti: Oh, I've seen plenty of USB jobs in "R", looping *somewhere*
<smurfix> pitti: but never in user space like udevd is doing :-/
<pitti> smurfix: debug version ready
<pitti> smurfix: in ~pitti/udev_0.050-3ubuntu3.1_i386.deb
<smurfix> pitti: OK
<lamont_r> pitti: not -3ubuntu3debug1?
* lamont_r ducks
<ogra> hehe
<pitti> smurfix: hmm, I can perfectly kill every single udev/udevd...
<pitti> smurfix: but I don't want to mess further with your system
<smurfix> pitti: You can't kill the one with pid 31924
<smurfix> ah, sorry
<smurfix> my fault
<lamont_r> pitti: while killall udev udevd ; do true; done doesn't count. :-P
<smurfix> damn kill(1) which doesn't report that the process died
* smurfix needs to fix that ASAP
<pitti> I did not yet try "killall -9 udevd" :-)
<lamont_r> smurfix: you mean waits for it to die?  or bitches that it's already dead?
* lamont_r wouldn't like the former, wouldn't mind the later
<lamont_r> hrm.. already bitches
<smurfix> lamont: The latter doesn't happen, which is a major no-no. "kill $RANDOM_PID" must complain if there is no such process.
<bradb> Kamion: hey dude. What was the use case again that we discussed in Mataro for filing bugs on source packages? ISTR it was when one doesn't know the binary package.
<lamont_r> bradb: or when the source fails to build
<lamont_r> smurfix: kill 59000
<lamont_r> bash: kill: (59000) - No such process
<lamont_r> with current procps
<smurfix> lamont: Try /bin/kill
<smurfix> lamont: you're using the shell builtin
<lamont_r> smurfix: yeah - that's bad
<bradb> lamont_r: how would you (want to) specify "file against the binary package foo" vs. "file against the source package foo"?
<abelli> pitti: ding
<pitti> dong
<abelli> pitti: acpi now doesnt work
<pitti> that's a lie, it works for me :-)
<pitti> no, really
<lamont_r> bradb: good question - today, we don't. :-(
<pitti> abelli: what exactly? booting?
<pitti> abelli: or power management?
<smurfix> pitti: The problem persists
<abelli> pitti: no.. its just 
<abelli> pitti: no.. its just fatal error: Could open /proc/acpi/toshiba/keys.
<abelli> Please make sure that your kernel has enabled the Toshiba option in the ACPI section.
<lamont_r> bradb: I'm not sure that I really need to be able to distinguish necessarily - it'd be nice.
<smurfix> pitti: You may attack udevd with gdb mow
<abelli> its just the toshiba extension
<smurfix> now, even
<pitti> abelli: do you try this as non-root?
<lamont_r> bradb: but there are packages who's source name is diff from all the binary package names....  I should still be able to file against the source package there.
<abelli> it just dont works..
<abelli> doesnt work and say you need to run it as root
<smurfix> pitti: I don't think udevd is the culprit, though
<pitti> abelli: the hardened kernel restricts the access to /proc
<pitti> smurfix: I still think it's a kernel bug
<abelli> pitti: it worked
<lamont_r> bradb: that is, I don't care about the namespace collision from the union - I just want to have the ability to file against the source package.
<lamont_r> likewise, the maintainer needs to be able to query for bugs against all of the binaries (and source) that build from "this" source
<Kamion> bradb: I think lamont's superseded anything I might say :)
<abelli> pitti: another thing is that it hangs as i try to umount an external hdd
<pitti> abelli: <abelli> pitti: it worked  <- does that mean it works now?
<abelli> no, it used to work
<abelli> :)
<lamont_r> Kamion: sorry to take the words from your mouth, and all that
<pitti> smurfix: I have a nice backtrace now
<Kamion> lamont_r: no worries :-)
<bradb> lamont_r, Kamion: ok cool, thanks for the insight
* Kamion is buried far too deeply in debconf to be able to think about anything else right now
<abelli> pitti: btw, ipw2100 seems to be unusable as well
<pitti> abelli: bah. is the module loaded?
<abelli> yes
<pitti> abelli: with the old kernel module loading did not work for me, now it does
<pitti> hrm
<pitti> smurfix: can you try to reproduce the madness?
<Hwolf> Guys; If I set up a printer, and it works from OOO, but not from FF, is that a bug? 
<pitti> smurfix: I restarted udev in debugging mode, but right now it behaves 
<smurfix> pitti: I'll have to boot the box (damn USB printer driver).
<pitti> smurfix: please wait a bit
<pitti> smurfix: I forgot to set the DEBUG compiler flag
<smurfix> pitti: *grumble*
<lamont_r> hrm.. time to go move the car... bbiam
<lamont_r> fabbione: here?
<ogra> lamont_r: you want fabbione to move your car ?
<dholbach> Kamion: about LIBTOOL_IS_A_FOOL again: i have a library whose auto-foo provides Makefiles with -rpath -arguments to the linker included, which makes lintian whine about binary-or-shlib-defines-rpath - what do you reckon, i should do?
<mdz> morning
<ogra> morning
<mdz> Kamion: no, casper-reconfigure is used after pivot_root
<pitti> Hi mdz!
<smurfix> mdz: evening ;-)
<mdz> Kamion: arch-specific task overrides, no
<lamont_r> ogra: heh
* lamont_r is in the car
<lamont_r> brb
<lupus_> fabbione, ping
<smurfix> pitti: done?
<pitti> not yet
<pitti> please gimme a minute for final testing
<smurfix> pitti: my daughter wants her pictures printed ;-)
<pitti> smurfix: okay, ready
<pitti> smurfix: I need to restart udevd anyway
<pitti> smurfix: to start it in the foreground
<pitti> but I'd like to do that before you reinstall hal to trigger the bug
<pitti> smurfix:  then I can watch the output messages
<smurfix> pitti: OK, I've reinstalled udev.deb. Rebooting now. brb
<abelli> pitti: i cant find any kind of error apart those in query
<[m0rph] > hi
<[m0rph] > some new gnome packages in hoary don't use my locale
<Kamion> mdz: casper-reconfigure> oh, I see
<Kamion> dholbach: I think you mean Keybuk
<Kamion> mdz: tasks> hmm, is it liable to be really hard or a moment's work?
<Kamion> hm, ok, I basically asked that already, sorry
<Keybuk> dholbach: make the Makefiles not include the -rpath arguments
<mdz> Kamion: I recall that the last time I worked with that code, the API needed to be reworked to support more interesting stuff
<mdz> it had some annoying limitations which made life difficult if you wanted to have more than one type of matching
<Kamion> elmo_: is calling apt-ftparchive once per architecture totally not an option?
<mdz> there's a work in progress to add wildcard matching support
<dholbach> Kamion: oh yes... sorry
<dholbach> keybuk: about LIBTOOL_IS_A_FOOL again: i have a library whose auto-foo provides Makefiles with -rpath -arguments to the linker included, which makes lintian whine about binary-or-shlib-defines-rpath - what do you reckon, i should do?
<elmo_> Kamion: no, it's an option I guess
<Keybuk> dholbach: make the Makefiles not include the -rpath arguments
<dholbach> Keybuk: i guess it's because examples are compiled with those libraries which are not-installed yet
<Kamion> mdz: debconf passthrough frontend fix just uploaded which may affect you; not sure
<Keybuk> right, when you install, libtool will relink the libraries without the rpath
<mdz> Kamion: debian or ubuntu?
<Kamion> mdz: checked into debconf upstream, uploaded to Ubuntu
<dholbach> Keybuk: ok... thank you - i'll try to investigate
<pitti> smurfix: I'm now watching the log
<pitti> smurfix: can you try to reproduce the situation?
<smurfix> The question is how
<ogra> smurfix: reinstall hal
<smurfix> ogra: OK
<smurfix> pitti: you see the problem? :-/
<mdz> Kamion: what is an invisible question?
<pitti> smurfix: not at all, the syslog is quiet
<pitti> smurfix: bah, it does not log anything ! 
* pitti cries
<smurfix> Well, it definitely occurs. :-/  Just look at pstree. Or the load.
<ogra> pitti: daemon.log/kern.log ?
<mdz> pitti,smurfix: are you looking at the udev madness?
<smurfix> ogra: you wish
<ogra> pitti: i definately sa output, cant remember which log though
<pitti> ogra, smurfix: all other logs are in syslog
<pitti> ogra, smurfix: and in daemon.log as well
<pitti> mdz: yes
<smurfix> mdz: pitti is
<mdz> I have some logs
<pitti> mdz: we already do for nearly an hour
<smurfix> mdz: it seems to be perfectly reproducible on my system
<pitti> mdz: I installed a debugging version on smurfix' machine
<pitti> mdz: and gdb'ed it there
<mdz> I had to disable the hotplug helper and reinstate it in order to get the system to calm down
<pitti> mdz: but from the first sight it doesn't seem to do anything unusual
<smurfix> mdz: not a good long-term solution
<pitti> mdz: maybe it gets flooded with hotplug events
<mdz> I'll send you my syslog, in case it helps
<pitti> thanks, yes
<pitti> smurfix: hrm, now /dev/log is missing and udev won't start again. grumpf
<pitti> smurfix: I just installed new binaries...
<Kamion> mdz: one that is not shown due to e.g. priority being too low
<pitti> smurfix: init.d/udev stop/start doesn't help either
<mdz> Kamion: ah
<smurfix> pitti: restarted syslogd
<smurfix> pitti: so it's back now
<Kamion> mdz: basically you can end up with boolean questions not having a "true"/"false" value as a result; there's an X bug which I'm wondering if it might be related to this
<mdz> Kamion: if I understand correctly, I'm surprised that didn't break anything
<mdz> (noticeable)
<pitti> smurfix: odd, it still exits
<pitti> smurfix: this time for another reason (but the strace doesn't reveal it...)
<pitti> smurfix: possible to reboot?
<smurfix> pitti: why?
<pitti> smurfix: well, if you can manage to run udev again?
<pitti> hmm, I can start it manually
<smurfix> pitti: it even logs what's broken
<pitti> okay, let's try the hal update again
<smurfix> Jan 31 18:42:34 udevd[10502] : main: bind failed, exit
<Kamion> mdz: I think it only causes values in config.dat to be out of spec after a particular instance of the passthrough frontend exits, so unless you were reconfiguring something twice you might not notice
<pitti> smurfix: that was my erroneous attempt to start it as user :-)
<mdz> ah, ok
<Kamion> unless you were paying close attention to errors in syslog
<pitti> smurfix: now it _should_ run again
<mdz> Kamion: syslog is dead by the time casper does its reconfiguring :-)
<smurfix> pitti: running sudo dpkg -i /var/cache/apt/archives/hal_0.4.7-1ubuntu1_i386.deb
<Kamion> heh
<pitti> smurfix: ah
<Kamion> "errors? what are those? LA LA LA LA"
<pitti> smurfix: try sudo tail -f /var/log/syslog
<mdz> Kamion: speaking of syslog
<pitti> smurfix: now you get a nice flood
<smurfix> pitti: ouch
<mdz> Kamion: I think I'd like to save the d-i logs in casper
<pitti> smurfix: I rather stop the process before the log fills up your disk
<mdz> Kamion: which bit does that?
<Kamion> mdz: prebaseconfig.d/93save-install-log
<smurfix> pitti: it already did
<pitti> smurfix: Jan 31 18:44:32 kiste syslogd: /var/log/daemon.log: No space left on device
<pitti> smurfix: sorry...
<Kamion> I've been meaning to do s/debian-installer/installer/ on that
<pitti> smurfix: 27 MB
<mdz> Kamion: I'd also been wanting to have it gzip them; mind if I make those changes?
<pitti> smurfix: hmm, I was thrown out
<mdz> the gzipping is especially significant under casper
<pitti> smurfix: can you please safe (part of) the log somewhere?
<smurfix> pitti: the fact that everything's logged three times doesn't exactly help
<smurfix> pitti: /var/log/syslog's still there
<pitti> smurfix: actually I wanted to check which events are coming to udev
<Kamion> mdz: that's fine for /var/log/*, but please don't gzip the cdebconf stuff; doing that will break base-config
<mdz> hmm
<mdz> maybe I should just give casper a separate script, then
<pitti> smurfix: I just can't ssh any more (I was just thrown out)
<Kamion> mdz: that might make better sense
<Kamion> I could have sworn there was an upstream bug about compressing logs
<pitti> smurfix: another idea, just for testing:
<Kamion> mdz: You didn't want prebaseconfig in casper anyway, IIRC ...
<pitti> smurfix: right before reinstalling hal, could you do "sudo /etc/dbus-1/event.d/20hal stop"?
<mdz> true
<mdz> Kamion: is the db_x_save still necessary if I skip the debconf/priority hack?
<Kamion> mdz: yes
<smurfix> pitti: /dev/pts got unmounted
<Kamion> mdz: at least I think so. cdebconf only saves the database between menu entries, by default.
<smurfix> pitti: you can now get back
<mdz> I don't think that's in debconf's confmodule
<Kamion> no
<smurfix> pitti: do it yourself ;-)
<pitti> okay
<Kamion> you could echo it and read the result ...
<mdz> or add the functionality to debconf...
<Kamion> I'd prefer not, it's a very cdebconf-specific extension that relies on knowledge of how d-i works
<mdz> echoing it seems like major XXX material
<mdz> and I've been trying to reduce the XXX count in casper, not increase it :-/
<Kamion> I don't think echoing it is a big deal; the debconf protocol is plain-text and well-documented for a reason
<mdz> I'm down to 3 :-)
<mdz> ok
<mdz> to fd 1 or fd 3?
<Kamion> it's not very nice, but it's tolerable
<Kamion> fd 1
<Kamion> er, assuming that was your debconf communication fd, which it is by default
<mdz> echo "X_SAVE"
<mdz> read resultcode resulttext
<mdz> something like that?
<Kamion> yeah
<Kamion> if it goes into debconf, one could probably argue that it shouldn't be X_ any more :-)
<Kamion> post-sarge we all need to sit down and go over the debconf/cdebconf extensions and get the sane ones into the standard
<Kamion> mdz: is there nowhere that you could use the cdebconf confmodule to do it?
<mdz> Kamion: . /initrd/usr/share/debconf/confmodule
<Hwolf> Is anyone here knowledgable about Postscript / Cups?
<pitti> Hwolf: what's up?
<mdz> hmm, ick
<mdz> multiple dpkg-reconfigures means multiple db saves
<mdz> I guess I should revert that split
<pitti> smurfix: hmm, I restored your original udev for now and purged the logs
<Hwolf> pitti: I've got a fresh warty install here, set up my printer, same box, same drivers. Works fine from OO.org, but printing from firefox/thunderbird/postscript viewer results in anything but prints. Cups going down or errors, or nothing at all, mostly.
<mdz> though, hopefully that's only config.dat
<smurfix> Hwolf: That kind of question is best asked in #ubuntu
<mdz> if it's saving templates.dat, that's costing a lot of memory
<Kamion> it should only save if there's a change
<Hwolf> smurfix: I've tried for half a day, and on the forums too. :-S
<pitti> Hwolf: please file a bug and append /var/log/cups/error.log
<Kamion> should> "I think that's the current behaviour" rather than "it ought to be this way", IYSWIM
<pitti> Hwolf: or send the cups log and a description to ubuntu-devel@lists.ubuntu.com
<Hwolf> smurfix: Just trying to narrow down if it is my config this time, since I've had warty working with this printer / box before
<mdz> Kamion: how awful is my fontconfig hack in your opinion?
<mdz> there will be other cases like that, and we ought to have a standard way of doing it
<pitti> smurfix: but /etc/init.d/udev restart won't start udevd, though
<pitti> smurfix: I used a foreground instance, but to really repair it you need to reboot (or find out what's wrong)
<mdz> I should skip the defoma part, too
<mdz> maybe it should be a debconf template in fontconfig?
<mdz> which I could preseed?
<Kamion> why is it regenerating in the first place, rather than checking if it's up to date and if so exiting?
<Kamion> came from #173949 apparently
<mdz> dunno
<mdz> even if it did, it would probably be quite slow
<mdz> presumably it needs non-trivial information from the fonts
<smurfix> pitti: it didn't restart from init.d because the udev database was still there. That's non-fatal though, udevsend will start udevd on its own when necessary. Anyway hotplugging still works.
<Kamion> I guess if the cache format can change between versions of fontconfig, it needs to regenerate, or something
<pitti> smurfix: okay, fine
<smurfix> pitti: you done on my box?
<Kamion> mdz: mm, so what are we doing at the moment for stuff that needs that information?
<pitti> smurfix: I copied the log to my servr
<pitti> smurfix: right now I don't know what to do further
<mdz> Kamion: in this case, we know that the cache is in fact up-to-date, and we only want to effect the changes to the config file
<Kamion> oh, the livefs build process updates the cache?
<mdz> yes, as part of the process of installing fontconfig
<mdz> the only reason we reconfigure it is to enable subpixel rendering on laptops
<Kamion> mdz: how about making fontconfig.postinst not regenerate the cache if DEBCONF_RECONFIGURE=1?
<mdz> Kamion: I thought it was naughty to pay attention to DEBCONF_RECONFIGURE
<Kamion> would that break other things? I assume *some* config file changes can require the cache to be rebuilt
<mdz> my understanding is that the cache only corresponds to the fonts on the system
<mdz> and not the config file
<Kamion> well, it is a bit, but no worse than adding any other environment variable to the postinst API I think
<mdz> hm, the man page claims that it checks timestamps and does incremental updates
<Kamion> I think it's better than FONTCONFIG_NO_CACHE_REGEN, assuming that nobody ever needs the cache rebuilt automatically on reconfigure
<mdz> I wonder why it's so horrifically slow
<Kamion> not when called with -f it doesn't
<mdz> I can't say that with authority, but it's the impression I got from jdub
<mdz> oh, so it is
<Kamion>        -f           --force
<Kamion>                  Force  re-generation  of  apparently up-to-date cache
<Kamion>                  files, overriding the timestamp checking.
<Kamion> how about only using -f if [ "$DEBCONF_RECONFIGURE" != 1 ] ?
<Kamion> if you're reconfiguring, you want the cache to be rebuilt if it's totally fucked (e.g. missing), but not otherwise, I'd've thought
<pitti> mdz: hm, you have the same logs as I got on smurfix' machine
<Kamion> and if you really need that you can still run fc-cache -f by hand
<mdz> yes, I think the postinst ought to only do what should be necessary for configuring the package
<mdz> haven't looke dat that bug you mentioned
<mdz> need to run to my appointment, back in a while
<Kamion> mdz: it basically just says "please import this stuff from RH"
<elmo_> hmm, if C-5 is ^[, what's a good way of getting a list of other keys?
<mdz> if you see jdub or someone else who seems to know about fontconfig, maybe we can get an authoritative answer
<smurfix> mdz, Kamion: any feedback on today's mail from me?
<Kamion> smurfix: I'll try to get to it tomorrow for you
<smurfix> Kamion: That'd be helpful.
<Kamion> sorry, deep in my own features today :(
<smurfix> Kamion: I noticed.
<Kamion> smurfix: hm, what exactly were the "unknown localized field" errors you got?
<Kamion> because I don't think you should be getting those
<smurfix> Kamion: might have been caused by the fact that the cdebconf.conf in src/ isn't exactly useable for anything
* decko vai pra casa!
<smurfix> Kamion: .. which is why my patch creates a new one in src/test/
<Kamion> smurfix: uh ... I'd rather not have one of those in the source package
<Kamion> smurfix: doc/testing.txt explicitly documents that you have to tune it depending on what you're testing, and I often munge src/test/cdebconf.conf a lot
<Kamion> dunno
<Kamion> it's usable at the moment if you're making cdebconf talk to your real debconf database, which is an ultimate goal for cdebconf to be able to do reliably
<smurfix> Kamion: Hmm, I'd rather have the one in src/test not touch anythoing outside that directory by default
<smurfix> Kamion: and run out of the box otherwise so that you have a working baseline without havign to understand cdebconf's deep magic any more than you need to *anyway*. ;-)
<smurfix> Kamion: those "unknown localized field" errors might be a case in point. Haven't reproduced them yet. :-/
<Kamion> smurfix: that's true of src/test/ certainly. dunno, it's just a matter of how much stuff I have to be careful not to accidentally commit when I'm testing in an svn working copy
<smurfix> Kamion: so test the have-to-be-careful-about stuff somewhere else. ;-)
<Kamion> no, I'd rather not make my working habits deliberately inconvenient for myself :)
<Kamion> I'll think about it, maybe there's some reasonable compromise
* rubenv kicks evo in the groin
<rubenv> just managed to fuck & delete my calendar >:[
<rubenv> (note:  it managed to do that, i am just innocent user :-( )
<rcaskey_> my nightly rsync saves my butt weekly
<rubenv> my last backup was a month ago
<rubenv> when I was still near university
<rubenv> gah i'm mad
* rubenv out
<doko> elmo: pong
<elmo> doko: doesn't matter
* Kamion gets down to zero questions in the second stage
<elmo> sweet
<Kamion> should keep Mark happy ;)
<elmo> Mark'll be happy when you make the code telepathic so it just pulls the answer directly from your mind :p
<Treenaks> elmo: the DWIM interface!
<Kamion> reassign xxxxxx python-telepathy
<kent> have some one had problems with Ubuntu (hoary 2.6.10) and usb devices?  this weekend when i tried to get a webcam nx to work (playing with a driver from CVS..) my computer crashed twice. I dont blame ubuntu since i guessed it was the cvs driver. But now when i connected a olympuc c-310 digital camera via usb it mounted automaticly as a usb-drive (but i dont see it in Computer though), but if i take out the usb-plug, then the computer c
<kent> rashed.
<kent> Im not sure though if i am to blame my computer or the kernel. (it has problem with heat. If i leave it on to long and use it to much, it can crash.) But using the usb seems like it should not trigger a heat-effect :)
<lamont_r> Kamion: no ppc livecd today?
<mirak> why are you doing xord updates without updating the drivers ATI ?
<Kamion> lamont_r: http://adare.buildd/%7Ebuildd/livecd/livecd-current.cloop:
<Kamion> 08:04:36 ERROR 404: Not Found.
<fabbione> hey guys
* fabbione is almost back to life
<fabbione> Kamion: did -13 work?
* dholbach welcomes fabbione back
<Kamion> mirak: it got updated recently ... try xorg-driver-fglrx?
<Kamion> fabbione: haven't tried yet, will probably try tomorrow
<Kamion> thanks for the upload
<fabbione> Kamion: cool! it has only the ia32 fix...
<Kamion> ok, hope it's the right one :)
<fabbione> no problem.. i wasn't really sure how long i was going to take to recover
<lamont_r> Kamion: hrmpf.
<fabbione> so when i saw it, i just did upload
<fabbione> Kamion:
<fabbione> #   [PATCH]  x86_64: fix crash on get_user_pages of ia32 vsyscall page before it's faulted in
<fabbione> #   
<fabbione> #   God invented symbolic names to help you.  Repeating magic constants by hand
<fabbione> #   is begging to lose, especially when you get them wrong.  Don't be a loser.
<fabbione> #   
<fabbione> #   [ Editor's hint: 0xfffe000 vs 0xffffe000 ] 
<fabbione> that was in the upstream changelog
<fabbione> :P
<lamont_r> fabbione: lol
<mirak> Kamion: it doesn't appear in my list, vut maybe they don't need to be updated after all
<Kamion> ok, I'll give it a shot :)
<fabbione> Kamion: thanks
<lifeless> Kamion: no more info needed I think, just no progress either :[
<Kamion> mirak: it's definitely in the archive, in the restricted component
<Kamion> lifeless: ok
<lifeless> Kamion: does it happen on every changeset, or just some [how reproducible is it] 
<Kamion> lifeless: it happened on all three I committed after upgrading to baz 1.1
<Kamion> I haven't checked the ones since then
<lifeless> ok, thanks.
<Kamion> (that was just up to the bug report)
<Kamion> let's see ...
<lifeless> so the sequence is 1) commit to remote archive, 2) mirror from remote archive to other remote archive.
<lamont_r> Kamion: symlink fixed.  will investigate what happened.
<lamont_r> fabbione: thoughts on 6035?
<Kamion> lifeless: right, mirroring from the same host so that .arch-cache is used; .arch-params/hook specifically
<lifeless> ok, so your hook calls baz archive-mirror ?
<Kamion> lifeless: yep
<lifeless> thanks
<Kamion> with a limit of the package-version
<lifeless> yah
<fabbione> lamont_r: bad ram? does it happen on all kernels? a corrupted filesystem?
<lamont_r> fabbione: exactly.  I'll go ahead and follow up with the bug
<fabbione> lamont_r: thanks.. i will check tomorrow as well. he is from .dk so perhaps i can just poop by his house :)
<lamont_r> fabbione: thanks
<lamont_r> you're much closer than I.
<fabbione> no shit! :)
<Kamion> lifeless: yeah, it's happened to every revision in cdimage--mainline--0 since patch-108, which was the first after I upgraded
<lifeless> Kamion: thank you 
<Kamion> if it helps though, I've only tried on powerpc
<lifeless> I don't *think* we've got any punish-64-bit user code left.
<Kamion> powerpc is 32-bit, but big-endian
<lifeless> that so sucks, get a 801e or whatever it is.
<mdz> smurfix: yes, haven't looked at the code yet, but I will
<schweeb|work> quick question... got an XFS bug/issue, the bug is already reported to SGI, not sure if you guys would want a bugreport or not too...
<tseng> schweeb|work: probably report a bug to ubuntu if you get a fix from sgi/linux-bk
<schweeb|work> well, the bugs I've found at SGI that are similar are unclaimed, and have been since like may
<tseng> =/
<schweeb|work> indeed
<tseng> if you do file a bug with ubuntu, be sure to link to those
<tseng> not sure how much it will help either party, however
<mako> ok.. someone want to help me identify a language and then translate out of it? :)
<dholbach> mako: give an example
<lamont_r> mako: you're asking, so I'll assume that japanese it isn't... :(
<mako> cuo sam da se  moze naruciti vas prizvod pa  ako nije problem moze te li poslat UBUNTU LINUX
<mako> something about getting ubuntu
<mako> i suspect its slavic
* dholbach can spot a "problem"
<dholbach> hungarian or something
<lamont_r> yugoslavian, I bet
<sivang> romania?
<[Clint] > not hungarian
<mako> that's basically the whole message
<tseng> google the oddest word says
<[Clint] > definitely looks slavic
<tseng> Balkan Media Club first hit
<marcin_ant> dholbach: absolutely not hungarian
<marcin_ant> dholbach: and besides - hungarian != slavic
<sivang> bulgerian?
<lamont_r> google on 'cuo sam da se' gives a bunch of .yu sites.
<mako> i'm actually more interesting in knowing what it says
<mako> interested even
<dholbach> marcin_ant, [Clint] : sorry - didn't say i was an expert :-)
<marcin_ant> dholbach: ;)
<dholbach> there's no #ubuntu-yu yet... hmmm
<Josephus> it's not hungarian :)
<[Clint] > mako: stalk joy
<marcin_ant> dholbach: hungarian is propably the most strange language in the world ;)
<marcin_ant> dholbach: a little example "hatlyba lp Fszekrakprogram segtsgvel llami garancival knnyebben juthatnak lakshoz" :)
<dholbach> marcin_ant: that looks nice to me :-)
<Josephus> it's one of the hardest
<jbailey> mdz: For using busybox, is updating the package version to 1.0 an option, or should I use busybox-cvs?  Busybox 1.0 looks to have been released in October.
<lamont_r> mako: sorry
<sivang> marcin_ant: with ishtanem being the strangest to me as "god"
<Josephus> it's "my god" actually
<Josephus> isten (isthan) is "god"
<sivang> Josephus: ah well, it's been a while since I Last heared hungerian :)
<sivang> Josephus: and "em" means mine?
<Josephus> yes
<sivang> Josephus: always sounded to me like mixture of some langs..
<marcin_ant> I got a question
<ajmitch> mako: for signing CoC text, just copy & paste off the webpage?
<marcin_ant> today is website contest deadline
<mako> ajmitch: that's fine
<lamont_r> mako: was that .yu email to info@?
<marcin_ant> could you tell me in which timezone jdub is?
<lamont_r> marcin_ant: .au somewhere
<marcin_ant> I'm not sure if I can send submission or not now
<lamont_r> like +7 or something
<marcin_ant> lamont_r: australia...
<lamont_r> yeah - +11 actually
<lamont_r> it's 0916 feb 1 for him
<mako> lamont_r: yes
<lamont_r> figures
<marcin_ant> lamont_r: whoo thanks :)
<mako> well, i get *plenty* of non-english mail to mako@canonical.com
<mako> a couple a day
<marcin_ant> lamont_r: then I have some time to finish my job
<sivang> mako: do you get hebrew ones? ;-)
<mako> usually i can either make out the point or do machine translation to get enough of a point to repsond
<mako> sivang: not yet
<mako> i'm sure it's only a matter of time
<sivang> mako: hehe, well, if you do, you know my address :)
<ajmitch> mako: sent
<Josephus> mako: i got translated that serbian line if you're interested :)
<mako> ok.. i might not get to it today
<ajmitch> I'm guessing that I first need the CC approval before I can be on the TB agenda for the next meeting?
<mako> i'm not exagerating when i say i've been writing email for 6 hours *straight* right now
<mako> ajmitch: it's up to them
<ajmitch> alright
<mako> ajmitch: but they could give you conditional approval upon membership being signed off by the cc next week
<ajmitch> that could be useful
<mako> i need to take a break and have tea or something..
<gsuveg> re
<lamont_r> mdz: you beat me to 6035 - thanks
<mdz> Kamion: still here?
<mdz> jbailey: busybox-cvs is what we use in the installer
<mdz> jbailey: so it's where most of the Debian and Ubuntu development seems to happen
<mdz> jbailey: confirm with Kamion, but I think busybox-cvs, yes
<mdz> Kamion: speaking of which, still here?
<jbailey> mdz: 'k, thanks.
<thully> when does mjg59 log on here?  I wanted to ask him about the progress of suspend in hoary.
<jbailey> mdz: It'll pretty much have to be.  The busybox package doesn't support 2.6 at all.
<jbailey> The non-cvs one, that is.
<jbailey> bbiam
<mdz> mvo__: here?
<mdz> mvo__: where is gnome-software-properties intended to be visible in the desktop?
<dholbach> mdz: it's launched by update-manager's "properties" button
<mdz> shouldn't it have a menu entry of its own?
<mdz> it affects much more than update-manager
<dholbach> mdz: i'm not sure if there are other visible ways... (desktop->system->update-manager is what i see too)  (i'm using german translation, so the wording may be incorrect)
* lamont_r gets ready to go fetch kids
<lamont_r> back on in a bit
<mako> Josephus: yes, go eahd
<Josephus> "I heard that i can order ubuntu linux from you. Would you send me one if it's not a problem?"
<Josephus> or something similar
<mdz> Kamion: is there an install iso available with the new base-config-before-reboot stuff, or should I wait for the next daily before doing a round of install tests?
#ubuntu-devel 2005-02-12
<sabdfl> whoot! how much is now pre-reboot?
<sabdfl> Kamion, mdz: ^?
<mdz> sabdfl: everything
<mdz> well, all the questions
<sabdfl> fantastic
<sabdfl> i think that's a big win and worth the effort
<sabdfl> thanks guys
<mdz> sabdfl: http://lists.ubuntu.com/archives/hoary-changes/2005-January/002077.html
<sabdfl> that will have a big impact on perceived install time, i think
<mdz> we still have the possibility of one question being asked by xserver-xorg if it can't probe the monitor
<sabdfl> that's fair enough
<mdz> though it should be possible to move that, too, if we want to
<sabdfl> does live-cd ask the same questions, if it has to?
<mdz> yes, if it has to
<mdz> so the infrastructure is already there for the installer to do it pre-reboot as well
<mdz> though it would require some X packaging work to get it set up that way
<mdz> and unpacking the X server before reboot
<sabdfl> i'm happy to keep the x questions post-reboot if needed
<sabdfl> because i think the live cd / install interaction is now such that we will get lots more feedback on the x guess-o-magic
<sabdfl> and quickly get those routines near perfect
<mdz> we've been getting lots of good feedback of that type
<sabdfl> super
<mdz> over 2000 live CD downloads from bittorrent alone
<mdz> powerpc especially got a lot of attention
* jdub cries for his firewall
<HrdwrBoB> dejah vu
<daniels> elmo: !
<elmo> daniels: ?
<daniels> elmo: you pinged?
<elmo> oh, doesn't matter kamion told me the answer
<daniels> phat
<elmo> does anyone knwo who runs apt-get.org ?
<YokoZar> mdz: ping
<YokoZar> ogra: pong
<ogra> YokoZar: pong ?
<YokoZar> heh.  Anyway let's talk abotu MOTUness
<HrdwrBoB> hey ogra, sup
* ogra sees HAL all around him
<ogra> http://www.grawert.net/hal_cpuinfo.png
<pitti> ogra: looks good :-)
<pitti> ogra: what does dmidecode do?
<sjoerd> ogra: and where in the spec are those fields defined :p
<jdub> ogra: heh, rad
* dholbach finally sees coaster around him - and no vision anymore. ;-))
<ogra> pitti: nothing in the ui yet, but i think i git a solution with the rights...
<thully> I wondered how suspend support in hoary is looking - any fix for pressing the "hibernate" button on thinkpads forthcoming?
<thully> mjg59: ping
<ogra> pitti: -rws--x---  1 root hal 19795 2005-01-31 23:16 hal-dmiwrapper
<ogra> pitti: would this be possible ?
<sjoerd> ogra: that's the way it's planned to do stuff for hal 0.6 afaik
<pitti> ogra: looks good
<ogra> yay
<pitti> ogra: well, 4751 would even match the Policy :-)
<pitti> ogra: i.e. -rws-r-x-r--
<thully> does anyone know if new Ubuntu theme(s) are planned?  Human is - well - a bit basic
<azeem> what's wrong with Human?
<tseng> thully: see ubuntuartwork on the wiki
<tseng> or gnome-look.org even
<pitti> Hi stub!
<ogra> sjoerd: th shot is 0.4.7 on hoary ;) basic dmi data is ready to go in tomorrow 
<pitti> hmm, what a short visit...
<thully> it's a bit basic - just has no color to it - kind of gives me that "solaris w/CDE" feel
<pitti> Hi stub!
<sjoerd> ogra: please get those fields in the spec, so they will be the same in 0.6 too :)
<pitti> stub: care to stay a little longer now? :-)
<sjoerd> ogra: dmi data should be very interesting.. nice
<stub> :-P
<pitti> stub: FYI, I currently work on PostgreSQL 8.0 packages
<pitti> stub: do you guys want 8.0 in the near future?
<stub> pitti: Will these be in base, Multiverse or Universe for Hoary?
<pitti> stub: I'm not sure whether they will be in hoary at all
<pitti> stub: I hope to upload them to experimental soon
<pitti> stub: but it's still a lot of work
<pitti> stub: since I do a completely new architecture
<pitti> stub: If you guys need/want it, I can probably accelerate the pace a bit and put it into universe at least
<stub> pitti: I think we will want to move to them as soon as we feel safe with it (wait to see if the early adopters get burnt), but also need it in the current stable distro. I wasn't expecting on moving to the 8.x series until 5.10
<elmo> stub: the options are supported or universe, not base or multiverse
<stub> So no need to go fast on our account. Mark and me will probably want to play though when it is available :-)
<pitti> stub: okay. By the Bendy release it should be well and up :-)
<pitti> stub: for playing with it, experimental packages should be enough, right?
<stub> pitti: As long as someone tells me what repository to add, I'm fine.
* stub isn't really a dumb user, but he plays one on this IRC channel.
<stub> pitti: Provided it coexists with 7.4.x - that might be an issue?
<pitti> stub: for Sarge+1 I thought about providing an upgrade path to the multi-version architecture
<pitti> stub: i. e. a mostly empty postgresql package which depends on postgresql7.4
<pitti> stub: however, without the dummy package, both versions should coexist quite happily
<stub> pitti: So you have them listening on different ports?
<pitti> stub: since I now manage arbitrarily many clusters/versions in parallel, I do that anyway :-)
<stub> pitti: cool :-)
<pitti> stub: if you want to play with it and comment on it, feel free to check out the arch head
<pitti> stub: however, I will do some first public packages anyway
<dholbach> good night everyone - i'm off to bed 
<pitti> hmm, good idea; already way after midnight...
<pitti> Night everybody!
<ogra> hi Alessio
<ajmitch> hey ogra  :)
<ogra> hi :)
<mdz> elmo: isn't that christoph haas?
<mdz> oh, no, that's mentors.debian.net
<tseng> hi dilinger, any word on as3?
<tseng> :D
<dilinger> yea, it's all ready, i just need to compile and test it
<Alessio> hi
<dilinger> (which will happen after i get home)
<mdz> haggai: awake?
<jdub> should i do this in a <ul> format?
<jdub> http://www.gnome.org/~jdub/blog/projects/ubuntu/1107219478
<jdub> might be easier for mako to copy
<mdz> jdub: what was the outcome of your gnome-bt look-see yesterday?
<jba> hi guys, I'm trying to find more information about ubuntu laptop support and this url (http://www.ubuntulinux.org/community/teams/laptop/view) said that the laptop guys hang in here?
<mdz> jba: that's right
<jba> cool, I don't suppose there is a whole wiki section devoted to laptop items ? or even a laptop blog?
<mdz> jba: mjg59 heads the laptop team
<mdz> there are a number of laptop-related pages in the wiki
<mjg59> jba: Not currently, but it's a good idea
<mdz> but I don't think there's a central overview
<jba> yeah but they seem disparate, and some seem contradictory
<mdz> yeah, there ought to be
<mdz> jba: this is symptomatic of wikis ;-)
<jba> yeah i know, I got excited when i saw there was a laptop team
<mdz> if you have the gumption, feel free to straighten out any wrongness in the wiki, and organize things better
<jba> thought it mean that you guys where already mega organised, but obviously, in that respect, you guys are getting there.
<jba> besides it's probably better to devote resources to hacking right now
<mdz> we coordinate here, on the ubuntu-devel mailing list, in the wiki, and in bugzilla
<jba> mdz,  the main thing confsing me now is the thing about custom dsdt files being in 2.6.9 kernel, but apparently not in 1.6.10
<jba> i mean 2.6.10
<jba> and I can't seem to find a reason for this
<mjg59> jba: 2.6.10 has support for dsdt files in the initrd
<mdz> Ubuntu 2.6.10 does, but not upstream, right?
<mjg59> Correct
<jba> it does? some people in the mailing list claim it doesn't
<jba> mjg59, cool thanks dude
<mdz> maybe they are not using Ubuntu kernels
<mjg59> jba: On ubuntu-users?
<jba> mjg59, i think so, to be honest i googled it yesterday and can't recall
<jba> but if it's there, then good
<jba> that means all i need to do is dissassemble my dsdt table fix the memory setting, recompile and add it to initrd, correct ?
<mjg59> jba: Correct
<mjg59> We'll have support in initrd-tools to do this automatically before release
<jba> cool, really wasn't looking forward to compiling a kernel though
<jba> mjg59, when is "before the release" ?
<jba> roughly
<mjg59> jba: When either mdz or I write it :)
<mjg59> It won't take long, but I'm a bit busy with real-life stuff at the moment
<jba> hehe, I didn't mean it like that dude, just trying to get a feel for when
<mdz> mjg59: actually, jbailey is the ideal person to do that now
<mjg59> mdz: Oh, good point
<mjg59> I'll hassle him about it
<jba> mjg59, i can imagine dude.
<mdz> mjg59: isn't there a bug open already?
<mdz> ah, I already gave it to him
<jba> as i understand it, the automatic initrd image adding only happens at ubuntu kernel installation time?
<mdz> mdz: good thinking
<jba> jdub, by the way dude, did you get that link i was talking about yesterday (the nautilus share extension)?
<mjg59> jba: Yes, or whenever someone runs mkinitrd
<jba> cool
<robertj> is hoary still accepting new packages?
<jba> did you guys want me to write up my experiences with adding a custom dsdt with 2.6.10 kernels ?
<jba> or has someone already done that?
<mdz> robertj: in universe, yes
<mjg59> jba: If you could write a wiki page on custom DSDTs, that would be great
<jba> btw props on includding pptp client 1.5.0 in this ubuntu version
<jba> mjg59, i'll give it a shot, but I'm not registered on the wiki yet
<robertj> mdz: will wesnoth get updated auotomatically from sid?
<mdz> robertj: no, only if requested
<jba> oh and, My baby is due to be born any day, so I may not get the chance to finish it too soon (which is why i asked when the automatic stuff would be released)
<robertj> is there a form anywhere ;)
<mjg59> jba: Only takes a minute :)
<mdz> daniels: rock, your new xorg fixes the gl crash on my laptop. good work
<jba> mjg59, to write it up yes, to do it and get it working, well that takes a while for me
<jba> i'm using a dell lattitude x300
<mdz> robertj: no, that particular process is lacking in documentation
<robertj> mdz: mail the devel list?
<mjg59> jba: jdub has identical hardware
<mdz> robertj: basically, we need to know the source package name, the version you want, and why
<jba> mjg59, no shit ?
<mdz> robertj: to ubuntu-devel, yes
<mjg59> And working suspend/resume now that he's fixed his dsdt
<robertj> oky
<mdz> robertj: for main, the 'why' should generally be to fix bugs, but we're a bit more flexible with universe
<jba> mjg59, i don't care about suspend/resume, I'm more interest in knowing when to plug power in
<mjg59> Haha
<mjg59> Yeah, that works too
<jba> jdub, do you mind if we exchange war wounds with the x300 and ubuntu ?
<jba> mjg59, serious though, that's all I really want from dsdt
<jba> my machine has turned off on me in the middle of a crucial mono hack 3 times already cause i forget the power
<jba> now i just don't cycle the battery, use power all the time
<jba> i might try jdub's blog for more info, but I don't remember seeing anything about it in planet.gnome.org
<robertj> mdz: coming at ya
<robertj> err if evolution is happy ;)
<jba> does jdub work for canonical or just volunteer?
<Mithrandir> jba: he's a canonical employee.
<Mithrandir> jba: he's the release manager. :)
<jba> wow cool
<jba> he is in the .au too isn't he?
<tseng> yeah, he sleeps all day while i am awake
<tseng> pretty wild, eh?
<jba> that must mean he has working wifi and alsa sound on his machine too
<Mithrandir> jba: not sure, he has a dell. ;)
<Mithrandir> unlike the rest of us, who have nice and groovy x40s.
* tseng has a dell, it works
<tseng> jba: do you have the irq conflict issue?
<jba> Mithrandir, that was my point, we have the same machine
<jba> tseng, used to work, before i updated on sunday
<jba> used to work, but always boot with volume at 0
<jba> now doesm't work at all
<tseng> again, irq conflict?
<jba> tseng, let me check that
<tseng> read dmesg
<robertj> is the nvdriver s3 problem a known issue?
<tseng> possible around where ipw2x00 is loaded
<sladen> mjg59: http://lists.gnu.org/archive/html/bug-grub/2001-06/msg00141.html  It looks like grub might already have the necessary support to pass it multiple initrd's
<jba> faq need to find a power cable
<mjg59> sladen: Did that get included?
<jba> tseng, one second booting haory now
<mjg59> It probably doesn't add the correct magic to demarcate the initrd, though
<sladen> mjg59: so might be able to do   initrd={real initrd},  initrd={DSDT HEADER},  initrd={replacement dsdt}
<jba> tseng, which dell do you ahve?
<tseng> jba: 600m
<jba> aah
<mjg59> Ah, I see what you mean
<mjg59> That would be kind of neat
<jba> tseng, what's something to grep dmesg with quickly?
<tseng> jba: ipw .. if you have an intel wifi card
<tseng> the driver complains if it cant get the irq
<sladen> poor update-grub would probably choke
<mjg59> update-grub can be dealt with
<jba> no ipw in dmesg
<jba> apperntly acpi is not finding the dsdt at all too
<robertj> sladen: your the usplash guru right?
<sladen> robertj: legend has it
<robertj> sladen: Any news on that?
* mjg59 finally switches his desktop over to a stock kernel
<sladen> robertj: I'm counting down the days to the feature freeze 
<robertj> sladen: so you can slip in naughty bootsplashes meer seconds before the freeze ;)
<sladen> robertj: I hope not mere seconds, I'd like at least a few days of testing first
<jba> tseng, this would be facilitate a little more by knowing what I'm looking for
* tseng has little problem skimming dmesg, but i guess its an aquired taste
<jba> hehe] 
<tseng> ill give you the bug # your issue is similar to
<robertj> sladen: something giving you more trouble than expected?
<sladen> robertj: hopefully more than the 15minutes-before-the-31st-January-deadline I allowed for the Tax return this evening
<jba> that would be most helpful thanks
<sladen> robertj: yes, the bit I'm worried about involves x86 computers.  They are unique in that they come up in something called a 'text console', rather than a framebuffer.  To change to a framebuffer mode, you need to figure that out and set it in the bootloader.  Now what happens if you set a mode the attached monitor can't handle?
<tseng> jba: have a look at https://bugzilla.ubuntu.com/show_bug.cgi?id=1254
<robertj> sladen: they buy a new monitor?
<robertj> (very rarely)
<tseng> jba: it sounds related based on the very limited info youve given so far. (sound + wifi no worky)
<sladen> robertj: X falls back to a text-console to allow you to fix things if it fails;  ...but now you've just made their bootloader unuseable
<sladen> anyone know 'Dave Cinege' ?
<jba> tseng, thanks for your help dude, I'll take anything I can get, since I didn't even come in here for that :)
<robertj> sladen: so the rub is you force the fb from the start things can be unusable
<sladen> robertj: I ignore the problem presently, since it is a big headache
<sladen> robertj: hence hacking up a semi-equivalent text-based version of the graphics so that it can at least display /something/
<robertj> sladen: text-based?
<jba> lspci says my lappy is using a braodcom wireless
<tseng> oh, nasty
<robertj> sladen: how much of the substrate is missing to actually probe the monitor?
<jba> yeah, I don't really care about it either, just want my sound back
<tseng> jdub: the key is the parport, not the wifi card on this bug
<tseng> er, jba 
<jba> i don't see irq 7 being assigned anywhere in dmesg
<sladen> oh, not /that/ bug
<sladen> jba: is it a Dell?
<jba> sladen, yeah dude
<jba> guys, by the way. I appreciate your help but if you're busy with other stuff I understand
<jba> I didn't really come here to fix this but would love to get the inside word :)
<sladen> jba: the bug number is 1254, have you tried the things on there?
<jba> besides I don't think the x300 comes with a parport
<sladen> jba: interesting
<jba> sladen, yeah going down the notes now, but I don't think it applies
<jba> got sound back, by unloading and relaoding the alsa drivers
<mdz> sladen: late night?
<jba> anyway guys, thanks for your help so far, I'll try and get that dsdt stuff done and documented in the wiki
<tseng> gl jba
<jba> jdub, if you ever get a chance, I'd love to have a chat with you about how you have your x300 set up
<robertj> sladen: so is usplash86 going to differ from usplash for the otherarchs?
<sladen> robertj: no, the actual code is identical.  The unique problem on x86/amd64 is going to be setting grub to pass vga=XXX on the kernel commandline based on what VESA modes where reported as being the closest match to what xresprobe/ddcprobe has found the monitor capable
<sladen> mdz: the first of many this week I suspect :)
<sladen> robertj: I've done nothing in that respect since it's currently easier to say  ''append vga=791 if you'd like pretty 1024x768 goo''
<robertj> sladen: do mac's not have that problem if you don't use video=ofonly?
<sladen> robertj: usplash just wants a framebuffer;  doesn't really care how it got there
<Riddell> is the wiki broken?  I can't log in
<robertj> was just curious ;)
<robertj> is the usplash artwork finalized?
<sladen> robertj: nope.  I'm build-depending on ubuntu-artwork and pulling in the GNOME background/splash/throbber and whoever is doing the artwork can deal with that
<tritium> sladen, so I take it you didn't care for my grub splash image that I emailed you?
<sladen> tritium: grub splash is a different thing.
<tritium> sladen, I realize that
<tritium> you has asked me to submit the image to you, though
<wasabi> heh: available updates: test
<sladen> tritium: if you read back a bit, you'll see why I'm scared of /automatically/ doing anything graphical at the grub level---eg. you toast their monitor, they can't even select the 'recovery' option and skip it.  However, that doesn't mean I've ignored it or haven't added it to the collection
<tritium> I joined too late to see that.
<wasabi> How's apple do it?
<tritium> okay, glad to hear it.  I just wasn't sure, since I hadn't heard back from you.
<sladen> tritium: it's here in fact: http://www.paul.sladen.org/ubuntu/usplash/ideas/tritium/ubuntu-splash-5-colour.xpm
<tritium> :)
<tritium> thanks, sladen
<sladen> wasabi: Apple is not a problem.  OF makes use of all the things like sensing pins and brings it up in the correct mode that fully fills the screen
<wasabi> ahh.
<wasabi> what about MS?
<wasabi> they just do low res don't they though
<robertj> wasabi: they changed at some point
<robertj> like sp1 maybe
<robertj> now on some machines its centered in the middle of the display
<tritium> sladen, zenwhen's idea is similar to my second idea (rotating ubuntu logo)
<sladen> I think it may even be the 640x400x16 mode until they can probe anything more
<wasabi> heh.
<robertj> I really like the idea of the rotating ubuntu log
<tritium> cool!
<wasabi> yeah that sounds slick.
<robertj> sladen: I've noticed recently that some fix the resolution properly from the start (usually 1024x768)
<tritium> I'm glad you agree :)
<robertj> My machine doesn't do it but the ones I have installed from at the Office that are standard Dimensions + Ultrascan Flat panels do
<tritium> sometimes there's something to be said for simplicity
<wasabi> I've been thinking about this update-manager thing.
<robertj> tritium: like the Apple?
<wasabi> I love the way it looks... but I wonder if showing stuff like "debconf" as an updateable is worth showing users.
<tritium> robertj, I meant the rotating ubuntu logo is simple, yet appealing
<robertj> yeah
<wasabi> Wonder if there could be some logical grouping to roll up many packages into one big group... like "System Components"... for everything that's built in.
<sladen> robertj: interesting.  Some 'what' fix the resolution?
<wasabi> and then "PostgreSQL Database Server" for postgres, and all it's component packages, etc etc.
<robertj> sladen: certain machines
<robertj> running XP
<robertj> maybe it trusts the bios to doko DDC probing?
<robertj> %s/ko//
<sladen> robertj: tell me more.  At what point is it flicking to the native panel resolution (not just the panel stretching)
<robertj> sladen: bios, blackscreen, then the moving blue bar
<robertj> and at the bar its good
<sladen> hmm
<robertj> but it still does the flicker when you laod into the GUI
<mdz> wasabi: there is certainly more that could be done to simplify the interface
<robertj> sladen: is it possible to get the monitor's serial number without too much fuss?
<wasabi> I'm sitting here trying to think through how one would accomplish something like that. There isn't much of a grouping at all in apt of relating packages.
<mdz> wasabi: but given that the only real option was previously synaptic, it's come a long way already :-)
<robertj> maybe it just stores the default res in the bootloader
<wasabi> yeah, it's amazing.
<wasabi> I'll give you that. I think it's a great app.
<wasabi> I use it instead of synaptic now heh
<mdz> we had discussed one way to group things
<mdz> along the same lines as gnome-app-install
<wasabi> desktop files?
<mdz> applications would be represented as first-class things, and other packages as "system software" etc.
<robertj> gnome-update-manager is another option to synaptic in the same way a can-opener is another option to using an axe
<wasabi> hahaha
<robertj> users could really care less
<robertj> securing your computer .... with a countdown timer would make them happy
<tritium> Speaking of security, I'm performing the "Sandia Secure Unix/Linux Operating System Certification Tests" to get ubuntu officially approved for use within Sandia National Labs
<robertj> sladen: ok, simple theory to explain the correct proportions on the new monitors
<robertj> the new monitors are all digital flat panels so it probably just automatically sized down the stuff to keep it from looking horrible
<mdz> tritium: what sort of tests are involved? anything meaningful?
<robertj> and windows is probably none the wizer
<robertj> sladen: more reaosnable sounding?
<tritium> mdz, they're pretty simple, actually.  Discretionary access controls and auditing, basically.
<robertj> sladen: and the initial bootsplash is 320x400
<tritium> mdz, the test plan was written in 1999, and is going to be revised soon.  I assume it'll get more rigorous.
<jdub> jba: there?
<tritium> So I'm working with another person to get the testing done soon.
<jba> jdub, yep
<jba> back from lunch
<sladen> tritium: wow.  groovy.  Excellent in fact!
<mdz> jdub: what was the outcome of your gnome-bt look-see yesterday?
<jba> actually had lunch at my desk
<jdub> jba: everything in the X300 works, but you need to load a custom DSDT, and i haven't tried the modem
<tritium> sladen, I think so too :)
<jdub> mdz: didn't get a chance, doing it today
<jba> jdub, you're wireless works "off the bat"
<jba> and I figured about the dsdt
* jdub sucks down the package
<jdub> jba: ipw2200 in mine, works fine
<jba> faq
<jba> we don't actually have identical hardware then
<jba> cool jdub, thanks for he assistance dude, much appreciated
<jdub> despite being a dell, and the DSDT issue, i can happily recommend the X300. lovely little box.
<jba> yeah, cept the Fn F8 has issues
<jdub> the only other option was an ipw2100, wasn't it?
<jba> doesn't even work properly in windows
<jba> jdub, i don't know, I didn't buy this machine, was bought by network adming
<tritium> You'd laugh at the simplicity of some of the tests.  (e.g., 6.1: Verify that UIDs are associated with all processes on the machine)
<jba> i think mine has a broadcom in it
<sladen> robertj: 320x400 sounds familier.  When does it stop being 'initial bootsplash' and start becoming the 1024... one
<robertj> sladen: i was thinking it was scaling it down but now that I think about it it's probably just the monitor
<jdub> jba: lspci?
<robertj> :(
<jba> jdub, did yo install the ubuntu i855crt or i80?switch from universe ?
<jba> jdub 1 sec booting again
<jdub> jba: if they did get the broadcom, tell them they're nutters :)
<robertj> sladen: thus no secret magic :(
<jdub> jba: i use i855crt
<tritium> jdub, but Waugh...uh...what is it good for?
<jba> it doesn't put that crap band accross the top on return from crt?
<jdub> hrm, no
<jba> jdub, it was never their intention to get a linux machine. my lappy is a windows machine that I dual booted
<jdub> haven't tried for a while, but the worst problem with it atm is lack of mouse cursor
<jba> for mono hacking
<jba> Fn F2 turns on wifi and blue tooth correct ?
<tseng> yep
<jdub> jba: roughly
<jba> roughly?
<jba> do i need to press it twice or something ?
<jdub> well, it seems to work and not work depending on the state of acpi and whether it's raining in cleveland
<jba> hey also, how come ubuntu install cd dosn't have a rescue mode
<jba> jdub, someone posted a way to fix that too, but it needs a kernel recompile
* jba hates kernel recompiles
<jba> broadcom bcm4036 wireless
<mjg59> You lose
<jba> hehe
* jdub has committed to no kernel compiles on any ubuntu system he runs :)
<mjg59> More seriously - we have someone working on Broadcom support, but it may not happen for Hoary
<jba> double faqers
<jba> don't need wireless yet anyhow
<jba> just want acpi
<jba> and bluetooth would be nice
<mjg59> You can get wireless with ndiswrapper
<mjg59> bluetooth should just work, really
<jba> mjg59, will test when i get my bluetooth phone
<jdub> bluetooth just works
<jba> i might go ndiswraper then
<jba> i really don't want to do a kernel recompile
<jba> and no one uses an sd card reader
<mjg59> If you need to do a kernel recompile, that means we've messed up
<mjg59> There's no support for SD readers yet, unless they're USB-connected
<sladen> or PCMCIA connected
<jba> i'm a happy camper
<marcin_> jdub: hi! Is website contest finished (I'm not sure in which time zone you are)?
<mdz> I don't think compiling the kernel helps for bc4036
<mdz> note that you don't need to recompile to get ndiswrapper; it's already there
<jba> will have working wireless, bluetooth and battery indicator by the end of this week (fingers crossed)
<sladen> mdz: thanks
<jba> jdub, where you guys standing on shipping mono?
<jdub> jba: possibly for the next release
<jdub> it's all in universe at the moment, and lots of apps are nicely up to date
<jba> 1.1.4 is about to be pushed out in the coming days
<jba> that will be the version to push out
<jdub> we haven't upgraded beyond 1.0 yet
<jdub> it's tempting, but there have been lots of build problems, etc.
<jdub> if you, or another mono dude, could update the packages and be sure that they work, that'd really help
<jdub> the worst part is the bootstrapping problem
<jdub> lamont and thom can probably help out with that
<jdub> tseng: i can't get to your site
<tseng> jdub: hm?
* tseng looks
<ajmitch> jdub: build problems were mostly fixed with 1.0.5
<ajmitch> which has just gone into sid
<jba> jdub, i've never packaged linux (let alone deb) software before, but I'd love to help
<tseng> jdub: the admin just ping timeout on irc, not a good sign
<tseng> jdub: i can upload elsewhere
<jba> I'm just cautious of taking on more than i can swallow in the coming months (baby and all)
<lamont> jba: 1.1.4 will need to actually be able to build 1.1.4 before it gets into the archive.
<lamont> unlike 1.0.4, which can't build itself (must be built using 1.0.2)
<ajmitch> lamont: 1.0.5 can build 1.0.5 - it was a problem with havnig .net 2.0 stuff enabled
<lamont> if 1.0.5 can actually build itself, then we have a good chance of having things happy
<lamont> jdub: I'll let you ask yourself to approve the sync.. :-)
<jba> lamont, didn't know that was the problem, I'm pretty sure 1.1.4 can build itself, 1 sec and I'll check
<tseng> jdub: copied to http://smarterits.com/~brandon/tomboy/
<jba> from #mono
<jba> <jba> hey guys can 1.1.4 build itself?
<jba> <miguel> This is just a preview I repeat
<jba> <miguel> jba, yes
<jba> its still a preview guys, but it's meant to be the most stable release so far
<ajmitch> jba: do you think it is good to put in a devel branch of mono over a stable branch?
<jdub> yeah, a number of mono hackers have been urging us to upgrade to 1.1.x because it's better that 1.0
<jba> not yet no
<jba> i'm just asking about it is all
<ajmitch> especially as the upstream version freeze is in place now
<jba> aah well, next time 
<ajmitch> it's up to the release people here anyway :)
<jdub> ajmitch: though we're more relaxed with universe
<ajmitch> jdub: yeah, which is a good thing
<jba> to be honest, this kind of thing is precisely what upstream version freeze is for
<sladen> mdz: just answering that email.  splash=  can stay on the command line, and usplash will happily draw a similar-ish text equivalent.  What should probably be ommitted is that 'video='  or  'vga=' lines
<jba> stop upstream packages sneaking in cause they're almost there at release time
<tseng> jba: er, not really
<tseng> before freeze things are auto synced from sid, thats what needed to be frozen
<tseng> as far as manual merges, they can be followed closely
<tseng> and reverted at worst case.
* tseng points at warty firefox
<jba> well in that case, a quote from miguel
<jba> <miguel> I strongly suggest 1.1.4 instead of 1.0.x series at this point
<jba> <miguel> Unless you must remain stable
<tseng> jba: note that mono is in universe as well
<mako> jdub: that's cool!
<jba> tseng, yeah jdub enlightened me to that fact too
<jdub> mako: going to do this every morning or so
<mako> jdub: rock
<jdub> mako: it's now in <ul> so you can copy to traffic :)
<jba> jdub, you never got back to me about the smb share extension? am i beating a dead horse without knowing it?
<jdub> jba: oh, which one was it?
<jba> i'llget linky again
<tseng> jdub: tomboy mirror working now?
<jdub> tseng: so, you don't need the debian/dirs file
<jdub> especially with usr/sbin in it ;)
<jba> jdub,  http://gentoo.ovibes.net/nautilus-share/
<jba> and http://gentoo.ovibes.net/nautilus-share/ubuntu
<jba> it works a treat for sharing folders in smb over a network
<jdub> ah, yes, i remember that one
<jba> it would be nice to have something similar in ubuntu by default
<duncanm> yo yo yo
<duncanm> jba: you're here already?
<tseng> jdub: gone now.
<jdub> yes, but i'd rather not add random things where there are gnome things on their way
<jba> duncanm, yeah, been here a while dude
<jdub> tseng: you are?
<jdub> oh
<jdub> dirs
<tseng> ya
<duncanm> i'm here to promote the use of Mono 1.1.x as the stable Mono to ship
<jba> jdub, that's what i was asking you, is there a gnome thing coming?
<jdub> tseng: i'd recommend versioning your package '0.3.1-1ubuntu1'
<tseng> i havent made a patch yet to force the install into /usr/share/dotnet
<jdub> duncanm: i'd like to, we just need someone keen enough to test that 1.1.4 can build, and all the important apps work with it
<jdub> tseng: yeah, so i roughly think that's crackish
<tseng> jdub: id agree, but its the policy laid forward
<tseng> so it should be done at some point.
<jdub> tseng: if you're intending to get it into debian, go for it :)
<tseng> id like to get a sane pacage into hoary for now
<tseng> and conquer debian another day
<jdub> yeah
<jdub> otherwise it's looking very sane
<ajmitch> tseng: what have you been packaging?
<jdub> you don't really need DOCS given your rules file
<tseng> oh on blam you mentioned an s/libxml/intltool
<tseng> does that apply?
<tseng> ajmitch: tomboy atm
<ajmitch> alright
<jdub> tseng: s/libxml-parser-perl/intltool/
<tseng> yep
<ajmitch> noone has taken up gsf-sharp & evolution-sharp yet?
<jdub> yeah, that'd be good too
<jdub> ajmitch: no one's said anything
<ajmitch> alright
<ajmitch> I'll take a look then
<tseng> jdub: one question
<tseng> jdub: lintian complains about duplicate deps, thats from the ${net:Depends} ${sh:Depends}
<tseng> not sure where i pulled that from, but im unsure if net:Depends by itself will get all deps properly
<tseng> like libgtkspell
<tseng> anyway to spot check that?
<ajmitch> ${net:Depends} is from dh_netdeps, iirc
<tseng> yes, it is
<tseng> but i dont think all the linked code is managed
<ajmitch> it says it'll look at the assemblies for info
<ajmitch> right
<jdub> hrm, i don't seem to have dupe depends
<tseng> oh i just have net:Depends atm
<jdub> oh
<tseng> im thinking that might not catch libgtkspell, however
<tseng> try adding sh:Depends
<tseng> i put up 1ubuntu1 with your suggestions also.
<jdub> with only net:Depends, i have:
<jdub>  Depends: mono-jit (>= 1.0.4) | mono-mint (>= 1.0.4), libdbus-cil (>= 0.23-2), libgconf-cil (>= 1.0), libglib-cil (>= 1.0), libglib2.0-0 (>= 2.6.0), libgnome-cil (>= 1.0), libgtk-cil (>= 1.0), libgtkspell0 (>= 2.0.2), libpanel-applet2-0 (>= 2.9.90), mono-assemblies-base (>= 1.0)
<jdub> 
<tseng> perfect
<jdub> interesting though, we should find out more
<tseng> id say that makes 1ubuntu1 a winner.
<ajmitch> 1ubuntu1 or 0ubuntu1?
<jdub> 0ubuntu1
<tseng> oh..
<jdub> oh, i wrote 1ubuntu1 above, sorry
<tseng> will fix
<tseng> i missed debian/docs also
<tseng> refresh.
<jdub> tseng: smarterits again?
<tseng> yep.
<tseng> jba: still here? whats the take on gkt-sharp2?
<jba> works well for me
<jdub> tseng: uploading now :)
<tseng> jba: its only 1.9.1, but rock solid here.. the muine maintainer has packages up
<jba> most of mono in svn at the moment deps on it
<tseng> jdub: rock, thanks
<tseng> jba: yes i run muine-cvs
<jba> tseng, 1 sec i'll ask tberman why the number wasn't bumped
<tseng> jba: would love to get a package in when 0.8.1 hits
<tseng> which number?
<ajmitch> hmm, why does mono-mint appear to be at 0.96?
<tseng> ajmitch: thats the minimum version per standards
<duncanm> oh, i'd like to advocate not to ship mint, btw
<duncanm> we have JITs available on a lot more architectures now
<tseng> mint is needs on amd64 in 1.x
<jdub> duncanm: we ship mint on !386 !powerpc
<tseng> 1.0.x
<jba> tseng, most of mono gtk tool sin svn now dep on gtk-sharp 2 anhyhow
<jdub> duncanm: amd64?
<duncanm> tseng: yeah, but it's no longer the case for 1.1
<ajmitch> tseng: yes, but it appears to depend on other 0.96 packages
<jdub> duncanm: sparc?
<duncanm> we have a JIT for amd64 in 1.1, and also a more stable sparc JIT
<jba> including gtkmozembed, monodevelop, gtksourceveiew-sharp and co
<duncanm> jdub: we have a sparc JIT
<jdub> cool
<duncanm> we run regression test suites on it too
<duncanm> as we move towards 1.1.x
<jdub> would you recommend the option of mint or jit for sparc?
<duncanm> and towards the 2.0 framework
<tseng> jba: hm, so the consensus is to package it?
<duncanm> i think the JIT will work
<duncanm> mint will become less and less maintained
<duncanm> because all the work on doing .NET generics is happening on the JIT
<tseng> jdub: thanks for all your help dude.
<jdub> so it's kinda jit-or-die really?
<duncanm> and it is unlikely that the interpreter will get generics support
<jdub> tseng: no probs, now we just have to get you MOTU love :)
<ajmitch> tseng: the debian pkg-mono group don't appear to have 1.1.x stuff packaged at all
<duncanm> well, .NET was always envisioned to be JIT'ed
<tseng> ajmitch: nope
<tseng> ajmitch: the muine maintainer has them in his webspace
<ajmitch> ah
<ajmitch> lovely
<jdub> tseng: aha, handy :)
<tseng> ill dig them out
<duncanm> it can be interpreted, but that was never a stated goal in its design
* ajmitch gets back to trying to get a gsf-sharp tarball
<jba> ajmitch, what is gsf-sharp ?
<tseng> http://www.ilrt.bristol.ac.uk/people/cmdjb/2004/muine/devel/
<tseng> muine cvs and gtk-sharp2
<duncanm> hrm
<ajmitch> jba: package used by beagle for reading office files, iirc
<jba> aah that;s right yeah
<ajmitch> not that you can tell from the README
<jba> by the way guys, duncanm is the guy that does most of the packaging for mono releases, he can be of great assistance here
<duncanm> who decides on how Mono is done for ubuntu?
<miguelkj> Hey folks
<duncanm> from the Mono standpoint, it'd be nice if the package names are all the same
<ajmitch> duncanm: as I understand it, no one person yet :)
<miguelkj> I wanted to clear up some confussion
<duncanm> hey miguel
<ajmitch> hello miguel
<miguelkj> Mono 1.1.x is a superset of Mono 1.0.x
<miguelkj> Hey Dude
<mako> miguelkj: hola
<miguelkj> Gtk# 2.0 is not a superset of Gtk# 1.0
<miguelkj> Is a refactoring and cleanup effort, which *might* break (although we have tried not to)
<jdub> morning miguelito
<miguelkj> Gtk# 1.9.xxx is still a development version, and its api is likely to keep changing 
<tseng> heya miguel
<wasabi> So, mono 1.1 + gtk# 1.0 should be compatible?
<duncanm> miguelkj: i'm also talking of not shipping 'mint'
<miguelkj> For now we are recommending that people use Gtk# 1.0, and if they want to use Gtk# 2.0, that its properly flagged as `unstable'
<duncanm> wasabi: they are compatible
<miguelkj> mono 1.1 + gtk# 1.0 is just perfect
<ajmitch> duncanm: currently the packaging for mono is grabbed straight from debian
<wasabi> yes yes, i don't mean with each other
<jdub> duncanm: we're following debian mono guidelines for the moment
<miguelkj> You can parallel install gtk#1.0 and 1.9, but 1.9 is still under development
<duncanm> hrm
<duncanm> from the Mono standpoint, it'll be nice if the package names are all the same, it cuts down on the FAQ
<tseng> im interested in shipping 1.9, as muine depends on it
<duncanm> but i dunno if that's possible
<miguelkj> That is fine, but flag the `-devel' packages as `unstable'
<miguelkj> Ie, dont encourage people to use it until we are done
<tseng> thats how it is here:
<miguelkj> (so we can avoid things like missmatches)
<tseng> http://www.ilrt.bristol.ac.uk/people/cmdjb/2004/muine/devel/
<tseng> the source, anyway, is -unstable
<tseng> the bins follow standard naming.
<miguelkj> Anyways, if someone has troubling questions, I will be happy to answer them
<miguelkj> Maybe I should write a FAQ on this subject
<jba> sounds like a good idea
<jdub> miguelkj: maybe a "SHIP THIS!" status thingy on the release page :)
<miguelkj> Heh
<miguelkj> Gtk# 1.0, Mono 1.0 usually
<miguelkj> But with 1.1.4 we have crossed the point where the -devel is way better than the -stable
<duncanm> tseng: do you guys have a /usr/share/dotnet dir in the Debian packaging?
<ajmitch> duncanm: yep :)
<tseng> yes.
<jdub> (sooo muuuuch craaaack)
<tseng> i didnt patch tomboy to follow that yet, i will before pushing to debian
<tseng> lest i be mauled
<ajmitch> jdub: it cou be worse
<duncanm> and that's a rename of /usr/lib/mono ?
<ajmitch> s/cou/could/
<miguelkj> what lives in share/dotnet?
<ajmitch> the GAC
<miguelkj> Oh, that is not right
<ajmitch> on my sid box I don't have /usr/lib/mono
<miguelkj> it should be lib/dotnet
<miguelkj> because there are certain per-architecture .dlls
<ajmitch> the argument was made that since they are meant to be arch-independent, they should be in share
<lamont> jdub: wrt mono, if we decide that we don't want 1.1 because of UVF, we should really take 1.0.5 instead
<ajmitch> that's what I assumed
<miguelkj> Someone did not know better
<duncanm> lamont: what's UVF?
<tseng> duncanm: upstream version freeze
<lamont> upstream version freeze
<miguelkj> I can tell you right now that its broken ;-)
* ajmitch is still the pnet packager for some reason, which uses /usr/lib/cscc
<lamont> 1.0.4 violates holy principles
<tseng> miguelkj: ironically, they argue in ignorance of your point that lib is for arch specific libs
<duncanm> who's the debian packager for Mono?
<ajmitch> the numbers don't add to a multiple of 3?
<tseng> miguelkj: if there are arch-specific dlls, their case falls apart.
<miguelkj> yes, and some of our dlls are arch specific
<ajmitch> duncanm: pkg-mono.alioth.debian.org
<miguelkj> oh well ;-)
<miguelkj> Its not like anyone seriously splits share and lib anyways
<miguelkj> Nowadays nobody has any of those nfs setups
<jdub> lamont: yeah, agree
<jdub> lamont: perhaps we should just sync that, and see if 1.1.4 happens
<lamont> jdub: anyway, I await y'all's decision on it...
<miguelkj> Also, at least for Mono assemblies, you should use $prefix/lib/mono, not $prefix/lib/dotnet
<tseng> 1.0.5 isnt in sid yet.. still on alioth
<miguelkj> To begin with, we are not dotnet ;-)
<lamont> if 1.0.5 syncs and someone tells me, I'll bootstrap it on whichever architectures it likes
<jdub> ajmitch: ah, no wonder you keep mentioning pnet. no one else thinks it's relevant. :)
<miguelkj> And to continue, that is also where we place precompiled object (ahead-of-time-compiled code)
<jdub> miguelkj: unfortunately the conventions wiki page is b0rked atm
<miguelkj> Maybe I should speak with the upstream maintainer of Mono
<lamont> tseng: mono won't be in sarge until 1.0.5...
<jdub> would be good to get some comments on it
<miguelkj> (the mono package)
<miguelkj> Sure
<lamont> since it has critical bugs against it...
<tseng> jdub: its in /usr/share/doc/mono-utils
<lamont> s/critical/serious/
<miguelkj> I wonder who came up with the idea of renaming the directory
<tseng> jdub: er, no
<miguelkj> we worked so hard to eliminate the notion of `dotnet', just to get it slapped right back 
<jdub> miguelkj: are you running ubuntu on one of your machines yet? :)
<ajmitch> jdub: I actually heard of one person using it the other day ;)
<miguelkj> Yes, in my other t40
<miguelkj> we really worked hard on that ecma/non-ecma split
<miguelkj> Our Gtk# is not touching any non-ecma for that reason (which everyone wants to)
<tseng> jdub: miguelkj http://smarterits.com/~brandon/README.Debian.gz
<miguelkj> So puting `dotnet' on the string is just flame material
<tseng> ^ crack
<jdub> miguelkj: ^ pull that file :)
<jdub> tseng: thanks
<tseng> nps
<miguelkj> uh oh
<tseng> if you beat them senseless over it, jdub and I would be two happy dudes
<tseng> patching every mono app to install there is crack
<miguelkj> oh my
<miguelkj> this is horrible
<miguelkj>  /usr/bin/cli  chooses between mint and mono
<miguelkj> There is no need for an extra wrapper
<miguelkj> Not to mention that the command line args are incompatible
<ajmitch> it should be a symlink
<ajmitch> well, it should have been in the past
<miguelkj> ilx, mono and mint all use different arguments
<ajmitch> lovely
<miguelkj> Patching every mono app sounds like a painful process
<miguelkj> It seems that the document was written by someone who barely knew Mono sadly
<tseng> this was written pre-beta
<miguelkj> Debian people are famous for being hard to convince
<tseng> but its still in play for some reason
<miguelkj> Is it that still the case?
<miguelkj> See, some of the cases discussed there we have taken care of upstream
<ajmitch> there are only 3 or so in the mono packaging group
<ajmitch> it shouldn't be too hard to convince them
<miguelkj> Will talk to them
<miguelkj> What are their email addresses?
<tseng> http://lists.alioth.debian.org/mailman/listinfo/pkg-mono-devel is the list
<miguelkj> Thanks Tseng
<miguelkj> Will go watch the daily show now
<miguelkj> Be back afterwards
<tseng> no, thank you.
<duncanm> haha
<bluefoxicy> tseng:  yo
<bluefoxicy> is XSS a bug or an exploit?
<tseng> hi blue
<tseng> cross site scripting?
<bluefoxicy> I say it's a bug because . . . it looks like a bug . . . and leads to infoleak or privesc
<bluefoxicy> yeah
<tseng> it depends
<bluefoxicy> but infoleak can lead to privesc o.o
<tseng> some XSS is more malicious than others, no?
<bluefoxicy> yeah but-- *sigh*
<bluefoxicy> tseng:  http://usrbac.sourceforge.net/misc/www/security.html
<bluefoxicy> tseng:  more of my toys
* tseng nods
<bluefoxicy> I have no idea what I'm doing
* lamont heads to bed
<tseng> nite lamont
<bluefoxicy> hmm.  OK, since XSS can be "fixed" and has no "bug" behind it I'm going to call it a bug?  (I don't know how XSS happens)
<tseng> sure, call it a bug.. can you do this in the other chan?
<bluefoxicy> I've been +q'd for like 4 days or something
<bluefoxicy> I think they made it permenant
<tseng> oh.
<thully> any developers here?  if there is, I have a local.conf that may possibly work for enabling autohinter only at large point sizes
<tseng> jdub: =/
<tseng> jdub: configure: error: Library requirements (libpanelapplet-2.0) not met;
<tseng> missed that one, part of the applet switchover
<aj> daniels: around?
<jdub> tseng: oof, it's an applet now?
<tseng> jdub: yes
<tseng> jdub: but the notification is still there.
<jdub> oh
<jdub> weird
<tseng> if you prefer
<jdub> how does that work?
<jdub> oh
<jdub> ok
<tseng> its a command line switch
<tseng> i have a new package, unless you want to just fix locally and reupload
<jdub> shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
<jdub> ^ getting a lot of that during upgrade
<jdub> tseng: 0ubuntu2?
<tseng> yes
<tseng> upgrade of tomboy there?
<jdub> uploaded
<tseng> thanks
<daniels> aj: what up
<aj> daniels: i have logs/conf; where you want them?
<daniels> aj: daniel.stone@ubuntu.com
<mdz> jdub: that'll happen if you run the upgrade from a nonexistent directory :-P
<aj> oh, hrm, do you want debconf stuff too?
<jdub> mdz: ... bong! i am too ;)
<mdz> aj: he doesn't, typically
<daniels> aj: nah, it should be fine, thanks
<daniels> mdz: the last of my amd64 bits are arriving tomorrow, so I'm going to tackle ddcprobe-on-amd64
<fabbione> can anybody explain to 2124 submitter the meaning of WONTFIX?
<mdz> nice
<fabbione> (morning btw :-))
<daniels> mdz: ironically, the x850 xt pe is on order (not that I'll be able to afford it until next payday, which is when it rolls in, anyway), so I'm going to be using a PCI video card in there for a while ;)
<mdz> x850 xt pe?
<aj> daniels: on its way
<daniels> mdz: the best radeon money can buy
<daniels> mdz: pcie
<mdz> ah
<daniels> aj: thanks
<mdz> drivers?
<daniels> mdz: 2d
<daniels> mdz: (and fglrx)
<daniels> mdz: but yeah, i believe it will be faster to run a shadow framebuffer in system memory with the cpu doing all the operations than to use pci
<jdub> wjpa
<daniels> aj: oh right, *that* bug
<jdub> whoa
<jdub> gregkh@novell.com
<fabbione> good
<fabbione> inotify sparc64 support is upstream as 3 minutes ago
<jdub> woo :)
<daniels> jdub: woah
<tseng> g'nite dudes
<aj> daniels: would've been much less of a problem if i'd actually noticed xorg.conf hiding, rather than saying "hrm, /etc/X11/X*... nope, nothing XOrgish, there, must be reusing the config file..."
<jba> thanks for your help today guys
<jba> gotta head off now
<daniels> heh :) i wanted to punt it to /etc/xorg.conf; /etc/X11/xorg.conf was the compromise
<jba> see you all later
<sivang> morning all
<sivang> hmm, am I too early? ;-)
<zenrox> hep
<zenrox> yep
<sivang> zenrox: heh, hi , 'sup?
<zenrox> not much
<zenrox> just listing to lugradio
<sivang> eh, what's on now?
<zenrox> go get it and listen to it and find out
<sivang> zenrox: do you know the episode which contains the interview with sabdfl?
<infinity> daniels : You're building a PCIe amd64?.. Which motherboard did you get?
<HrdwrBoB> nforce :(
<zenrox> sivang, 2 ep 17 for the conical guy and 2 ep 18 for some other guy  invoulved with ubuntu
<infinity> HrdwrBoB : Ick.  I was looking at the Abit AX8 when I was shopping, but PCIe video cards were so hard to come by (and priced higher, to boot), that I settled on the AGP version of the same.
<HrdwrBoB> yeah
<HrdwrBoB> now PCIe is easy/cheap (ish)
<infinity> I dunno.
<infinity> PCIe video cards still seem to carry a premium price over their AGP counterparts.
<HrdwrBoB> a 6600GT is the best bang/buck atm and is in PCIe everywhere
<HrdwrBoB> not really
<infinity> I bought a 6800GT.
<HrdwrBoB> the native PCIe stuff is cheaper in some cases
<infinity> The PCIe ones seem scarce.
<infinity> Despite the fact that the entire 6xxx line is native PCIe, with a PCIe->AGP bridge on the AGP cards.
<infinity> Either way, I'm not really concerned.  It'll be a long time before I find something that needs that much bandwidth to the card.
<infinity> And when I do, it'll probably be upgrade time again anyway.
<HrdwrBoB> currently (at the price list I'm looking at) a 6600GT PCIe is $20AU cheaper than an AGP
<HrdwrBoB> but eh
<HrdwrBoB> not really a big deal
<sivang> zenrox: this is a live radio? I mean, do they broadcast all the time?
<zenrox> no
<zenrox> prerecorded then thay release
<sivang> zenrox: woo, they have some very high upstream
<zenrox> ya
<fabbione> mjg59: i just saw a huge acpi update in bk... is it something interesting to look at?
<sivang> 500Kb/s
<sivang> fabbione: morning, how do you feel today?
<fabbione> sivang: much better thanks...
<sivang> fabbione: great, I'm glad to hear that :)
<fabbione> so am i :)
<sivang> zenrox: also very high quality stream
<zenrox> the oggs are much better
<sivang> zenrox: I am only using the oggs :)
<zenrox> ya the high quailty oggs are great
<zenrox> but its killing my cpu
<sivang> zenrox: ah, I have a 2.6G HT machine...
<zenrox> 2ghz celron no ht
<sivang> zenrox: I'll try to compile gnome-system-tools in the background :)
<zenrox> lol
<sivang> zenrox: I also designated this machine to be a development system, so got 512MB of ram..which is the minimum for such a system, but the best I could efford :)
<zenrox> i have 516 in mine ddrpc 2100
<sivang> dholbach: morning!
<dholbach> good morning everyone
<dholbach> hi sivan!
<dholbach> jdub: still there?
<sivang> dholbach: 'sup?
<dholbach> sivang: guess i need some coffee first :-)
<ajmitch> hi dholbach 
<dholbach> hi ajmitch
<pitti> Morning
<ajmitch> morning pitti 
* fabbione shows some love to pitti
<sivang> pitti: morning
<pitti> fabbione: do you feel better now?
<fabbione> pitti: check your inbox ;)
<fabbione> and yes.. i am almost 100%
<pitti> nice to hear
<pitti> fabbione: btw, no can for the broken sendcmsg compat syscall fixes
<fabbione> ok
<pitti> fabbione: as I already said in the meeting, I can care for kernel security updates during your honeymoon :-)
<pitti> fabbione: that mail was just to inform you about it
<sivang> was there a CC meeting yesterday?
<sivang> (or TB)
<ajmitch> sivang: tomorrow, I think
<ajmitch> well, in a few hours
<sivang> I recall there was some talks in having a different time for the meeting each time, for benefit of all timezones.
<ajmitch> I'd like that
<ajmitch> since the meetings are scheduled for 5AM NZ time :)
<sivang> yeah, jdub also suffers from that :)
<ajmitch> 3am isn't quite so bad
<zenrox> ya but 3am is bad if you got to go to work at 5am
<infinity> If you go to work at 5am, you need a new job.
<zenrox> i am jsut glad i dont need to work
<infinity> Oh, hey, neat.  I just converted a friend to Ubuntu.
* infinity pats himself on the back.
<sivang> infinity: cool
<infinity> I like this quote: "This is the first Debian install I've
<infinity> actually gotten to work with X at all, so that's something.  I don't
<infinity> think that I'VE gotten any smarter in the last few months :)"
<infinity> Well, there was also: "It's very... brown."
<fabbione> hmmmm
* fabbione is temped to pull all the alsa 1.0.8 from bk
<fabbione> elmo, Kamion: ping
<fabbione> elmo: please sync silo-installer 1.00 from Debian
<magnon> wow, ubuntu-users is larger than my spam folder
<magnon> that has never happened for a list
<magnon> after checking neither for a week
<elmo> fabbione: violates UVF, please mail jdub & mdz, cc me.
<fabbione> elmo: it's only for sparc.. unreleased arch.. unofficial arch, but yes i will even if Kamion agreed on the changes
<elmo> fabbione: i realise that, but I've been told not to make assumptions on this kind of thing
<fabbione> elmo: no problem at all
<Mithrandir> hi fabio, gotten well again?
<fabbione> Mithrandir: much better thanks
<elmo> fabbione: kernel-latest-2.4-sparc is in NEW - do we actually want it?
<fabbione> elmo: it's nothing more than a copy of linux-meta
<fabbione> i think we should let it in.. it's harmless for us
<Kamion> elmo: veto silo-installer
<Kamion> it has Ubuntu branding, it should be merged not synced
<fabbione> Kamion: did you read my comment in the mail?
<Kamion> oh, haven't read mail yet
<fabbione> Kamion: it makes more sence to just sync it and rebranding
<fabbione> rebrand it
<Kamion> no it doesn't, I'll merge in the way I do everything else
<fabbione> Kamion: if you prefer that way, is ok with me
<Kamion> yes, I definitely do
<fabbione> than it is more than fine for me
<fabbione> elmo: don't sync please :)
<Kamion> I'll do the merge once I've caught up on mail
<fabbione> no rush
<fabbione> did the kernel work btw?
<fabbione> (mad64)
<Kamion> I've only just woken up, give me a minute :-)
<fabbione> sure
<fabbione> even one hour
<elmo> fabbione: #6057 is bogus - I've already reported bugs against nagios-plugins and cyrus-sasl, the bug is in them and they need fixed
<fabbione> elmo: i already had one on cyrus-sasl
<fabbione> i wasn't sure if germinate missed the b-d
<ogra> morning
<dholbach> hai ogra
<elmo> fabbione: nope, I chose to ignore germinate
<fabbione> ok
<Kamion> fabbione: germinate is responsible for *saying* that something should be in main, but not for actually causing it to be in main - that last step is manual
<Kamion> and for the record:
<Kamion> <cjwatson@cairhien ~/src/ubuntu/germinate/hoary>$ grep libradius1-dev supported+build-depends
<Kamion> libradius1-dev                            | radiusclient                    | nagios-plugins (Build-Depend)            | Turbo Fredriksson <turbo@debian.org>                                      |           29402 |             116
<fabbione> roger :-)
<dholbach> good morning seb128 :-)
<Kamion> I've just made http://people.ubuntu.com/~cjwatson/germinate-hoary-output/ look at universe and multiverse as well, so that people can see what's going on without having to run germinate themselves
<fabbione> sweet
<seb128> morning
<seb128> m'rning
<Kamion> /sbin/grub-install: line 516:  9593 Segmentation fault      $grub_shell --batch $no_floppy --device-map=$device_map  >$log_file <<EOF
<Kamion> fabbione: bzzt
<Mithrandir> Kamion: kernel thingythangy?
<fabbione> Kamion: is that with -13?
<Kamion> ii  linux-image-2.6.10-2-amd64-generic      2.6.10-13     Linux kernel image for version 2.6.10 on x86_64.
<Kamion> Linux cittagazze 2.6.10-2-amd64-generic #1 Mon Jan 31 06:52:49 UTC 2005 x86_64 GNU/Linux
<fabbione> FUCK FUCK FUCK
* Kamion goes to do the live CD dance
<Mithrandir> Kamion: it was the noexec flag?
<Kamion> Mithrandir: noexec=off works around it
<Kamion> but isn't a good long-term solution
<Mithrandir> agreed.
* fabbione would love a fic
<fabbione> FIX
<fabbione> i can't type
<elmo> not being funny, but have you tried a newer grub?
<Kamion> I was surprised when you said it was fixed upstream, since there's been no reply to my post on linux-kernel
<Kamion> elmo: it's not grub's fault, I've investigated a fair bit
<Kamion> elmo: you can chroot into the exact same userspace from an old kernel and get no segfault; the reason for the segfault is that the amd64 kernel isn't honouring the exec-stack bit on ia32 binaries, or something along those lines
<Mithrandir> elmo: it's support for the NX bit which makes nested static functions fall over, or something.
<Kamion> right
<Kamion> nested functions need an executable stack trampoline in order to access local variables of the outer function
<Kamion> grub uses those, so unless large bits of it have been totally rewritten not to, a newer version won't help
<elmo> you mean it's not respecting PT_GNU_STACK on ia32 binaries?  how are RH, SuSE etc. not seeing this?
<Kamion> exactly, and I have no idea, but Debian people are seeing it too
<Kamion> and I can reproduce it with stock kernels
<Mithrandir> does RH, SuSE ship 2.6.10?
<elmo> do they ship ia32 grub?
<Mithrandir> elmo: this is a recent change -- 2.6.9-bk2 or something.
<Mithrandir> if they want it to fly on amd64, pretty sure.
<elmo> Mithrandir: FC4 at least must (not ship, but use)
<Mithrandir> elmo: do you happen to know if they use lilo or grub by default?
<Kamion> 2.6.9-bk2 was the first release that set noexec=on by default
<elmo> nah, I've never even seen a FC install - thom's the fedora fanboy
<elmo> Kamion: was it you that pointed me to that cleanup patch related to the PT_GNU_STACK handling?
<elmo> 'cos I know exactly which patch you mean, but I don't know if that's 'cos you told me about it, or 'cos I read it on lkml because it involved PT_GNU_STACK
<Kamion> elmo: I did mention a patch here that cleaned up noexec kernel parameter handling
<fabbione> Kamion: do you have the patch changeset handy again?
<fabbione> i want to check some other bits around it
<Kamion> fabbione: not at the moment I'm afraid; grep for gnupatch in the logs of this channel maybe?
<fabbione> oh right.. and i even have the logs here
<Kamion> aha, there it is
<Kamion> http://linux.bkbits.net:8080/linux-2.6/gnupatch@41752e4eX1Y99rE-GhfPoRzKlwh85g
<fabbione> ah nice
<elmo> Kamion: and reverting that does/doesn't fix it?
<elmo> boggle
<elmo> that patch says noexec=off was default for ia32 bins on amd64 anyway?
<carlos> pitti: hi, around?
<fabbione> elmo: exactly...
<Simira> carlos: morning
<carlos> morning
<pitti> carlos: yes, hi
* Mithrandir ruffles Simira
<Simira> hey
<Simira> carlos: care to fix some language-issue on Rosetta? There are too many Norwegian alternatives ;)
<Simira> Mithrandir: behave
<carlos> Simira: need to finish the import task first :-(
* thom bitchslaps elmo
<Simira> carlos: ok. Is it possible to put some kind of note to it, that "Norwegian" is not valid for translations, or something?
<thom> fedora fanboy indeed
<carlos> Simira: we don't have a way to do it atm
<Simira> carlos: ok then. I'm reporting a few other bugs as well, now.
<elmo> giggle
<carlos> Simira: perfect, thanks
<Mithrandir> Simira: it ought to be possible to update translations which are there already, though.  And migrate no -> {nb,nn} easily.
<Mithrandir> thom: do you know what boot loader FC uses on amd64?
<thom> grub afaik
<thom> in 32bit mode
<Mithrandir> ook
<Kamion> elmo: used to be the default; it's noexec=on now
<Kamion> elmo: reverting that does fix it, but is badness
<Kamion> sivang: say I've got a Hebrew .po file mentioning "" (should be "Debian" from context I think); how would I replace that with "Ubuntu"?
<elmo> Kamion: no, if you just revert the whole patch, we'd have working grub and could patch noexec (not noexec32) to be forcibly on
<elmo> IYSWIM
<sivang> Kamion: 
<sivang> Kamion: got that? :)
<Kamion> elmo: er, hmm, kinda unconvinced, noexec32 is a good thing and I'd rather fix it to work properly if possible
<Kamion> sivang: I can read it - in right-to-left display, is "" the rightmost letter?
<sivang> Kamion: yes
<Kamion> sivang: ok, cool, thanks a lot
<sivang> Kamion: no prob! where is this going to? do you need help with hebrew trans?
<Kamion> -"  SILO       ,   - "
<Mithrandir> Kamion: noexec32 isn't really important -- nobody sane will run 32 bit stuff anyhow. :)
<Kamion> +"  SILO       ,   - "
<Kamion> except I think pasting might have done something totally wacky to the RTLness of that
* smurfix notices that x-chat's bidi support is nonexistent
<Xof> it looks pretty in iso-8859-1, too
<sivang> smurfix: true, I am reading hebrew left to right on IRSSI :) (got used to that already)
<sivang> Kamion: yes, the beginning and end
<Kamion> my God, it's kind of swapped bits around the word "SILO"
<Kamion> looks right in vim/pterm though
<elmo> boggle - that looks REALLY ba din irssi
<Kamion> sivang: it's in d-i branding in general - basically once I have a rule for converting "Debian" to "Ubuntu" I can apply it everywhere and not have to bother you again. :-) There aren't going to be any funky word-endings or anything?
<amu> moins 
<sivang> Kamion: not as I can tell, what do you mean funky? ;-)
<Kamion> well, like Czech says "Debianu" sometimes
<Kamion> is wiki login broken at the moment?
<sivang> Kamion: not, hebrew is plain straight for most of it.
<Kamion> ok, cool
<sivang> Kamion: howevr, thre is somethign there strange like "You system can do" where do is mentioned as in a male addressing, where as system is a female in hebrew
<sivang> Kamion: maybe this was cut due to pasting?
<sivang> Kamion:    ==<   
<Kamion> sivang: hm, looks fine in the editor, I think it's a paste bug
<sivang> Kamion: I should finish some of Kinnison's courseware I want to write for him, then you coould join him and study ;-)
<Treenaks> sivang: put it online somewhere, so the whole world can learn :)
<Kamion> sivang: http://people.ubuntu.com/~cjwatson/silo-installer-hebrew.png is how it really looks
<sivang> Kamion: cool, notice the "" there? it makes the word "do" in hebrew from male to female addressing. Cool!
<sivang> Kamion: so it's fine.
<sivang> Treenaks:I will :)
<Treenaks> sivang: cool :)
<Treenaks> sivang: or you could add to http://en.wikibooks.org/wiki/Hebrew
<sivang> hmm, nice
<sivang> wikipedia is phenomenal
<dholbach> have a pleasant day - i'm off
<sivang> dholbach: bye!
<dholbach> bye sivang :-)
<Treenaks> too bad only the first chapter really explains something though :(
<Treenaks> and not really detailed either
<Kamion> incidentally if anyone around here knows how to translate "Debianu" in Czech and/or Slovak, that'd be good too
<Kamion> er, translate => change it to be referring to Ubuntu
<aj> Ubuntuu? :)
<Kamion> "Debiana" in Polish too
<Mithrandir> aj: that'd be finnish. :)
<Kamion> aj: I considered that briefly and rejected it as improbable, but who knows :)
<Treenaks> Kamion: no strange Dutch transformations?
<Kamion> Treenaks: not as far as I can tell, I've just got stuff like "Debian-opstartpartitie" => "Ubuntu-opstartpartitie"
<Treenaks> Kamion: looks right
* sivang going to get something to eat.
<Simira> daf, carlos: so, there you go, six bug reports for Rosetta. You won't be bored in a little while, then. :)
<daf> gosh!
<daf> thanks :)
<carlos> Simira: thanks!
<carlos> :-D
<Kamion> sivang: I've got one string that says "" instead of "" - is that a male/female thing again, and does it apply to "" in the same way?
<sivang> Kamion: no, it's like "the debian"
<sivang> Kamion: the "" is in the front this time
<sivang> Kamion: not sure how you would tranlsat that, could you show me the contexT?
<Kamion> " , /boot     ${PARTTYPE}.     , "
<Kamion> "        SILO."
<Kamion> with the usual inversion crap around ASCII letters
<Kamion> right-to-left HURTS MY BRAIN
<sivang> Kamion: am reading it LTR ;-)
<sivang> Kamion: ok, you can use "" it's the same meaing :)_
<sivang> Kamion: which would mean "you will not be able to boot your ubuntu system", in hebrew it's like
<Kamion> yeah, that's the English text, thanks
<sivang> "you will not be able to boot the ubuntu system of yours" in a hebrew arrangemtns translation..
<Kamion> operating vim in RTL is even more confusing, if that's possible
<sivang> there are suportive packages, I need to speak tp pitti to include them in the langpack
<Kamion> oh it works, it's just weird
<sivang> Kamion:, k cool, for anything ping here or in msg :)
<Kamion> ta
<daniels> Kamion: christ, I could imagine that would screw you up
<Kamion> elmo: wiki login doesn't love me at all - I just reset my password and it's still not accepting it
<smurfix> Kamion, elmo: Mine doesn't work either
<thom> Kamion: by way of a stupid question, could I hack round the usb keyboard problem with some preseeding action? Given the current cd, could i get to the point of having a working sshd?
<elmo> Kamion: mmk, one sec
<Kamion> thom: preseeding only works if there's a debconf question to preseed
<thom> Kamion: i was thinking about the language choices
<thom> oh well
<thom> i'll try redownloading array 3 and hope that the internet is less broken today
* daniels chortles.
<Kamion> thom: oh, yeah
<daniels> thom: you can visit here if you want -- i have working internet
<Kamion> thom: what kind of system?
<daniels> thom: ever thought of moving somewhere with actual bandwidth?
<Treenaks> daniels: like Australia?
<daniels> fo'sho
<pitti> sivang: just tell me the package and I will crank up my langpack-o-matic go generate a new support package :-)
<Kamion> thom: if it's a Mac, try booting with 'install preseed/locale=en_GB console-keymaps-usb/keymap=mac-usb-uk'
<thom> Kamion: dual G4 mac
<thom> Kamion: righto
<abelli> fabbione: ding
<thom> daniels: shuttit, level3 were just being crap
<fabbione> abelli: dong, dang
<elmo> thom: err?
<thom> elmo: they broke their bgp sessions for a while yesterday
<thom> Kamion: right, nice. i have a working keyboard now :-)
<Kamion> thom: bonus. would like to see /var/log/*, lspci, lspci -n, maybe lsusb
<thom> righto
<elmo> Kamion/smurfix: fixed - the lunchpadders br0ke it
<elmo> (and fixed it, to be fair ;)
<smurfix> thanks
<Kamion> heh, ok, thanks
<daniels> Kamion: ooi, have you still got xserver-xorg (or xserver-common, preferably) 6.8.1-1ubuntu11 kicking around?
<daniels> or anyone?
<elmo> ugh, anyone know how to make irssi make the line you're typing be per-window?
<Treenaks> elmo: yes, there's a scritp for that
<Treenaks> elmo: let me look it up
<Kamion> daniels: yes, installed on cittagazze
<Kamion> (amd64)
<Kamion> oh wow, irssi/screen/pterm reverses the digits in the datestamp when somebody types something involving RTL text
* decko vai tomar caf!
<daniels> Kamion: could you please look at line 83?
<daniels> if [ $? -ne 0 ] ; then
<daniels>     bomb "error while getting options; use \"$PROGNAME --help\" for help"
<daniels> fi
<Kamion> daniels: of which file?
<daniels> 81-83 should look like that; unfortunately a cat/younger sibling attacked that just before ubuntu12, and vim appears to have turned that into 'sudo di' (instead of fi)
<daniels> Kamion: ah, sorry, dexconf
<Kamion> daniels: looks fine here
<elmo> decko: please disable that public away or whatever it is
<daniels> Kamion: so it says fi?  thanks
<Kamion> daniels: yep
<daniels> Kamion: debian/rules now runs dexconf through validate-posix-sh ;)
<Kamion> heh
<Treenaks> elmo: hm, can't find it..
<daniels> mdz: 
<daniels>   * Rewrite Debconf logic to write a new xorg.conf if it doesn't exist, and
<daniels>     default to using xresprobe (use XORG_FORCE_PROBE=no to disable this
<daniels>     behaviour).
<elmo> Treenaks: ok, not to worry, I'll have a look myself later.. thanks
<elmo> hmm, what's the sanest/cleanest way to get multiple apaches running on different ports and with different configs with our packages?
<fabbione> elmo: why multiple apaches?
<fabbione> (just curious.. there is no really a sane way to do it)
<elmo> fabbione: I want to run a subversion webdav apache, and a 'everything-else' apache server
<elmo> 'cos I don't want to chown www-data the subverson repo
<elmo> and am quite happy to tell svn folks to use a different port/ip
<daniels> you allow commits over webdav?
<thom> different config, different init script, and the -f flag
<elmo> mmph, ok
<thom> daniels: why on earth wouldn't you?
<elmo> daniels: err, yes?
<daniels> *boggle*
<thom> fabbione: how is that not sane?
<thom> :-)
<daniels> not even fd.o allows that :P
<thom> dude, no login accounts. heaven
<daniels> true dat
<Kamion> uh ... you shouldn't have to chown www-data the repository with subversion 1.1 and fsfs
<daniels> i just dislike the idea of web server compromise -> your source is fucked
<elmo> Kamion: which so isn't in warty :P
<daniels> Kamion: you still will if you need to write to it, no?
<Kamion> oh, well, if you're using webdav you do have to
<Kamion> svnserve is so much saner though
<fabbione> thom: you still need to "replicate" the init script and adapt it to use the -f
<elmo> Kamion: requires logins..
<HrdwrBoB> elmo: wouldn't you be better off using a different MPM
<fabbione> thom: perhaps we can write a better init to look in /etc/apache/sessions.d or something...
<HrdwrBoB> and running another user with taht
<fabbione> thom: it's not that uncommon to run more than one apache
<HrdwrBoB> for the SVN webdav stuff
<thom> HrdwrBoB: eh?
<fabbione> elmo: make sense
<elmo> plus, this has a requirement to replicate an existing setup which is already using webdav, so it's moot
<Kamion> elmo: could be restricted to svnserve?
<Kamion> bleh, ok
<decko> elmo, Sorry, it's not a public away or whatever...
<elmo> god damn it.  first cup of tea -> 30 mins.  second cup of tea -> 1 hour.  this is a distrubing pattern of how long I keep forgetting about my tea
<daniels> elmo: i think you need a longer attention span
<HrdwrBoB> thom: sorry, still a pipe dream, apache2 has a 'perchild' mpm which in theory allows different users to run different virtualhosts, but it has never been released in any usable form
<thom> HrdwrBoB: it's probably useable for svn, but i wouldn't trust it
<sivang> pitti: sure cool
<HrdwrBoB> I'm just a little bitter, it makes apache look like a toy compared to IIS (which does what perchild would do)
<elmo> I love when people say things like that
<elmo> it may be a toy, but it's a you n (for ridiculously high versions of n) % of the internet's websites run on
<Treenaks> HrdwrBoB: I want threadpool + perchild!
<Treenaks> HrdwrBoB: with working php!
<HrdwrBoB> elmo: I know, this was in a mixed environment in a hosting company. when you have several hundred websites on a machine securing them from each other gets to be pretty important
<Mithrandir> thom: the metux mpm ought to work, don't you think?
<HrdwrBoB> Treenaks: yes, heaven!
<thom> Mithrandir: from what i've seen that lot look insanely incompetent
<thom> Treenaks: threadpool is less performant than worker these days
<thom> and that's basically what perchild is, yes
<Mithrandir> thom: oh?
<HrdwrBoB> http://www.metux.de/mpm/en/?patpage=download <- that says it all for metux
<Treenaks> thom: oh I'm running worker now.. but that's PHPless
<HrdwrBoB> Treenaks: I have used suexec and binfmt with php registered with some success (though obviously it doesn't work for everything)
<elmo> fabbione/thom: an $OPTIONS in the init script would be useful
<elmo> and, umm, what do I do about the invocations of apache2ctl?
<daniels> apache2ctl takes -f as well, IIRC.
<elmo> daniels: oh, that's not clear from the manapage
<daniels>   -d directory      : specify an alternate initial ServerRoot
<daniels>   -f file           : specify an alternate ServerConfigFile
<elmo> uh?
<elmo> that's not in the apache2ctl manpage dude
<daniels> gleaned from apache2ctl -h
<elmo>        apache2ctl command [...] 
<elmo> and no mention that a) options are accepted, or b) passed onto apache
<daniels> wow, that manpage is spondonically shit
<rburton> daniels: as bad as the X manpages?
<daniels> hah
<rburton> surely not!
<rburton> i started a list of X manpage crackrot before i gave up with them totally
<rburton> i should file lots of bugs
<daniels> yeah, don't bother
<daniels> well, file lots of bugs if you want
<daniels> but don't bother documenting crackrot
<daniels> 'clusterfuck' is a good summation
<rburton> some of the problems are silly things like typos and missing newlines
<rburton> which just make the man page a nightmare to read
<daniels> the newlines stuff is pretty much imake being absolutely screwed, and we can't do anything about it
<daniels> branden wrote a patch for it, which not only didn't fix the problem, but totally broke utf-8 locales
<daniels> i don't think it's fixable without work enough to be roughly equivalent to the time needed to throw imake away
<daniels> Kamion: kaping
<Kamion> daniels: kapong
<Mithrandir> you know it's good when you have gcc command lines which are long enough to fill a 1024x768 pixel pterm window
<daniels> Kamion: so, dvorak in d-i ...
<daniels> Kamion: any ideas?
<daniels> Kamion: looking at #5894
<daniels> jbailey: 'morning
<sivang> jbailey: morning
<Kamion> daniels: console-data contains all those maps
<daniels> Kamion: cheers
<jbailey> Hey'all. =)
<seb128> hello jbailey 
<Kamion> daniels: you need to look at both the dvorak and mac-usb-dvorak keymaps, probably
<sivang> seb128: hi :)
<elmo> daniels: and btw, -f doesn't work with apache2ctl, at leasst not for configtest
<daniels> elmo: wack
<daniels> Kamion: ok, thanks
<fabbione> Kamion: thanks for silo-installer
<elmo> dear god
<elmo> apache2's init script uses pidof, you evil evil evil people
<Kamion> fabbione: np
<elmo> "lala, kill apache2 any apache2, absolutely anything that has the name apache2, who cares if it's mine??"
<Mithrandir> elmo: p4tch3z accepted.
<jbailey> elmo: You have to admit, that thought it tempting sometimes. =)
<ajmitch> morning jbailey :)
<infinity> elmo : Blame thom.
<elmo> infinity: that's my default state
<infinity> elmo : Alternately, blame me, if you want it fixed.  But I didn't write it.
<daniels> I didn't write it, either.
<infinity> elmo : The last bit is the only thing that needs to go.
<infinity> elmo : Initially, it compares pidof against the pid file, and then tries to kill if they match (which seems sane)... The last bit where it gives up and says "fuck it, just kill em all" is decidedly less safe looknig.
<infinity> elmo : Shall I queue that up for my apache2 upload this week?
* infinity wonders if it's saner in that instance to exit with an error, or just silently do nothing...
<elmo> infinity: it'd be nice, IMO, no particular urgency
<elmo> I'm never sure about that, daemons exiting with non-zero status are right up there in the "top 5 ways to sideways screw a buildd", but OTOH, it's clearly the right thing todo, esp. if you have a sane-by-default config and it won't error out simply because no apache ever actually started
<infinity> If there's no apache running, but it's properly configured, it won't error out.
<infinity> If there's none running and it's broken, that's where problems come in.
<infinity> I'm undecided on the proper outcome.
<infinity> I could exit 0, but echo a warning... A half compromise.
<pitti> Hi ogra
<infinity> "There were [n]  processes running named 'apache2', however none were killed, as they didn't match your PID file, you may want to examine this situation manually.", or some such.
<ogra> hi pitti
<infinity> elmo : Does something evilly verbose like that (with an exit 0, to not fuck buildds) seem a reasonable compromise?
<jbailey> fabbione: There?
<fabbione> jbailey: yup
<Kamion> mdz: today's ISO works with no questions in the second stage
<jbailey> fabbione: Can you shed some light on why this patch: http://marc.theaimsgroup.com/?l=acpi4linux&m=107448387831707&w=2 wouldn't have made it into the kernel?  It seems so clearly like the right thing for early userspace ACPI work.
<fabbione> humpf.. new inotify patch breaks the abi
<elmo> infinity: does to me
<Kamion> mdz: the chief remaining bug is that there's an enormous delay after the apt configuration question when nothing's displayed while it downloads Packages files to test the new sources.list; I need to add a progress bar there somehow
<fabbione> jbailey: reading...
<infinity> elmo : Alright.  Consider it done.
<fabbione> jbailey: i dunno.. the best person to ask is mjg59 
<jbailey> fabbione: Cool, thanks.  
<fabbione> we need to get some 4cp1 love anyway
<fabbione> 2.6.10 isn't the state of the art
<jbailey> Dude, 2.6.10 is the suck. =(  2.6.9 worked wondefully on my laptop, 2.6.10 can't tell that I have a battery or an AC adapter.
<fabbione> jbailey: patches are welcome :)
* fabbione hands https://www.ubuntulinux.org/community/teams/kernel to jbailey :)
<jbailey> fabbione: Of course. =)  I only discovered it a week ago when I bumped my laptop to 2.6.10.  I've been working my way through the ,9 -< ,10 changelog to understand where to look but the bloody thing is *long* =)
<fabbione> jbailey: not only.. we have a few tons of patches in our tree
<fabbione> including a big acpi update
<elmo> meh, I can't  use apache2ctl with -f for reload either. I'll have to clone a apache2-svnctl or something
<Kamion> has anyone got any further with that udev-forkbomb problem?
<Kamion> or whatever it is that's causing the desktop to be unusable for a minute or so after logging in at a fresh installation
<Treenaks> Kamion: is that the same problem as the "load but nothing's running" hal upgrade bug?
<Kamion> dunno, seems to have appeared around the same time
<pitti> Treenaks, Kamion: that's the very same bug, yes
<pitti> I started to track it yesterday
<pitti> but now security work came in between...
<pitti> however, I'm a bit lost with this issue :-(
<Kamion> anything I can do to help?
<Kamion> (bearing in mind that I know nothing about it ...)
<pitti> I already have a proper strace and a debug syslog output
<fabbione> jdub: ping
<pitti> Kamion: " know nothing about it" -> welcome to the club :-)
<Kamion> can you put the strace/syslog somewhere public?
<pitti> Kamion: http://people.ubuntu.com/~pitti/syslog.gz
<infinity> elmo : apache2ctl doesn't do much more than "apache2 -k $1" anyway, so there's not much harm in just calling the binary directly, if you want -f
<tseng> grr hey can someone help fix my brainfart from last night?
<tseng> i made tomboy build-dep on libpanel and not -dev
<Kamion> pitti: I assume that's with extra debug in udev; I'm not seeing stuff like that here
<pitti> Kamion: right, I compiled a debugging and logging enabled version
<pitti> Kamion: however, I ran that one on smurfix' machine
<pitti> Kamion: I just can't reproduce the bug on my machine
<pitti> Kamion: I tried to up-, down-, sidegrade a dozen of times
<pitti> Kamion: however, I don't think that this is a hal bug
<pitti> I think the hal upgrade (daemon restart) merely triggers some hotplug situation which causes udev to go mad
<sivang> pitti: I am usually reastarting all of my session after a hal upgrade...doesn't work otherwise.
<pitti> sivang: why, usually a hal upgrade should work immediately
<pitti> sivang: g-v-m should automatically restart
<sivang> pitti: never worked for me, the best I could get is killing all nautilus isntances and let them restart.
<pitti> sivang: and with this bug, restarting the session is not enough anyway
<sivang> hmm, I'll upgrade, see the fun myself :)
<sivang> I hope this is not arch specific
<pitti> sivang: no, this is moonphase specific
<sivang> hehe
<mjg59> jbailey: Around?
<jbailey> mjg59: Yup!
<Mitario> hey everyone
<jbailey> mjg59: Are you asking me a new question, or responding to my conversation with Fabio? =)
<Keybuk> meh, why the hell isn't evo threading properly anymore :-/
<mvo_> hi Mitario 
* Keybuk blames seb128 
<mjg59> jbailey: Fabio-related stuff
<fabbione> mjg59: hey
<mjg59> Can you stick up a 2.6.10 dmesg and contents of /var/log/dmesg somewhere?
<mjg59> It's an ACPI interpreter regression in 2.6.10, which I /thought/ we had fixed but it seems we don't
<fabbione> mjg59: there was a huge acpi commit in bk recently... anything that you should push me?
<seb128> Keybuk: have you updated to eds 1.1.4.2 ?
<fabbione> it was mentioning something about a regression fix
<Keybuk>   Installed: 1.1.4.2-0ubuntu1
<seb128> what's wrong ?
<Keybuk> they thread, but only up to the third level
<mjg59> fabbione: The regression fix stuff was what I pushed you last time
<thom> hrm, forkbombing oneself with acpid is probably careless
<fabbione> mjg59: ah ok
<mjg59> But I'll try with the full patch
<Keybuk> and anything deeper just gets attached there
<Keybuk> so you see:
<Keybuk> message 1
<Keybuk>   message 2
<Keybuk>     message 3
<Keybuk>     message 4
<Keybuk>     message 5
<seb128> previous version had a bug because they sorted with In-Reply-To to not get the full headers, but that should be fixed now
<seb128> hum
<seb128> lemme check
<jbailey> mjg59: Great.  Send to which address?  
<mjg59> jbailey: mjg59@codon.org.uk
<thom> mjg59: 6026 is fixed, just gonna upload now
<jbailey> mjg59: Note that dmesg is only full of "Method execution failed" bits.  The boot stuff has fallen out of the ring buffer by now.  I can reboot and capture it, though.
<mjg59> jbailey: That's /var/log/dmesg
<mjg59> (pretty much)
<jbailey> mjg59: In vaguely related news, I've been looking at this patch http://marc.theaimsgroup.com/?l=acpi4linux&m=108973961928358&w=2 for a while, and trying to figure out why it didn't get noticed.  It seems like the obvious right thing to do with early userspace booting.
<mjg59> Intel will never accept it
<seb128> Keybuk: yep, correct, that's broken here too. But at least they are in the threads :p (some days ago it was not even regrouping threads correctly)
<Treenaks> mjg59: they should accept it, or beat BIOS writers into writing proper DSDTs
<mjg59> Treenaks: They say they prefer the latter, but don't seem to be doing anything
<Keybuk> seb128: want a Bugzilla bug for it?
<mjg59> thom: Rock
<seb128> Keybuk: no, that's fine, I'm opening a bug in bugzilla.ximian.com right now
<Keybuk> ok
<thom> mjg59: /var/lock/acpid is the lock file, FYI
<jbailey> mjg59: Would we consider pulling that patch in?  It would be really nice to open this up a little more sanely than just gluing the DSDT file to the end of the initrd.
<Keybuk> thanks dude
<jbailey> mjg59: (I can test and all that first, obviously)
<mjg59> jbailey: It'd need refactoring to work with the current kernel, but I've no real objection to using it instead (assuming it works)
<jbailey> mjg59: Lovely, I'll bring it current and post to bugzilla.
<mjg59> As long as initrd-tools gains sensible support
<fwiffo> mjg59, jbailey, is the problem you are discussing not the same as bug #5861?
<jbailey> fwiffo: I'm getting AE_AML_NO_OPERAND errors, but different methods.  I don't know enough about ACPIs guts to know if that makes it the same error or not.
<mjg59> fwiffo: Likely to be
<fwiffo> jbailey, ok, me neither :)
<Mithrandir> lamont: any ia64 boxes dropping out of the bushes yesterday?
<jbailey> lamont: Do you need access to one?
<jbailey> err.. Mithrandir ^^
<lamont> Mithrandir: the bushes were hiding yesterday...
<Mithrandir> jbailey: at some point, it'd be nice to have one for multiarch, yes.
<zul> hi everyone
<jbailey> Mithrandir: Mine builds the d-i nightlies, so it runs Debian atm, but there's lots of HD space for chroot's and such.
<Mithrandir> jbailey: I'll get this working on i386 and amd64 first, but I'll give you a shout.
<jbailey> Mithrandir: 'k
<fabbione> hey zul
<zul> fabbione: how is it going?
<Keybuk> hmm, worring
<Keybuk> the drop-down on MSN search was my most recent google searches
<fabbione> zul: better than usual
<zul> good
<daniels>               observe "not updating $SERVER_SYMLINK; it is a symbolic" \
<daniels>                       "link to a directory"
<daniels> why the fuck would anyone ever do that?
<doko> mvo_: ping
<mvo_> doko: pong
* fabbione is melting....
<fabbione> ok guys.. we need ACPI and USB fixes... possibly some alsa stuff
<fabbione> the new inotify patch breaks the ABI so we have full freedom
<fabbione> suggestions?
<pitti> powerpc sleep
* pitti ducks
<pitti> just kidding
<pitti> argh
* pinhead inflics some serious pain to pitti
* pitti runs
<daniels> try the patch to rewrite the kernel in C++
<daniels> i hear it's really cool
<pitti> no, in python
<daniels> also, I have some vm rewrite from a guy on the gentoo forums
<daniels> speeds things up a hojillion per cent
* pinhead sticks violently pain dameons in pitti's head
<Kamion>   * Add progress bar support and corresponding templates to apt-setup.
<fabbione> daniels: same as i am getting 31337 FPS with glxgear?
<Kamion> MMM, EVIL
* pitti 's poor iBook continues to sing "Insomnia - I can't get no sleep!"
<daniels> fabbione: heheh :)
<ogra> fabbione: whats so special about that ?
<ogra>  glxgears
<ogra> 37489 frames in 5.0 seconds = 7497.800 FPS
<ogra> 90911 frames in 5.0 seconds = 18182.199 FPS
<ogra> 93257 frames in 5.0 seconds = 18651.400 FPS
<ogra> 90150 frames in 5.0 seconds = 18030.000 FPS
<fabbione> ogra: the number ;)
<ogra> ah...leetspeak...
<ogra> i thought the value....
<Kamion> ogra: plus daniels hurts people who benchmark using glxgears
<ogra> hehe
<zul> daniels, it should be re-written in cobol
<ogra> Kamion: in fact the above is glxgears at 24x24 ;)
<daniels> GLXGEARSISNOTABENCHMARK
<fabbione> 37645 frames in 5.0 seconds = 7529.000 FPS
<mvo_> 1482 frames in 5.0 seconds = 296.400 FPS
<fabbione> mvo_: time to change gfx?
<mvo_> fabbione: probably :)
<fabbione> mvo_: with a better gfx synaptic will run faster
<ogra>  lol
<mvo_> even faster than it is now ;) ?
<fabbione> no more need to sleep while waiting for the GUI to refresh on your miserable 300 fps
<fabbione> :P
* mvo_ thinks daniels is to blame 
<fabbione> doko: ping?
<fabbione> pitti: benh didn't release anything new
<pitti> Hi sabdfl
<fabbione> so no ibook "go and get a nap" patch
<pitti> :-(
<sabdfl> hiya pitti
<fabbione> and soon it will be the end of inotify
<fabbione> upstream didn't respond either to Jeff or me 
<daniels> yo sabdfl
<sabdfl> hi
<jbailey> fabbione: me?
<fabbione> mjg59: do you happen to know if ACPI in 2.6.11-rc2 is safe or is it still buggy?
<fabbione> jbailey: sorry.. Jeff as in jdub
<fabbione> hey sabdfl 
<jbailey> fabbione: No prob.  Just triggered the nick highlight. =)
<fabbione> ehhe
<fabbione> jbailey: do you like USB?
<ajmitch> morning sabdfl 
<jbailey> fabbione: Are you asking me if we should get rid of it, or do I use it?  (No, and yes respectively, btw.. *g*)
<fabbione> jbailey: would you like to maintain it inside the kernel?
<fabbione> (as a subsystem?)
* fabbione feels the earth shaking under jbaley's feet
<jbailey> fabbione: Errr....
<ajmitch> jbailey: you could always just run :)
<jbailey> fabbione: Is this one of those game shows when my x-girlfriend for 15 years ago shows up with 4 kids that I didn't know were mine and a DNA test in hand?
<zul> heh could be
<thully> hi - I MAY have a possible fix to the whole autohinter issue (a way to restrict it to big fonts)
<fabbione> jbailey: kinda :-)
<Kamion> thully: could you post that to ubuntu-devel@? waiting for somebody appropriate to be around on IRC isn't so ideal ...
<Kamion> (I'm not sure who is appropriate, even)
<doko> fabbione: pong
* Kamion goes to test apt-setup changes
<thully> It's up on bugzilla
<Kamion> ah, ok
<fabbione> doko: does the last change to libc6 affect also gcc != 4.0?
<jbailey> fabbione: I'm not sure that I have the skills, but I have a non-zero interest in learning them.  I've usually stayed on this side of the kernel-userspace iron curtain.
<thully> also, I found a newer version of the trackpoint driver which may fix the issues that forced it to be removed - and adds scroll support
<fabbione> thully: it is the same patch you already posted and that i marked as wONTFIX
<daniels> thully: dude, I read the mail about autohinter, it's on my TODO
<fabbione> reopening the bug on regular intervals doesn't make my decision change
<doko> fabbione: no, gcc-4.0 became more strict (fixes an accepts-illegal bug)
<fabbione> doko: ok.. thanks
<fabbione> jbailey: up to you... it would be nice to get someone to love USB
<thully> I reopened it because there is a new version as of 2 days ago
<jbailey> fabbione: Lemme chew on the thought.  I'm not running out of tasks atm.
<jbailey> fabbione: But many of them are over soonish.
<thully> it's same address, but 4K bigger than the previous version (I don't really know C so I don't exactly understand the code that well)
<fabbione> thully: the patch can be 3MB bigger.. the problem is still the same
<fabbione> the 2 calls in psmouse.c
<fabbione> that can misdetect normal ps2 mices
<thully> did you look at the new version?
<fabbione> so the patch is no go for the inclusion
<fabbione> yes i did
<daniels> thully: fwiw, we have the same problem with ALPS
<thully> new as of Jan 30?
<fabbione> thully: yes i read my mails this morning
<fabbione> and checked the stuff
<thully> OK - will go re-close that now
<sabdfl> hi ajmitch
<fabbione> there is a new DRM big fat patch...
<Treenaks> fabbione: with VIA? :)))
<fabbione> http://www.skynet.ie/~airlied/patches/lk_drm/bk_drm_010204.patch
<fabbione> Treenaks: check it there :-)
<Treenaks> fabbione: 
<Treenaks> fabbione: "via" -> not found :(
<Treenaks> fabbione: (oh well, it's security-holey anyway)
<fabbione> ehh
<thully> how are the newest daily builds?  are the current hoary install/hoary live builds working decently?
<Kamion> EXT2-fs: hda10: couldn't mount because of unsupported optional features (4).
<Kamion> thully: current install CD works, haven't tried live
<Kamion> ^-- did somebody add a pile of ext2 patches? that's the result of trying to mount a freshly-created Ubuntu partition in Debian
<Treenaks> Kamion: nice
<azeem> Kamion: ext2 got modified between 2.6.9 and 2.6.10, yes
<azeem> dunno if it breaks backwards-compatibility, I just noticed it when I tried to apply another ext2-related patch
<Kamion> crap, that's inconvenient
<Kamion> that presumably also means that a warty installation cannot now mount a hoary ext3 installation
<zul> jbailey: are you in ontario?
<Kamion> oh, never mind; that feature flag is EXT3_FEATURE_COMPAT_HAS_JOURNAL. mount -t ext3 fixes it
<Kamion> I wonder why mount didn't spot that automatically though
<jbailey> zul: Yes, Toronto.
<zul> jbailey: cool im in ottawa
<dilinger> zul: *poke*
<jbailey> zul: Nice!  Perhaps I'll meet you next time I'm in town.  I'm going to try to get to GCC summit and OLS again this year.
<dilinger> zul: any luck w/ the config tool stuff?
<zul> dilinger: havent had time to this week been busy with work and having the flu
<zul> jbailey: cool its expensive though ;)
<jbailey> zul: Yeah, I know. =(
<dilinger> oh, that sucks.  well, get better
<zul> dilinger: trying to
<zul> dilinger: what about u?
<dilinger> oh, i hadn't intended to work on it just yet.  there are a few items higher up on my todo queue that i need to take care of
<zul> ah i cd
<zul> s/cd/c/
<mdz> morning
<Treenaks> hi mdz 
<sivang> mdz: mornig
<sivang> err, morning
<sabdfl> elmo: how big is an archive.ubuntu.com/ubuntu mirror now? want to update the web page
<sabdfl> also, is the list of mirrors on the web page complete?
<sabdfl> mdz: morning
<pitti> Hi mdz!
* smurfix waves in mdz's general direction
<aj> mdz: hello :)
<aj> mdz: so, we were just discussing apt-secure in sarge on #debian-release :)
<zul> morning
<mdz> aj: have you decided not to try to release this year? ;-)
<mdz> aj: how long do you think it would take to work out the mirroring issues?
<aj> mdz: eh, everytime i think of doing anything debian related i think how long it's taken for Release sigs to still not have gotten anywhere and don't bother...
<aj> mdz: didn't we already figure them out?
<aj> mdz: it'd take two days to make those changes if there was any point. (one day to implement, see what breaks; one day to fix)
<mdz> aj: I mean implementing them
<mdz> aj: I thought they required changes on the remote ends
<aj> mdz: eh, not necessarily
<Kamion> mdz: oh, there'll be an issue with sending the X_SAVE command via passthrough - the debconf confmodule rejects commands it doesn't understand
<thully> hi - does anyone know what the best live cd/install builds are - the current live cd is broken (2/1 hoary) and I think the install cd may be also
<Kamion> how so?
<Kamion> I did an install with the current install CD earlier today
<Kamion> (successfully)
<lamont> haggai: you about?
<haggai> lamont: yes
<mjg59> fabbione: No idea
<Kamion> thully: there's an issue with udev after the install; it seems to be somewhat hardware-dependent and for me it only makes things slow for a minute or so after the install. pitti's been working on it a bit, but nobody knows the exact cause yet
<lamont> haggai: oo.o build-depends: libneon23-dev... how hard would it be to make that libneon24-dev???
<mjg59> fabbione: Current 2.6.10 packages work fine on my hardware, so I'm having trouble working out what's broken
<Kamion> I'm intending to block Array CD 4 on that issue, so ...
<pitti> Kamion: my problem is that I can't reproduce it at all
<fabbione> mjg59: ok
<haggai> lamont: quite hard.  It's been done for oo2
<mjg59> fabbione: This evening is being spent on fixing T-series power draw in ACPI, I'll move on to the general stuff tomorrow
* lamont updates his laptop to try and reproduce the udev thang
<lamont> haggai: ok
<haggai> lamont: but needed several upstream changes.  rene already discussed it and decided to stick with 23 for 11
<haggai> neon 23 for 1.1
<ogra> Treenaks ?
<thully_> just lost my connection - which live CD build is best?
<Kamion> thully: there's an issue with udev after the install; it seems to be somewhat hardware-dependent and for me it only makes things slow for a minute or so after the install. pitti's been working on it a bit, but nobody knows the exact cause yet
<Kamion> thully: if that's the breakage you're referring to; you didn't elaborate when I asked
<thully_> Ok - I lost my connection
<Kamion> array-3.5-live is stable, although there's localisation breakage; array 4 is the next milestone and will be tomorrow + whenever the udev bug gets squashed
<thully_> will array 4 for install be out too?
<Kamion> thully: the intent is to release them simultaneously from now on
<lamont> thully: live and install arrays release together.
<lamont> execpt that live-3.5 was kinda really late... :-)
<thully_> there was no install-3.5
<thully> ok - leaving now...
<dholbach> re
<tseng> hi dholbach 
<mdz> tseng: /join #ubuntu-meeting if you're around
<mdz> dholbach: and you as well
<thom> hey, if i boot an smp kernel on ppc , i get two penguins
<thom> score
<Kamion> thom: symmetric multi-penguins
<thom> *g*
<thom> Kamion: oh, www.clearairturbulence.org/d-i.tgz  is the logs and so on for that g4 that you asked for
<elmo> thom: a2enmod could do with some variabalizing
<elmo> i.e. so I can just change the /etc/apache2/ dir in one place
<infinity> thom : It could do with a lot of stuff.
<thom> elmo: it needs to be thrown out and jumped up and down on, but yes
<infinity> s/thom/elmo/
<infinity> elmo : I can, however, fix that one small issue on the next upload.
<thom> i need to finiosh the python version
<infinity> Replacing it completely sounds better.
<elmo> yeah, I'm just whining about the small things as I continue my two-apache server adventure
<infinity> thom : No debconf version, a la apache-modconf?
<infinity> elmo : Feel free to put every whine/bitch in an email to me.
<thom> infinity: it'll use debconf for the front end
<thom> infinity: i'm more interested in doing dependency tracking and so on for hte moment
<infinity> elmo : I may as well polish stuff up as best as can be done for Sarge/Hoary, before we scrap it all and start over. :)
<infinity> thom : Dependency tracking is much needed, yes.  We have a few open bugs relating to it.
<thom> yeah
<thom> it mostly works, too
<infinity> Spiff.
<infinity> How are you declaring deps?  Parsed comments in foo.load, or an info file, or something?
<elmo> infinity: uh, scrap it?
<infinity> elmo : Well, scrap bits of it. :)
<infinity> elmo : Like a2enmod.
<thom> scrap the code, keep the name ;-)
<elmo> oh
<infinity> <nod>
<elmo> I thought you meant apache3 or something ;P
<infinity> Oh.
<infinity> No. :)
<thom> infinity: for the minute, command line arguments, because it's easier to test ;-)
<infinity> thom : Ahh.  How do you envision the final product?
<infinity> thom : info files in /usr/lib/apache2/modules would work.  As would comments in .load...
<infinity> I'm undecided as to which is less intuitive for people doing by-hand module installs.
<thom> i'm leaning towards the latter, tbh
<infinity> Works for me.
<thom> it seems more likely that people will think of those (to me anyway)
<infinity> <nod>
<infinity> People are more likely to read other .load files as examples than go digging in /usr/lib
<thom> also, we can document in readme.etc and readme.debian, and hope that people bother reading either
<thom> yeah, that's what i though
<infinity> People read?
<thom> infinity: some do
<infinity> I'd like to meet these people.
<infinity> And shake their hands.
<infinity> All three of them.
<thom> infinity: they're not php users, mind ;-)
<infinity> (three people, not people with three hands)
<seb128> daniels: around ?
<infinity> seb128 : He claimed he was going to bed a coulpe of hours ago.
<seb128> k
<seb128> thanks
<infinity> I wonder if there's a way to unlearn Manoj's typing skills.
<infinity> I've been getting worse lately.
<thom> infinity: you're approaching raster's "skill" level
<infinity> Say it ain't so.
<infinity> Anyhow, after I kick off yet another GCC build, I'm heading to bed.
<infinity> thom : I wouldn't mind having a gander at this fabled a2enmod v2 sometime.
<thom> 'night
<thom> infinity: it's in the source package
<thom> for apache2
<infinity> ...
<infinity> Hiding, I presume? :)
<thom> infinity: debian/a2-scripts
<tseng> mdz: im off for lunch if im no longer needed, ill read the log later. thanks
<thom> modhandler.py and u-a-m
<infinity> Oh, u-a-m.
<infinity> Right.
<infinity> Silly me.
<infinity> thom : Any work on it since then?
<infinity> thom : If not, I'll just read that.
<thom> no, that's the latest code
<thom> it's nigh on a year stale, unfortunately
<infinity> Tastes better that way anyway.
<infinity> Fresh code is too chewy.
<thom> heh
<infinity> I'll look at it later.
<infinity> 'Night.
<thom> cool
<Mitario> heyha
<mdz> daniels: ping?
<infinity> mdz : He's asleep.  It's 3:30am.  I'm asleep too, this is just my daniels responder bot.
* mvo_ goes and plays some hockey
<dholbach> mvo_: have fun :-)
<zul> mako: where is the copy of the coc?
<dholbach> zul: http://www.grawert.net/CoC.txt (courtesy by ogra ;-))
<zul> thanks dholbach 
<T-None> http://www.ubuntulinux.org/community/conduct
<T-None> a convenient way to sign & mail it can be: lynx -dump http://www.ubuntulinux.org/community/conduct | gpg --clearsign | mail 
* T-None is off now
<zul> thanks t-none
<mako> zul: on the website
<zul> yeo got it thanks mako
* marioch is away: I'm busy
<thom> mjg59: dude?
<tseng> hi all.
<dholbach> hello tseng
<tseng> how does one go about "signing" the CoC?
<dholbach> tseng: gpg --sign CoC.txt (from http://www.grawert.net/CoC.txt)
<dholbach> dholbach: or fax it to mako :-)
<mdz> mako: isn't there a text version that you provide for signing?
<zul> heh i still live in the stone age...
<tseng> dholbach: and where shall I send CoC.txt.gpg
<smurfix> tseng: mako@canonical.com
<tseng> works for me.
<tseng> and off it goes
<tseng> also, is it required to work in a debootstrap chroot? its documented on the motu page, without much reasoning
<Kamion> no, as long as you know what you're doing and are careful
<thom> tseng: it happens to be a very good way of checking build-deps
<tseng> thom: ah, right
<thom> but no, not required. just makes life much easier
* tseng points at his tomboy mis-dep =/
<Kamion> you can build source packages pretty much wherever you like; it only matters for testing
<thom> tseng: sbuild or pbuilder are both useful ways of automating the process; 
<tseng> thanks dudes.
<mako> tseng: you have no signatures on your key?
<tseng> no, its new =/
<mako> tseng: do you have an old key?
<tseng> no.
<mako> where do you live?
<tseng> central pennsylvania
<mako> whats the town?
<tseng> York.
<fabbione> YEAH
<fabbione> http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/0.18/inotify-0.18-rml-2.6.10-13.patch
<seb128> thom: please fix #6007, that's really annoying
<fabbione> with our sparc64 support
<fabbione> :)
<thom> seb128:RESOLVED/WORKSFORME
<thom> :P
<seb128> hannnn
<thom> seb128: it's actually font dependent, it seems
<seb128> seriously, every time I'm in bugzilla I need to click to change a comment
<seb128> the cursor jump all around the place with the keyboard
<thom> seb128: but i know where the problem is, i'll try to get to it soonish
<seb128> oh ok
<seb128> that's due some firefox changed in the new uploads ?
<seb128> it was not doing it before
<thom> yeah, it's pango
<thom> IT'S A GTK+ BUG!
<seb128> ah ah
* thom grins and goes to get food
<tseng> mako: im speaking at a conf with russel coker and todd troxell, could probably get signage, but thats a month away
<tseng> mako: have another way to verify out of band?
<smurfix> tseng: Can you check biglumber if there's somebody you can get to?
<tseng> a few in harrisburg
<smurfix> tseng: That should work -- the "normal" out-of-band method is to get a copy of your ID notarized or something, and we don't really hav a procedure for that yet.
<tseng> ok.
<sabdfl> tseng: where are you based?
<tseng> York, PA
<mako> sabdfl: all yours at https://www.ubuntulinux.org/wiki/NewMembersMaintainersDraft 
<sabdfl> mako: thanks
<mako> where is jblack again?
<sabdfl> tseng: are you trying to figure out the web of trust issues?
<mako> PA is not so small.. 
<tseng> sabdfl: yes.
<mako> tseng: any of the people in harrisburg would work i suspect
<sabdfl> are there any notaries public close by?
<mako> sabdfl: should be at any bank
<mako> and usually your own bank will do it for free
<sabdfl> or CPA
<mako> lawfirm, etc
<tseng> there is a notary nearby.
<tseng> much closer than h-burg
<sabdfl> tseng: if you can get a notarised statement of your ID to me i'll sign your key
* T-Bone waves around
<sabdfl> key T-Bone
<sabdfl> hey even
<T-Bone> hey sabdfl! Long time no see ;)
<sabdfl> mako: did you see the draft i had sent to the launchpad team previously?
<mako> sabdfl: gpg on the mind :)
<sabdfl> T-Bone: are you officially a sailor?
<T-Bone> sabdfl: well no, otherwise I'd be ditching corpse in Indonesia right now ;P
<mako> sabdfl: i did see it.. although i had forgotten about it
<T-Bone> sabdfl: quite a lot of thing happened to me last December, hence the blackout on my side
<T-Bone> +s
<sabdfl> T-Bone: are you back?
<T-Bone> i'm front ;)
<Kamion> hmph, FAT filesystem autodetection is a nightmare. yay for no sensible magic numbers whatsoever
<mako> sabdfl: ok.. almost all of that go in there although the organization is little bit different
<T-Bone> sabdfl: roughly put, I'm doing my internship in .fr eventually, and I'm hacking ia64 Ubuntu on my spare time. So far we're getting very close to have a fully fonctionnal installer for hoary
<mako> sabdfl: ergh.. almost all of it got in there
<sabdfl> Kamion: you can't search for "this is patented technology.."?
<mako> sabdfl: the major difference is that i dropped committer
<Kamion> haha
<sabdfl> mako: any substantial differences? i would like just one canonical version :-)
<T-Bone> Kamion: i'll get back to you pretty soon btw ;)
<sabdfl> mako: dropped it?
<mako> sabdfl: well, i took it out of the proposed current published version because we don't have the infrastructure to support it yet
<mdz> sabdfl: more like "didn't document it fully because it doesn't actually exist, and the implementation will probably influence the process"
<sabdfl> T-Bone: ok cool, glad to hear you are on it
<sabdfl> ok
<sabdfl> WHUI
<mako> sabdfl: we have maintainers (which are uploaders in your draft) and that's it
<T-Bone> sabdfl: well, the bootloader installation is the last remaining issue, so that's not much indeed ;)
<sabdfl> ok
<mako> sabdfl: i figured adding committers when we could support them would make more sense.. ther's no sense is approving people to be a committer when that's not somethignw e can support
<sabdfl> and until we have a revision control system, committers are meaningless
<sabdfl> ok
<mako> exactly
<sabdfl> 356 people in #ubuntu
<Kamion> as far as I can tell the best you can do is check for 0x55 0xAA at the end of the DOS boot sector, and then go through and audit every bleeding fields
<mako> so it's excised permently, it's still on the main wiki page
<Kamion> s/s$//
<mako> sabdfl: it's still documented in the main wiki page but the Official Document we can keep up to date
<mako> sabdfl: there are a few minor things that are in your draft things like planet, etc.. i can go through and compare if you'd like and try to move things in
<T-Bone> Kamion: would there be some way to link mptscsih's load with mptbase's one in hotplug? ie: "load mptscsih when loading mptbase" ?
<mako> sabdfl: the current draft doesn't quantify a minimum letter of recommendations/letters of endorsement for members but i suspect that the CC would be happy with that change
<sabdfl> mako: let me have a once-over, then yes, please merge in new ideas from that draft
<sabdfl> mako: i think we want to introduce the letters of support once we have grown a bit
<mako> elmo requested we "beef up the importantance of testimonals"
<sabdfl> we need to keep the process lightweight but grow on the basis of known-quantity-quality
<mako> at the moment, it just says that they're extremely helpful
* mako nods
<sabdfl> once we have a stable core group, we formalise the process a lot more
<sabdfl> i guess mdz wants the doc to reflect *current* policy
* mako nods
<sabdfl> but it would be useful to have a doc which outlines intended stable-state policy
<mako> ok.. well in your draft, there is a requirement for a signed/faxed letter from ubuntites.. in mine, it says anyone can do it
<sabdfl> elmo: i understand the importance of testimonials, right now we should be fast-tracking folks who we *personally know* are good
<sabdfl> or who have demonstrated real skill
<mdz> I just want to have a step-by-step doc that people can look at and see what they truly need to do, today, to get involved
<sabdfl> once the group is bigger we'll need that more rigorous process
<elmo> sabdfl: no objection to that - I was saying testimonials are going to be an important part of scaling the process up
<mdz> which I think mako's doc does
<elmo> or was trying to say
<sabdfl> elmo: agreed
<tseng> sabdfl: sorry to be a pain, do you have an idea how this is going to work?
<tseng> i go to the notary, present proof of ID, and they will fax you something possibly?
<sabdfl> tseng: take a copy of the code of conduct, and sign it in front of them
<sabdfl> i think they will notarise that signature as coming from you
* T-Bone is trying to catchup with backlog to figure out what it's all about, wishes there was a "split window" option to xchat ;)
<sabdfl> in addition, include on that paperwork your GPG key id
<sabdfl> have them notarise that specifically
<sabdfl> i'm not sure of the language, draft something up together with your friendly notary
<sabdfl> it needs to contain:
<sabdfl>  - the CoC
<sabdfl>  - your full name
<sabdfl>  - your GPG id
<sabdfl> then send me that original thing, i can sign your key, and i think we are all set
<sabdfl> this is just to bootstrap you into the keyring
<sabdfl> elmo might have some additional suggestions after his palpitations settle down
<tseng> heh.. this will be snail mail then?
<sabdfl> tseng: yes, to london should be quick though
<smurfix> tseng: yep. Notarys' seals don't fax very well. :-/
* tseng nods
<tseng> ill type this up quick and maybe it can be a draft for future folks
<tseng> that run into this problem.
<mako> sabdfl: want to go through the rest of the differences?
<YokoZar> I'm getting this error when building my package (the .deb file is still there, and works, but it doesn't let me enter my key): dh_clean: I have no package to build
<sabdfl> mako: i'm picking my way through this slowly, will ping you when i'm done
<YokoZar> make: *** [install-arch]  Error 1
<mako> sabdfl: cool
<dholbach> YokoZar: what does your  debian/control  look like? can you put it somewhere on the web?
<YokoZar> dholbach: deb-src http://tuzakey.com/~scott/apt source/
<YokoZar> package winetools
<YokoZar> dholbach: find it?
<dholbach> YokoZar: try   Section: otherosfs   and   Architecture: any   (in  debian/control )
<sabdfl> mako: am using the terminology "confirm... nominations"
<dholbach> YokoZar: there's no  contrib/...  here
<YokoZar> oh heh
<tseng> sabdfl: i have pasted the CoC into oowriter
<tseng> sabdfl: and at the end of the doc, i have :
<tseng> This document verifies that the following public key belongs to Brandon Hale.
<tseng> pub  1024D/D0DC9743 2005-01-27 Brandon Hale <brandon@smarterits.com>
<tseng>      Key fingerprint = 29A6 C717 110B 1F37 4E60  2F4A 8A5A 6772 D0DC 9743
<YokoZar> dholbach: architecture: any in the package desc or at the top?
<dholbach> YokoZar: and you don't have any  Makefile ?
<YokoZar> dholbach: gives the same error by the way
<tseng> just to be totally clear, sign it just below this, have it notarized, and mail to you
<YokoZar> Nope, the package is just a bunch of scripts
<sabdfl> tseng: yes, as long as the doc includes the things I described, this should be absolutely fine
<YokoZar> I guess I could just try moving everything into install-indep, since it really isn't an arch package.
<tseng> sabdfl: wonderful, ill have it done and will catch up with you about mailing later. thanks for your help
<T-Bone> Kamion: ping?
<YokoZar> dholbach: Still with me?
<sabdfl> mako: it says maintainers must be confirmed by both CC and TB
<sabdfl> this means that a person would have to go:
<sabdfl>  - CC for member
<sabdfl>   - TB for maintainer
<sabdfl>   - CC for maintainer
<sabdfl> which seems silly to me
<mako> sabdfl: i argued against that
<dholbach> YokoZar: yes - lets move to a query
<mako> sabdfl: but elmo felt strongly about it
<sabdfl> i thought the member (cc) and maintainer (tb) approach was simpler
<sabdfl> ok
<mako> sabdfl: that was in the original draft at the beginning of the meeting
<sabdfl> cc - tb - elmo :-)
<mako> sabdfl: if you're unconvinced, you might want to look over taht part of the log
<sabdfl> i understand elmo's reservations
<mako> the basic argument was that (a) elmo doesn't want to a vote for membership to translate into a vote maintainership
<sabdfl> my view is that the tb should not approve a maintainer they are not certain about
<mako> and (b) there aren't enough people on the tb that have day-to-day working in the distribution
<sabdfl> but... they can look to the references / testimonials
<sabdfl> and ask their own questions
<sabdfl> and look at packages
<mako> i'm not really the person you need to convince here
<sabdfl> right
<mako> i'd be happy to relax that
<mako> at the moment, we can clarify that it's for uploaders to main
<mako> the argument in favor is, yes it's silly and annoying but we are talking about the ability to upload any package into ubuntu
<mako> and if there's any place to be silly and annoying its here
<sabdfl> true
<sabdfl> it works ok if we have the tb and cc both at a meeting
<sabdfl> and it can all be done right there
<mako> i suspect in most cases, taht will happen
<sabdfl> i guess it would work ok if we had a launchpad process that made this less irc-awkward too
<mako> at least with our current schedule
<mako> the chance of kamion, elmo and myself being on during a mid-day tb meeting on tuesday is extremely high
<mako> and matt, who is really the only tb member who is in an awkward timezone, has been super about making the cc meetings
<sabdfl> nonetheless, it seems awkward to me
<sabdfl> if we need to grow the tb, we should do so, so they can handle the decision w.r.t. maintainers
<sabdfl> they are of course welcome to ask people their opinions
<sabdfl> so i imagine they would ask elmo et al whether they are confident in the candidate
<sabdfl> cc - tb - cc seems too bureaucratic to me
<sabdfl> i'll raise this again at the next cc meeting
<sabdfl> mako: done, go ahead
<sabdfl> would you not like to restructure that document?
<sabdfl> perhaps pull out the process docs as separate pages?
<mako> sabdfl: sounds fine
<mako> sabdfl: that's how it used to be
<mako> sabdfl: mdz suggested it be on in one page
<sabdfl> anyhow, in substance i'm happy, with the expressed reservation about the return-to-cc process
<mako> sabdfl: we can bring it up again
<sabdfl> if you could add some of the nice stuff about planet etc in, as FUTURE sections, so people know where we are headed, that would be great
<mako> sabdfl: and appointing a bonus TB people or two may be a solution that makes elmo happy
<sabdfl> then please point cprov and salgado at the updated doc
<mako> sabdfl: one up on the wiki hierarchy is where that should go i suspect
<mako> let me look over the diff
<mako> sabdfl: looks great
<sabdfl> ok
<sabdfl> i think it could be clearer
<sabdfl> Membership
<sabdfl> MembershipProcess
<sabdfl> Maintainership
<sabdfl> MaintainershipProcess
<sabdfl> Canonical
<sabdfl> SupaPreHoary
<mako> it used to have a link under membership to the membership process page
<mako> and same with maintainers
<sabdfl> lets keep them on one page but tighten up the text
<sabdfl> there is a bit of repetition
* mako nods
<mako> i can try to do a bit of reorganization today and then move it into the website
<sabdfl> thanks mako
<mako> i also need to send a message to the -users list irt to the reply-to
<mako> sabdfl: did you want to add anything about that?
<mako> sabdfl: you seemed to be inching toward suggesting that we should bounty reply-to for thunderbird
<sabdfl> mako: yes
<mako> which is the client we ship that is missing this
<mako> i think in any case, this is a good idea
<sabdfl> other than that, i think it's worth stating why we have the current approach
<mako> but matt argued that it (a) doesn't solve the current problem and (b) was skeptical it would really solve the problem with user
<mako> so the decision was to flip the switch for reply-to.. since the negative impact would be pretty minimal (looking at the number of people who use a real reply-to on users now)
<mako> just for users
<metalikop> quick question, I went to debian-devel for it, but they were little help.  what's the proper procedure for setting setuid bit on a file while making a .deb?
<sabdfl> i don't mind one way or another, i think the current config is more correct, given that the -users list is not a tightly bound community (it has WAY too much traffic for that)
<sabdfl> mako: reply-to-list
<sabdfl> for t-bird
<mako> sabdfl: but mdz experience, and mine as well, is tons of people replying to us offlist anyway :)
<mako> sabdfl: cool.. so if ok with that, i'll mention that too
<dholbach> wb ogra :-)
<sabdfl> that's because the current setting is to reply offlist, right?
<mako> sabdfl: i'm going to send an announcement to -users today
<mako> sabdfl: reply-to sender
<sabdfl> announcement?
<mako> sabdfl: yeah. just a message to users
<sabdfl> about the reply-to sender?
<mako> yeah, read the reply-to section here: http://people.ubuntulinux.org/~mako/cc-summary-20050125.html
<ogra> pitti ?
<mako> man.. how did my spellchecker not catch "joingly"
<sabdfl> mako: i like the idea of running a trial period with reply-to list
<sabdfl> did that get serious consideration?
<mako> sabdfl: that is what won
<mako> sabdfl: the trial starts today :)
<sabdfl> cool
<mako> i guess i didn't make the conclusion very explicit
<sabdfl> thanks for handling that
<mako> i'm gonna fix that summary
<mako> i also spelled jointly with a g
<sabdfl> Kamion: just reading the cc meeting summary, are you concerned that the tone or quality of -users or any other forum is deteriorating?
<mako> sabdfl: that thread got *nasty*
<mako> we want to avoid saying, "compare the admins to slavemasters and get what you want"
<crimsun> mako: have you received my signed CoC yet? (I sent it Tue, 25 Jan 2005 10:13:04 -0800)
<mako> crimsun: usually i reply when i recieve/check them.. let me look
<ogra> mako: you didnt reply mine....
<YokoZar> Ok when my package runs debian/rules binary and it gets to any of the debhelper commands it bugs out with "I have no package to build" - is this me missing some obvious declaration somewhere?
<mako> well, i replied to tseng on irc today instead of email..
<mako> ogra: but maybe not as usually as i thought ;)
<ogra> mako: heh, doesnt really matter.... i'm not a friend of buerocracy ;)
<mako> does that make me a buerocrat?
<ogra> lol
<mako> an ubuntocrat
<ogra> rather ... yes
<mako> crimsun: looks good and you're 4 hops away from me :)
<crimsun> mako: excellent, thanks muchly
<dholbach> mako: i think we just have one hop in between :-)
<mako> dholbach: mvo, yes
<YokoZar> What generates debian/files ?
<YokoZar> I know uupdate modifies it, but does something make it in the first place?
<ogra> YokoZar: http://www.nl.debian.org/doc/manuals/developers-reference/ap-tools.en.html#s-dh-make
<YokoZar> wait
<YokoZar> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianfiles
<YokoZar> debian/files should not exist?
<dholbach> YokoZar: "...it is used while building packages to record which files are being generated..."
<dholbach> YokoZar: so if your package doesn't build, it's still lying there
<YokoZar> The error I'm getting is that it isn't there when it comes time to make a .changes file (after I enter in my key the first time)
<dholbach> YokoZar: ogra is quite right to point you towards dh_make - it serves as a perfect start for a nice, clean package
<YokoZar> I used dh_make to make my package
<darklight> fabbione, ding
<Kamion> T-Bone: sorry, my clue is starting to run out when you get to modules auto-loading each other; you need a real kernel/hotplug expert
<T-Bone> Kamion: ok. Cause i've been talking to James Bottomley and Matthew Wilcox, they both agree that making mptscsih hotplug-friendly is everything but a trivial task
<maswan> mdz: thanks for being nice, even when I'm slightly frustrated after having butted my head against silly mistakes I made while recompiling a slightly patched kernel. :)
<Kamion> sabdfl: -users hasn't got as bad as debian-user, but I certainly can't deal with reading every thread on it any more; I strongly believe that we need the flexibility to be able to ban people who are being abusive or end discussions that have got out of hand
<Kamion> there aren't many discussions that got that far, but the reply-to flamewar did
<Kamion> T-Bone: ok, if it's a matter of special-casing it in hw-detect then we can do that in principle, but it *sucks* *really* *badly*; the only way to make the installed system guaranteeably behave the same way is to stick it in /etc/modules, and then you have drive ordering problems etc.
<Kamion> I'd almost advocate special-casing it in hotplug itself over that, but that probably sucks worse for other reasons :)
<Kamion> T-Bone: if there isn't a bug open, could you file one and cc mdz? I'd like his input
<T-Bone> Kamion: well, you _have_ to stick it in /etc/modules if you don't load it from initrd anyway
<Kamion> only if /usr's on the MPT disk and / isn't, or something
<Kamion> (assuming a hotplug-friendly mptscsih)
<T-Bone> Kamion: no you don't get it
<T-Bone> yeah but it seems mostly out of question right now
<T-Bone> the idea is that on MPT boxes, there is no (usually) other disks than those hooked to the Fusion bus
<Kamion> ok, well I want mdz's input before adding special cases really, but provisionally I don't mind hacking it in hw-detect
<T-Bone> Kamion: you'd have to ask jbailey i suppose, but it seems that Debian preloads MPT on the initrd, afaict
<Kamion> that's probably initrd-tools
<Kamion> which has sod-all to do with what the installer detects
<T-Bone> yup
<Kamion> does anyone here have an i386 CPU that supports NX? look in the "flags" line of /proc/cpuinfo to find out
<sivang> Kamion: not me, what does this flag mean?
<rcaskey_> sivang: mark memory regions as non-executable
<sivang> rcaskey_: ah ok, thanks, it is probably good to have, can I choose this when I buy my processor? ;-)
<Kamion> new systems have it, as I understand it; AMD defined it
<Kamion> don't know exact vintage though
<Kamion> I think all/nearly all amd64 systems have it
<lamont> Kamion: not here.
<sivang> Well, I'm tired, night everybody!
<HrdwrBoB> night
<tseng> bye sivang 
<sivang> tseng: bye , big congrets for today :)
<tseng> thanks.
<sivang> bye HrdwrBoB 
<dholbach> i'm tired too
<dholbach> have a good night everyone
<mdz> mako,sabdfl: everything ironed out with regard to the process docs?
<mdz> Kamion: what's the special-case in hw-detect?
<mako> mdz: i'm working on it now
<mako> mdz: it's getting good
<mvo__> good night dholbach 
<Kamion> mdz: T-Bone sent mail
<dholbach> bye mvo__ :-)
<mako> mdz: sabdfl went through it and suggested some reorganization.. but liked what we had
<mdz> mako: sabdfl is happy?
<mako> sabdfl: he rolled his eyes at the elmo clause
<mako> sabdfl: may try to bring taht up next week
<mako> mdz: ^^^
<mako> sabdfl: i wish i could blame taht on tab completision.. that was brain completions problem
<mako> sabdfl: sorry :) almost done with a reorganization that i think you will like
* lamont goes to fetch kids.  bbiab
* dilinger wonders whose kids..
<T-Bone> dilinger: it's better if you don't know. For your own sake ;^)
* T-Bone runs away swiftly before lamont comes back with some highly explosive substance he knows about ;)
<T-None> gnight all
<mako> mdz: check that out: http://www.ubuntulinux.org/wiki/NewMembersMaintainersDraft
<mako> sabdfl: ^^
<mako> sabdfl: you were right. i think that reads a *lot* better.. 
<ajmitch> morning
<Kamion> mdz: I suspect part of the mptscsih problem might be, is it possible to register the same PCI ID in two modules and expect both of them to be loaded?
<mjt> mdz: you around?
<mdz> mjt: yes
<mdz> Kamion: apparently it is; it happened undesirably with e100 and eepro100
<mjt> mdz: just come across this for initrd/whatever coldplugging:
<mjt> eval "findmodule() { case \$1 in $(sed -n 's|^alias \(.*\) \(.*\)|\1)module=\2;;|p' /lib/modules/$(uname -r)/modules.alias ) *) module= ;; esac; }"
<_mvo_> ping jdub 
<bluefoxicy> pitti: ping?
<pitti> bluefoxicy: pong
<bluefoxicy> pitti:  did you get my e-mail?
<_mvo_> anyone else noticed problems with gamin? it seems to not inform me about changed files :/
<pitti> bluefoxicy: ahem, mind to translate your nick into a realname?
<bluefoxicy> pitti:  John Richard Moser :)
<pitti> ah :-) sorry
<bluefoxicy> wow, you only have update-linux-hardened-support hitting Xorg and soffice.bin?
<pitti> bluefoxicy: well, mono too
* bluefoxicy is looking at /etc/linux-hardened-support/page_exec.conf :)
#ubuntu-devel 2005-02-13
<thom> mdz: well, that was a great game
<pitti> bluefoxicy: all other things work for me
<mdz> thom: for you, perhaps
<bluefoxicy> pitti:  it kills various xscreensavers too (you get a black screen), also I had it kill qemu
<pitti> hmm, obviously I don't use these things :-)
<thom> mdz: you're not a poor misguided arsenal fan? 
<pitti> bluefoxicy: you mean your mail about testing the kernel?
<mdz> thom: no, I couldn't care either way, but I was surrounded by arsenal fans :-)
<bluefoxicy> pitti:  does pitti  yeah
<thom> heh!
<mdz> pouting and crying
<bluefoxicy> pitti: yeah
<thom> as it happens, so was i. very funny
<bluefoxicy> pitti:  does /usr/lib/xscreensaver/bouncingcow work for you?
<pitti> bluefoxicy: yes, pretty well
<bluefoxicy> hmm.  ok.
* bluefoxicy has mesa gl, not accelerated.
* pitti uses standard nv driver (not accelerated as well)
<thom> mdz: they have arsenal fans in LA?
<pitti> bluefoxicy: thanks for the testing, btw
<bluefoxicy> pitti:  Also, have you tried libsafe?  I just added /lib/libsafe.so.2 to /etc/ld.so.preload and rebooted, cat says it's got libsafe linked it.
<mdz> thom: yes, we have real live English people too
<pitti> bluefoxicy: however, we can't put patched binutils in hoary right now
<pitti> bluefoxicy: never heard about libsafe
<bluefoxicy> pitti:  libsafe prevents overflows from happening if they leave the current stack frame; this will stop large overflows, and should make many overflow periods too small to insert shellcode or stack frame pointers for ret2libc attacks
<thom> mdz: i hadn't realised getting rid of arsenal fans was a growth industry. good to know, anyway
<bluefoxicy> pitti:  problem is that it (i think) still lets enough overflow happen to tank the SFP and return pointer, meaning exploits that SSP will stop can still happen if they load their shellcode on the heap (i.e. in a PNG image exploiting the PNG overflows, etc)
<bluefoxicy> pitti:  libsafe is in universe
<bluefoxicy> just apt-get it and add /lib/libsafe.so.2 to /etc/ld.so.preload, then try `cat /proc/self/maps | grep libsafe` to see if it's there
* bluefoxicy is using it now in combination with ProPolice; ProPolice protects data inside the current stackframe, libsafe protects data outside the current stackframe.  :)
* marioch is back (gone 04:51:06)
<Kamion> mdz: hm, well that might help ...
<Kamion> night all
<thom> night dude
<pitti> Night Kamion 
<ogra> night
<ogra> pitti: any news about the hal/udev bug ?
<pitti> no, sorry
<ogra> i tried out stopping only hal manually before the install/upgrade of the package... didnt help, the funny thing is, if i do it right after boot on a console (without being logged in to gdm, but gdm running) it doesnt occur
<ogra> pitti ^^
<pitti> ogra: right, I already tried that too (on smurfix' machine)
<ogra> ah, ok
<gernika> Hello, I run an irc logging site.  I have heard that the #ubuntu channel is a very helpful channel and am interested in logging that channel.
<jbailey> WTF? 
<ogra> jbailey: ?
<jbailey> For some crackheaded reason bugzilla took me to another bug number.
<AndyR> evening from UK
<gernika> would that be ok?
<jbailey> ogra: Don't mind me, I just posted a patch on the wrong bug number.
<ogra> heh
<Mithrandir> jbailey: it does that after you have edited a bug.  Really icky.
<gernika> here is an example log: http://www.loglibrary.com/62/
<ogra> gernika: if you want to log the conversations in #ubuntu, you should ask the people whose conversations you want to log if they think its ok....
<jbailey> I wonder how many other times i've done that and just not noticed. =(
<ogra> i.e. ask in #ubuntu ;)
<gernika> ogra: i did, but they told me to come here :)
<ogra> gernika: i personally have no problems if you or anybody else logs my conversations in #ubuntu....
<robertj> I think by virtue of being on irc you consent to being logged
<AndyR> would it be best to put logging message in topic?
<gernika> AndyR, I think that would be good.
<Mithrandir> The channel is already publically logged --  http://people.ubuntu.com/~fabbione/irclogs/
<Mithrandir> it's noted on the wiki somewhere.
<HrdwrBoB> AndyR: I think the topic has enough stuff as it is
<gernika> I provide indexed searching as well as some other useful features, if you don't mind double logging.
<AndyR> HrdwrBoB, fair point
<ogra> topics tend to grow....
<gernika> How about if I mention it somewhere in the wiki?
<_mvo_> hey jdub_ 
<AndyR> any developers living in united kingdom?
* thom is in the smoke
<AndyR> unlikely :))
<AndyR> unlucky even
<thom> pffft
<AndyR> im in southampton
<thom> ah. my brother is at uni there
<thom> at the institute
<AndyR> oh ok
<robertj> ooh, Puzzle Pirates is being a good Open Source citizen
<robertj> it provides a front page link to the linux client and puts a .desktop file on your desktop
<AndyR> thom, comp sci?
<thom> AndyR: my brother? tourism management
<Mithrandir> thom: "cattle herding"?
<thom> Mithrandir: "skiving"
<mxpxpod> thom: have you made any more netmanager packages?
<thom> mxpxpod: not recently, been a tad busy
<mxpxpod> heh, ok
<mxpxpod> just wondering
<lamont> aclocal: configure.in: 72: macro `AM_DISABLE_STATIC' not found in library
<lamont> aclocal: configure.in: 74: macro `AM_PROG_LIBTOOL' not found in library
<lamont> hrmpf.  cyrus-sasl not happy
* _mvo_ is not happy too
<_mvo_> lamont: *grr* it build in my pbuilder :(
<tseng> can anyone reupload a miffed build-dep for me?
<tseng> it will be a few days before i can get upload, web of trust needs worked out
<mdz> tseng: deb-src ?
<tseng> mdz: didnt upload a source package for it, i can make it for you right quick
<mdz> tseng: you tested this one in a chroot, I hope ;-)
<lamont> _mvo_: pbuilder is evil
<tseng> hmm no i read the config scripts to dep checks
<lamont> since it picks the wrong build-deps
<tseng> ill do the chroot thing
<lamont> _mvo_: specifically, pbuilder picks the last of any | lists in the build-depends, (our) sbuild picks the first (available)
<azeem> _mvo_: why did you remove libtool?
<elmo> azeem: libtool1.4's considered harmful
<_mvo_> azeem: elmo said it all :)
<azeem> and automake1.4 isn't?
<mdz> build-depending on libtool in general isn't particularly sane
<mdz> of course automake1.4 is
<elmo> hmm, it's in main tho
<elmo> boggle, directly seeded too
<mdz> boggle indeed
<mdz> but it's build-depended upon by tons of stuff anyway
<elmo> yeah, but can I remove the direct seeding regardless?
<mdz> definitely
<azeem> so libtool gets into the usual pbuilder chroot, or what?
<mdz> and the other old versions of stuff anyway
<mdz> automake1.7
<elmo> azeem: probably a timing thing
<mdz> automake1.8
<azeem> or that
<mdz> autoconf2.13??
<mdz> gnome-common??
<mdz> how did this crap get in there?
<elmo> all purged, added automake1.9
<pvh> Is dmix anywhere on the Ubuntu horizon?
<elmo> removing gcc, it's pulled in by build-essential and the comment's already outdated
<elmo> do we want the duplication of ship and seed or can I clean it up while I'm here?
<elmo> meh, ship and supported
<elmo> and can I add baz to ship? nm, in fact, I'll just mail
<mdz> pvh: not currently, no
<mdz> elmo: unsure about ship/supported duplication, ship is a bit special
<elmo> mdz: I'm fairly sure it's a bug, it's partial
<elmo> but I'll cc colin on themail
<mjg59> thom: Ping?
<pvh> mdz: Just lack of interest, or are there technical obstacles?
* mjg59 appears to have sorted the Thinkpad power consumption thing
<mdz> pvh: it has come up several times, and the result of the discussion in Mataro was to go with polypaudio, following GNOME
<mdz> dmix doesn't seem to offer much in the way of incentive over polypaudio
<mdz> mjg59: all thinkpads, or particular ones?
<mjg59> mdz: The ATI ones
<pvh> mdz: I'll look into it. Thanks.
<mdz> yay
<tseng> oh, this chroot business rocks++
* tseng fixes a bug in the wiki page
<mjg59> Hrm. Trying to deal with PCI capabilities is slightly sucky.
<srbaker> yaye
<dholbach> re
<mjg59> Anyone know of code for dealing with reading PCI capabilities in userspace?
<infinity> mjg59 : lspci?
<mjg59> infinity: Hrm. Yeah, I guess it must do.
<infinity> mjg59 : Assuming by "capabilities", you man stuff like:
<infinity> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
<infinity> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
<mjg59> Yeah, that's the stuff
<pitti> Night everybody!
<srbaker> what seems to be the most popular lappy for ubuntufolk?  X series thinkpad?  or ibook?
<mjg59> X40, for the most part
<mjg59> /* Here we fork() and exec() the lspci command to look for the Radeon hardware \address. */
<mjg59> ARGH HOLY JESUS NO
<srbaker> mjg59, well, i'm not rich.  i can only afford a used one.  so an X2? or X3?
<mjg59> The newer the better, really
<infinity> I've not had issues with any Thinkpads from the last 5 years or so.
<infinity> But newer is always better.
<daniels> mdz: pong
<mdz> daniels: wanted to talk to you about xserver-xorg template text
<mdz> since the mode selection dialog is only displayed if the probe fails, I think it deserves some explanatory text
<mdz> "Unable to automatically determine the capabilities of your monitor, please tell me:" or similar
<daniels> mdz: reckon we can get that translated in time for hoary?
<mdz> this might necessitate a separate template to be used if the probe fails, as opposed to probing being disabled
<mdz> yes
<elmo> jbailey: the point about libnet-snmp-perl was that the snmp plugin is C
<daniels> mdz: ok, i've tomboyed it
<jbailey> elmo: Yes, and two utilities are in Perl.  I wrote in the bug which ones they are.
<infinity> Okay, i just fell further in love with IBM.  They finally let you completely configure a Thinkpad online.
<daniels> mjg59: are you reading radeontool again?
<elmo> jbailey: so you did, sorry
<mjg59> daniels: Yes
<mdz> jbailey: can you upload now?
<tseng> mdz: tested in a clean chroot. http://smarterits.com/~brandon/tomboy/
<mjg59> daniels: I decided to do this in userspace, rather than hack up a kernel driver
<mjg59> Works, too - I got a T42 down to 0.5W
<jbailey> mdz: I sent off the email to elmo this morning.  I figured it was polite to wait a day before nudging him. =)
<daniels> mjg59: nice!
<elmo> yeah, I'm doing it before I go to bed
<mdz> tseng: uploaded
<tseng> mdz: thanks muchly
<tseng> is there a quick way to clean my chroot for testing again?
<tseng> i followed DebootstrapChroot on wiki.
<mdz> rm -rf and make a new one, save a tarball of it before deflowering it the next time
<tseng> ok, thanks.
<srbaker> i have two laptops.  p3 laptops.  i'm going to sell/trade those to get either an iBook or an X20/30
<srbaker> a tecra 8100 750/192/20G, and a thinkpad a20m 500/128/20G
<dilinger> tseng: btw, dunno if you saw.. i unleashed -as3 yesterday
<tseng> dilinger: saw it :P
<tseng> looked over it briefly, didnt have time to really digest
<tseng> i have a hard time with the changelog format
<mjg59> ARGH.
* mjg59 KILLS pcilib
<jbailey> dilinger: -as3, like the "kernels that don't suck" round that you were talking about doing?
<tseng> jbailey: indeed
<elmo> amu: ?
<amu> yep?
<daniels> holy shit, they really were serious
<daniels> new major version of fglrx scheduled for release next week
<elmo> amu: is kiosktool yours, or are you sponsoring it?
<srbaker> does the x40 have accelerated video?
<amu> elmo: mine
<daniels> srbaker: yes
<srbaker> daniels, so if i plug a monitor into it, the cursor won't skip across the screen, right?
<daniels> srbaker: huh?
<tseng> you mean xinerama?
<srbaker> daniels, on my friend's T22, when she plugs a monitor into it, there's a mouse trail.
<srbaker> daniels, the mouse cursor skips around
<daniels> er, that's probably just a bug in the driver
<daniels> then again, radeons are known to have weird cursor limitations
<daniels> i get massive, massive artifacting if I scroll the bottom fo my LCD (i have an uneven mergedfb)
<daniels> and we can't fix that, that's a card limitation
<srbaker> she's using a docking station, and replacing her desktop with it
<elmo> amu: ok, sorry then dude
<elmo> would it be particularly evil to rip out "compatability" code for something like fsh and just leave it with stuff that works for python2.4?
<srbaker> how much battery time do you get on an x40?
* lamont heads to the fire dept meeting.  back later
<daniels> srbaker: lots and lots
<amu> elmo: np 
<srbaker> daniels, how many hours?
<srbaker> i know what ibm says.  and it sounds unreasonable
<srbaker> ibm says 5hrs.  i know that requires lunar alignment
<daniels> srbaker: with the 4-cell battery, you get about 6 with wifi on
<srbaker> whoa.
<daniels> srbaker: er, with the 8-cell
<daniels> the 4-cell is about 2.5, apparently
<srbaker> oh.  is that the jumbo battery?
<daniels> extended life puts you in 11 territory
<srbaker> coooooooool
<daniels> not really jumbo; it sticks out the back a bit, but it's not like awedge underneath (the extended life kinda wedges underneath)
<daniels> the 8-cell is standard in australia
<srbaker> that's what i want. an x22 and an extended life battery
<infinity> srbaker : Believe IBM (and daniels)... I used an X series for a while, and it blew me away.
<infinity> Though, if I was shopping today, I'd probably rather have a T series.  But I don't walk around with laptops much.
<amu> srbaker: the trick is like that, if you want a working X, just buy the same laptop as daniels has :)  
<infinity> <laugh>
<infinity> And if you want good ACPI, buy the same laptop as mjg59?
<srbaker> hahah
<srbaker> infinity, i want one that i can plug in when i go to bed
<srbaker> when i wake up, i want a fully charged battery that i don't have to worry about
<srbaker> and, i want a docking station at home
<infinity> Docking stations are overrated.
<srbaker> so, i'll get the extended life, and a 4-cell just in case
<srbaker> infinity, i prefer desktop (wireless) keyboard and mouse when i'm home
<infinity> Have you owned an IBM laptop before?
<tseng> i dont need a docking station for that
<tseng> i plug in a usb receiver and bam
<infinity> After using IBM laptop keyboards, I prefer them to 99% of desktop keyboards.
<amu> infinity: hehe 
<srbaker> infinity, yeah.  i had an A20m.  the keyboard was awesome.
<infinity> Though an external mouse can be nice on occasion.
<srbaker> infinity, but i pound on the keys somethign fierce.  laptop keyboards don't last long for me
<elmo> sigh, that took way too bloody long
<elmo> jbailey: done
<amu> elmo: how it works, i need a sync of kalyxo, should i tell you, fire in the hole?  
<jbailey> elmo: Thanks!  Now I just need to figure out how we store the arch bits for chewing on the Debian package and I'll upload the nagios plugins package.
<elmo> jbailey: eh, arch bits?
<jbailey> elmo: Don't we keep the diffs from Debian packages in arch?  I thought I read that on the wiki.
<elmo> jbailey: not yet, not our changes
<elmo> for distro stuff you can just upload, no arch stuff needed
<jbailey> Ah, okay.  How do we keep those from getting overwritten when new versions are imported?
<lamont> jbailey: we don't import - we bitch in bugzilla
<lamont> or rather, the merge-o-matic does
<jbailey> *lol*
<lamont> jbailey: will be much nicer once the infrastructure is really there and we can do it easier...
<lamont> and if the change is one that should be pushed to debian, then be sure to file the bug in debian's bts, or update the existing bug with the patch
* lamont is working through the uber-diff figuring out what we have and havent'
<lamont> actually submitted to debian
<lamont> but now I'm running out the door before I'm late...
<lamont> bbl
<jbailey> 'kay.  Do I note in bugzilla that I've posted to patch to the Debian BTS?
<elmo> jbailey: probably a good plan - you know where to put that right?
<elmo> i.e. patches.ubuntu.com
<jbailey> elmo: Yup, I see it here under BugTracking
<elmo> k, cool
<jbailey> elmo: Thanks. =)
<elmo> amu: sorry, forgot to answer.. err.. sync from where unstable?
<elmo> amu: if so, and it's universe, just ask me on irc or mail me if I'm not around on irc
<thully> is array 4 still set for tomorrow?
<dholbach> now i'll really go to bed - bye
<tseng> bye.
<dholbach> bye tseng  :-)
<amu> elmo: np, sending a mail ...  
<amu> daniels: did you added dbus-qt? 
<daniels> amu: yeah, it should already be in 
<amu> daniels: cool, thanks a lot!
<daniels> no worries
<amu> daniels: hmm no it isnt :)  
<daniels> amu: weird.  will take a look at it after lunch, but it should've gone in with dbus 0.23.
<mjg59> Anyone around here with an ATI-based machine?
<daniels> mjg59: 'sup
<mjg59> (And willing to try something that may well require a reboot)
<mjg59> daniels: Can you:
<mjg59> a) grab http://www.codon.org.uk/~mjg59/tmp/radeontool.tar.bz2 and make it
<mjg59> b) from a text console, do radeontool power off && sleep 5 && radeontool power on && vbetool post
<mjg59> c) tell me what happens
<mdz> jbailey: yes, the long-term vision is to use arch very widely, but the infrastructure isn't there yet
<amu> daniels: in this case you should  remove --disable-qt :)  
<mjg59> (Note that (c) may well be It fucks everything up badly)
<mjg59> daniels: This sets various registers to reduce power consumption, and then puts the card in D3
<mjg59> Oh, yeah, you probably don't want to do this if you're running radeonfb
<daniels> mjg59: sure
* mjg59 wonders if it's exploded daniels
<daniels> mjg59: radeontool power off ran for 30 seconds without seemingly doing anything
* dilinger looks forward to martin pool's work
<daniels> want an strace?
<daniels> (the console was still alive, it still updated)
<marcin_ant> hi - does anyone (excluding jdub) here know something about Website Look'n'Feel Competition?
<mjg59> daniels: If you could, yeah
<daniels> mjg59: loops endlessly in get_pm_cap
<mjg59> daniels: Ah, right
<mdz> lamont: does hoary-live-ia64.iso boot and/or work?
<mdz> an ode to grub:
<mdz> GRUB WHY DO YOU SUCK SO MUCH
<mdz>  - by mdz
<dilinger> <grub> because i can.  look at my competition.
<stackpopper> How commeth the ppc64 port?
<mdz> stackpopper: no one is working on one at the moment
<infinity> If I had a ppc64 machine..
* infinity hints.
<stackpopper> infinity, So the ppc64 hoary release is just an online myth?
<infinity> Well, hoary will run on ppc64 machines, but with a 32-bit userland.
<infinity> So, it's a half-myth?
<stackpopper> noted.
<infinity> (where is this myth perpetuated?)
<stackpopper> I can't remember
<stackpopper> probably irc
<stackpopper> Do any of you live in Scotland?
<infinity> Many live close enough...
<infinity> Well, closer than I.
<stackpopper> How long would it take to port?
<stackpopper> At a guess\
<infinity> Depends on if I have any weird compilation issues, iff gcc's ppc64 backend is up to snuff, and how fast my buildd is.
<mdz> IRC never lies
<infinity> Assuming best case for all three, a matter of weeks.
<infinity> Assuming worst case, a couple months?
<stackpopper> That isn't too bad
<mdz> yeah, it's mostly a matter of ppc64 hardware being comparatively rare
<mdz> if you have a ppc64 system and would like to help with the port...*hint*
<infinity> I keep trying to get my hands ona G5, but my bank account keeps saying "no".
<stackpopper> Well, if the timing was right
<mdz> G5s want 32-bit userland anyway
<stackpopper> I can probably *help* somewhat
<infinity> I was under the impression you could run them pure64 just fine.
<mdz> you can, but you get better performance from 64/32
<infinity> Or, did you mean that "G5 users should want 32 bit userlands"?
<infinity> Which is likely true.
<stackpopper> Why?
<infinity> Yeah.  The 64 bit userland has no real gain on G5s, but a G5 would be fine for the porting effort.
<infinity> 64-bit userland == bloated memory and register consumption.
<infinity> If you don't need it, you don't want it.
<stackpopper> noted.
<infinity> Same reason people rarely complain that UltraSparcs use a 32-bit userland.
<infinity> (Though they sometimes do)
<stackpopper> :P
<mdz> infinity: "want" rather than "need"
<mdz> power5, though, is supposedly a different story
<stackpopper> interesting
<infinity> Less register-starved, probably.
<mdz> though those are even harder to come by
<stackpopper> I assume those babies will end up in the next wave of mac's
<infinity> But, any porting effort done on a G5 in pure64 should be happy running on a power5, so I'd be happy porting on the "wrong" hardware.
<infinity> Though, testing on a power5 would be nice.
<infinity> stackpopper : No.. The Motorola CPUs and IBM CPUs are reasonably forked.
<infinity> stackpopper : The POWER series has a different target audience.
<toresbe> 
<infinity> Apple can talk all they want about Macs being "supercomputers", but compared to their cousins at IBM, they're pathetic.
<stackpopper> Isn't the CPU in the G5's just an IBM POWER4?
<infinity> No.
<mdz> related
<mdz> but not at all identical
<infinity> Sure, they're all related, back to the first PPC.
<mdz> well, some closer than others :-)
<infinity> The G4 doesn't have Altivec, however, has (generally) larger caches, has more registers (I believe), and is most likely manufactured on a different process, etc.
<infinity> s/G4/POWER4/
* infinity blames his fingers.
<mdz> our -power4 kernel runs on G5 and power4, but not on powerpc
<stackpopper> noted
<stackpopper> Do any of the later snapshots install flawlessly on the imac's as of yet?
<stackpopper> Or should I say, is it an issue which will be resolved by the next release?
<mdz> Warty runs fine on imacs
<mdz> at least some of them
<stackpopper> won't install on this one. :(
<mdz> did you look for known bugs, or file a new one?
<stackpopper> I haven't had time.
<stackpopper> but I do now.
<mdz> please do try a daily, then
<mdz> where did the install fail?
<stackpopper> when loading
<stackpopper> some crazy firmware spew then it freezes
<infinity> Well, whattayaknow?... IBM does make exactly one machine with a G5 in it. :)
<stackpopper> :/
<stackpopper> nada in the bug database
<stackpopper> there is a reference to my problem in the forums
<stackpopper> however, it is a crappy report
<stackpopper> and help given was for the sake of helping
<mdz> stackpopper: when booting the install CD?
<stackpopper> that's right. 
<mdz> it should be a quick test to see if it's better now, then ;-)
<stackpopper> I'll download that snapshot you released recently when I get into the city
<mdz> yeah, a live CD test should do fine for that
<toresbe> infinity: Do they?
<toresbe> infinity: which machine is that?
<stackpopper> :)
* toresbe is today going on a proprietary UNIX rampage
<toresbe> Linux is boring, everything is so ...predictable and ... it works
<stackpopper> yeh, it is getting boring these days
<stackpopper> very boring
<toresbe> so I'm installing solaris 8 and IRIX
<stackpopper> It used to be fun hacking your system together
<toresbe>  not I get boring OS'es with support for everything
<toresbe> stackpopper: if you're into hacking kernel stuff, mipslinux needs you ;)
<dilinger> run the -mm tree
<dilinger> lots of fun broken stuff to play w/
<stackpopper> linux on the PSP would rule
<stackpopper> especially if you could connect a keyboard/mouse to it
<stackpopper> etc
<mdz> jdub: gnome-bt?
<jdub> mdz: not entirely happy with it, but it'll do
<mdz> jdub: if there are tweaks you'd like to see made, maybe we can bounty the lot
<mdz> meanwhile, I'm going to upload it
<mdz> want to send a nice mail to the author telling him his package is in Ubuntu?
<infinity> toresbe : The js20 blades have dual 970s (970 == G5, same deal)
<toresbe> ah
<thully> Hi - I just tried to install Ubuntu from 2/1 hoary shapshot and it installed, but Xorg won't start - is this a known issue?
<crimsun> thully: where does it break?
<thully> it won't configure Xorg - I get some message about a driver missing and it won't start
<thully> Xorg -configure even fails
<thully> Actually, it does configure using debconf but won't start - won't configure with Xorg -configure
<thully> How do I look at recently closed bugs filed by me in Bugzilla?
<crimsun> should be in your list of bugs
<thully> no - only see open bugs
<thully> any clue on the X stuff?  I'd hate array 4 to have this issue!
<crimsun> thully: unfortunately I haven't tested 2005-02-01 snap, so I can't say for certain, but place your /etc/X11/xorg.conf and /var/log/Xorg.0.log on http://pastebin.ca
<lamont> mdz: the live CD has the cloop fs on it, but claims to be 'installer', and brings up the partitioner...
<lamont> am I missing something?
<thully_> just had connection problem
<thully_> so, I'm still wondering - what's wrong with X?  debconf configures my card and then it complains about drivers when starting
<sabdfl> Kamion: the cc is the right forum to deal with problems related to the code of conduct on lists. if we get another thread like that, i'd encourage any member of the cc to step in and ask the people involved to remind themselves of the code of conduct
<daniels> thom: what are you actually trying to do here?
<daniels> s/thom/thully/
<daniels> and he's even gone, god
<sabdfl> Kamion: failing that, if we have someone who won't respect that, let's raise it at a cc meeting (we can call a special one if it needs urgent attention) to discuss it, and then i'd be willing for the cc to ban someone who persisted in making a mess of it from the lists
<mdz> lamont: weird
<mdz> lamont: partman shouldn't even get unpacked on the live CD
<mdz> lamont: ohh
<mdz> lamont: I bet the boot loader magic hasn't been done for ia64
<mdz> lamont: you need to pass a couple of parameters
<fabbione> morning guys
<mdz> lamont: casper/enable=true casper-udeb/snapshot/backing-file=/cdrom/casper/filesystem.cloop
<daniels> mdz: next upload gets us xorg-on-livecd
<daniels> fabbione: morning dude
<mdz> daniels: wha?
<fabbione> hi dani
<daniels> mdz: the next time I upload xorg, the live CD will work *under* *qemu* (possibly a vital piece of missing information)
<mdz> aha
<mdz> speaking of which
<mdz> I just did a test install on powerpc
<mdz> and X seems to start, but the monitor never syncs
<fabbione> what about a kernel meeting tuesday after the CC meeting?
<mdz> it goes into power save mode
<daniels> mdz: log and config as per usual
<mdz> yeah, getting them
<daniels> cheers
<daniels> i'm pretty sure it was fixed in ubuntu12
<daniels> (assuming your problem is what I think it is)
<mdz> mailed
<daniels> cheers, will check it out
<mdz> (II) RADEON(0): Supported Future Video Modes:
<mdz> whoa, this card supports modes that _don' t even exist yet_
<infinity> Handy.
<daniels> heh
<daniels> that's a vesa thing
<daniels> you can specify modes that are defined in the vesa spec, or you can specify resolution+depth+refresh modes in free-form, or specify detailed timings
<daniels> mdz: what the fuck is wrong with that monitor?
<daniels> is it actually 1:1, or is it just totally bong?
<mdz> nothing, I'm using it right now
<mdz> it's attached to a KVM is all
<daniels> it looks like everything that came back via EDID is *comp ... oh
* daniels frowns.
<mdz> warty installed fine on this very machine, and it was happily running warty-upgraded-to-hoary until I decided to trash it tonight
<daniels> dvi, or vga?
<mdz> VGA
<daniels> ah, it doesn't give us sync ranges
<mdz> it also was fine with the hoary live CD
<daniels> yeah, that's already fixed, and ubuntu13 will build on powerpc
<mdz> at some point in the past
<daniels> yah
<daniels> it would've been fine with 6.8.1-1ubuntu10
<daniels> your kvm is seriously wack, btw
<mdz> it was cheap
<mdz> there are two kinds of KVMs
<mdz> wack and very very expensive
<jdub> or wack and cheap? :)
<toresbe> You know you're tired when you see letters in the IRC log
<toresbe> I mean, as in, your eyes blur and you see ASCII art
<jdub> amu: ping
<mdz> fabbione: I don't think I will be able to attend the kernel meeting; if you think you will need me, let me know soon so that we can work something out
<fabbione> mdz: don't worry about it. if you are happy with me evaluating a temporary team leader and you can stay in bed and enjoy :P
<fabbione> same question as yesterday:
<fabbione> - next kernel will break the ABI module loader <whatever thingy>
<fabbione> is there anything sweet we want to drag in it?
<infinity> "whatever thingy". :)
<fabbione> please speak up now or be quite forever.. backport from 2.6.11 starts to be a royal pain
<mdz> we can move to 2.6.11 for hoary if you think it's the right way to go
<fabbione> mdz: there is no 2.6.11 yet, we are at rc2
<fabbione> but they changed heaps load of code around
<fabbione> and it starts to be more difficult to merge back
<mdz> yes, I know :-P
<mdz> but it is likely to release before hoary
<fabbione> i am pretty sure it will
<fabbione> BK PATCH]  Critical SCSI fixes for 2.6.11-rc2 <-
<fabbione> stuff like that ;)
<fabbione> that really makes my day!
<fabbione> :P
<fabbione> mdz: i would suggest we wait a bit and see
<mdz> [BK PATCH]  New virtual memory manager
<fabbione> changing major kernel at this point in time is not as timeconsuming as before
<fabbione> given that i sorted patches as stolen_from_head and externals
<mdz> yes, I saw
<fabbione> at least i think i got all of them
<fabbione> but in the worst case there are not that many external
<fabbione> mdz: how happy would you be if i prepare a 2.6.11 packages?
<mdz> sounds fine
<fabbione> mdz: starting with a .orig.tar.gz from 2.6.10 and using incremental patches to go to a .11 status?
<fabbione> clearly it means that when a real .11 will exists there will be a stolen_from_head_2.6.10-to_real-2.6.11.dpatch
<fabbione> but i think that doesn't change anything to anybody
<mdz> you could use a 2.6.11-rc .orig
<fabbione> have been there... no thanks
<mdz> 2.6.10->2.6.11rc seems like a huge patch to put in the diff
<mdz> I haven't looked, but they are usually huge
<fabbione> the debian/rules needs a lot of love to understand that stuff
<fabbione> it's about 3.5Mb
<mdz> bz2?
<fabbione> mdz: the problem is all the versioning after.. we can call the orig even 2.6.10+2.6.11rc2mm383646
<fabbione> i think gz
<mdz> 2.6.11~rc2
* mdz hides
<fabbione> but when make-kpkg and debian/rules are going to build, they will go banana
<fabbione> ahhaha
<mdz> we need to do a major review of kernel bugs in bugzilla.  will you talk about that at the meeting next week?
<fabbione> yes.. that enters the "TODO list"
<fabbione> we need 3 major subsystems reviewed
<fabbione> USB, alsa and acpi
<fabbione> 99% of the bugs float around them
<mdz> I am sending you the last of the bugs that are still assigned to herbert
<fabbione> yes i noticed
<mdz> hopefully the kernel team can divide them up
<mdz> many of them probably need re-testing with 2.6.10
<fabbione> many of them are SL errors
<mdz> sl?
<fabbione> Super Lusers :)
<daniels> the new fglrx might work with our kernel finally, but I doubt it
<fabbione> daniels: get ready for another ABI change
<fabbione> ahhaha
<mdz> at least we have a live CD with an identical kernel so that they can use it to test
<daniels> fabbione: just don't touch DRM this time :P
<fabbione> mdz: exactly
<fabbione> daniels: i am updating them
<daniels> fabbione: i have to roll a new orig, bump the ati version and whatever anyway; whatever you do cannot hurt me
<daniels> fabbione: aieeeee
<daniels> fabbione: ok, maybe whatever you do can hurt me
<fabbione>     - DRM at 20050201:
<fabbione>       . Add patch stolen-from-head_drm2.dpatch.
<daniels> but hey, I love pain
<daniels> HURT ME MORE
* fabbione hits daniels with a bat
<daniels> whoohoo!
<daniels> thankyou
<mdz> man, I feel bad
<mdz> I ate this pub food for lunch
<mdz> and I think it was a mistake
<infinity> Did it scream on the way down?
<mdz> no, it is only now rearing its ugly head
<daniels> mdz: good pub food is awesome; bad pub food is e.coli
<infinity> I don't think "good pub food" exists in Cairns.
<infinity> You'll have to show me some in Melbourne.
<infinity> (but not before the pancakes)
<daniels> infinity: James Squire Brewhouse.  But yes, after PCP.
<infinity> Pancake Parlor is like... Heaven.
<infinity> With more butter.
<HrdwrBoB> haha
<HrdwrBoB> a *LOT* more butter
<daniels> infinity: Imagine a fine pie made with a rotating meat and beer.  Sometimes (in the case when I had it) beef and Porter.  Oh my god.  And chips.  Yum.
<daniels> HrdwrBoB: and cider!
<HrdwrBoB> I still say cider needs to come in jugs
<infinity> daniels : Where I come from, pie doesn't contain meat.
* daniels kicks himself for offtopicness.
<jamesh> not even a little bit?
<daniels> infinity: But yeah, you'll see.
<infinity> daniels : Blame mdz.  His stomach started it.
<fabbione> mdz: pub food? too bad you are vegetarian.. otherwise Double Bella burgers!
<jdub> monthly calendar word of the month: "triangle"
<daniels> fabbione: triple
<fabbione> daniels: that one too :)
<mdz> bella?
<jdub> pipka has gone vego now
<mdz> perhaps some delicious portabella?
<jdub> or is at least trying it
<fabbione> mdz: half cow compressed in a burger with everything in it.. salad, tomatoes.. etc.
<daniels> mdz: bottom up: bun, onion, lettuce, HUGE-ARSE BEEF PATTY, cheese, bacon, sauce, HUGE-ARSE BEEF PATTY, cheese, bacon, sauce, lettuce, onion, bun
<jdub> tonight i am eating herb and garlic kangaroo
<daniels> oh yeah, tomatoes and stuff too
<daniels> jdub: when'd that happen?
<jdub> about a week and a half ago
<daniels> mdz: beautiful, but I didn't want to look at meat for a while after that.  went to a vegetarian restaurant the next night and had a jerusalem artichoke salad, a pie with spinach and lots of veggies in it, and a beetroot-based sald.  all organic.  heaven.
<daniels> jdub: whoa
<fabbione> mdz: HOLY SHIT! from 60 to 110 bugs in one shot eh?
<jdub> daniels: matrox 450 3d support - open source?
* jdub remembers there was
<jdub> but might be on crack
<daniels> jdub: not afaik
<daniels> jdub: i believe 3d stuff is provided by the binary mga_hal module
<HrdwrBoB> no
<HrdwrBoB> that's the TV out and stuff
<daniels> which can be loaded a da submodule of the open source module
<daniels> oh, so there's full open-source dri?  sweet
<HrdwrBoB> 450 is a 400 by another name ?
<daniels> the 650 is *totally* unsupported
<jdub> HrdwrBoB: pretty much
<HrdwrBoB> I'm fairly sure
<daniels> HrdwrBoB: i believe it's a dual-head 400?
<HrdwrBoB> yeah
<HrdwrBoB> I had a 400
<HrdwrBoB> er 400 is dual head
<HrdwrBoB> it's a nonshit 400
<jdub> daniels: 650 is the parhalia or whatever it is?
<HrdwrBoB> 400 had a terrible RAMDAC on the second head
<daniels> jdub: yeah, we have nothing for that, and they won't even talk to us
<jdub> wow
<jdub> changed their tune a bit
<daniels> they're perfectly happy to throw specs to xig for accelerated x
<HrdwrBoB> 400 drivers were the ones carmack helped on
<daniels> but won't have anything to do with xorg.  not even a binary module.
<HrdwrBoB> for quake3
<HrdwrBoB> *reminisce*
<jdub> does mga_hal work with xorg?
<fabbione> daniels: the 650 should be fairly trivial to add
<fabbione> daniels: i did a temporary patch once, but i think it got lost somewhere
<fabbione> daniels: you can just try adding || MGA650 in parallel to 450
<fabbione> the amount bits to change is minimal
<HrdwrBoB> jdub: looks like it
<jdub> HrdwrBoB: oh, using matrox now?
<jdub> i loved my matrox card
<jdub> such crisp 2d display
<HrdwrBoB> yeah
<infinity> Do you guys mean 550, not 650?
<HrdwrBoB> I did side-by-side nvidia/matrox and it was chalk and cheese
<infinity> If so, fabbione's right.  The 550 is just a souped up 450.
<daniels> fabbione: people tried that -- it's a totally different core
<jdub> 550 should work, but 650 is totally different
<daniels> fabbione: the 550, as infinity says, is 450-based, but the 650 stuff is a totally different chip altogether
<fabbione> oh ok
<jdub> Kamion, mdz: do we have cpu detection -> choose appropriate kernel package stuff in the hoary installer?
<fabbione> jdub: exactly as we did in warty :-)
<jdub> oh
<fabbione> jdub: sparc should be installable today
<fabbione> wanna give it a shot?
<fabbione> daniels: ?
<jdub> 'cos a gnomer tried sarge and got an smp kernel on his p4 (correctly so), but didn't on warty/hoary
<jdub> fabbione: ahr, will do - mini.iso?
<fabbione> jdub: mini.iso or netboot.. same stuff
<fabbione> if you can try both it's even better
<fabbione> at least now you can get silo to install
<daniels> fabbione: yeah.  reason my bandwidth sucks so much right now (ask mjg59) is that I'm rsyncing down ubuntu-sparc now.
<HrdwrBoB> jdub: The Matrox HAL ("Hardware Abstraction Layer") is a special library 
<HrdwrBoB> to enable features not supported by the standard XFree86 driver. 
<HrdwrBoB> It's required for DualHead, TV output, and DVI support
<daniels> jdub: btw, we don't do smp stuff just because we can't fit it all into the cd
<daniels> aiui
<jdub> HrdwrBoB: i thought we did dualhead without hal?
<daniels> required for dual-head and dvi?  that's crap
<jdub> daniels: oh
<HrdwrBoB> jdub: apparently it adds more featuers and the original G400s need the hal module
<jdub> fabbione: no rsync for sparc.ubuntu.com?
<daniels> jdub: works for me
<daniels> jdub: rsync://sparc.ubuntu.com/ubuntu-sparc/
<HrdwrBoB> matrox do the same retarded license thing that ati do, they say you can't do all these things with the driver, and then give you code which is GPL'd
<daniels> mmm, ati's licence stuff is interesting
<daniels> basically, you can write code like this:
<daniels> /* Enable CRTC2 output. */
<daniels> OUTB(RADEON_CRTC2_GEN_CNTL, RADEON_CRTC_EN);
<daniels> but not like this:
<daniels> /* Writing 0x11 into MMIO:0x443F enables the second CRTC. */
<daniels> OUTB(RADEON_CRTC2_GEN_CNTL, RADEON_CRTC_EN);
<daniels> go figure
<HrdwrBoB>  weird
<fabbione> jdub: yes.. there is rsync.. as daniels said
<fabbione> daniels: ok
<daniels> the only thing stopping tv out support is someone with time (not me), motivation (uncertain), specs (me), and hardware (me)
<fabbione> jdub, daniels: in anycase.. boot with a DEBCONF_PRIORITY=medium
<daniels> fabbione: heh, ok
<fabbione> you need to be able to tell choose-mirror to use one unofficial ones
<jdub> fabbione: the ramdisk stuff is fine now?
<fabbione> otherwise d-i will loop forever over there
<fabbione> jdub: it should be.. at least from the tests Kamion and I did
<fabbione> jdub: but i could only check the netinst
<jdub> fabbione: d'oh, still have ramdisk problems
<jdub> fabbione: what was the boot param again?
<fabbione> AHHH right
<fabbione> d-i hasn't been rebuilt
<jdub> oh
<jdub> is this going to work at all then?
<fabbione> jdub: i think we will need to wait for Kamion to upload a new d-i
<fabbione> silo will, but i am afraid that the rest is the same
<fabbione> otherwise.. wait..
<fabbione> i can do a local build
<fabbione> and upload only the mini.iso
<fabbione> it doesn't take long.. and i need to remember to setup the daily d-i
<sivang> morning all!
<infinity> I can't believe I had to register just to download Matrox's binary-only driver.  Ugh.
<daniels> infinity: SOLD YOUR SOUL.
<daniels> infinity: if you want any of a series of crappy video cards, let me know
<daniels> infinity: my radeon 9000 (agp, dvi+crt) is all yours if you want it
<infinity> My GF6800GT makes me happy, currently.
<daniels> infinity: http://amnesiac.heapspace.net/~daniel/cards.html, plus a fair few more esoteric ones that have just arrived
<infinity> But if I build a second machine...
<infinity> I was grabbing the Matrox drivers specifically pursuant to the conversation up there.
<infinity> Is that IBM an ATI-based FireGL?
<daniels> ATI OEMed it; it's not actually an ATI chip.
* infinity notes in the "need" list that he used to have a miniITX board with via videa.
<daniels> We don't have *any* docs on that one, and IBM won't give us any.
<infinity> Hence why I submitted the via-on-XF86 patch to Debian.
<infinity> Not an ATI chip?.. How old is it?
<daniels> Pretty old.
<infinity> I though all FireGL products in the last 2 or 3 years were Radeon-based.
<infinity> Oh.  If it's ancient, it might be whatever was on the old Diamond FireGL cards.
<infinity> Which was very not ATI.
<daniels> Probably.  It was done by FGL Graphics, who were an S3 subsiduary (and the origin of fglrx), so Diamond doing it totally isn't out of the question.
<daniels> The board says  2000.
<infinity> Yeah, that'd be a Diamond FireGL, then.
<infinity> IBM logo notwithstanding. :)
<infinity> I used a few of those when I was doing sysadmin work at a place that was heavy in CAD/CAM.
<daniels> As I said, it's an ATI OEM.
<daniels> Well, I have one here, and it's currently a $50 VESA card.
<infinity> That's probably al it'd ever be at this point anyway.
<infinity> Video cards have come so far in 5 years, who'd want support for olf ones (beyond "something on the screen")
<daniels> One of the DRI guys, in particular, wants DRI supporting every 3D-capable card ever.
<daniels> So one of the conditions of him sending me the imstt (iXmicro) was that I'd have to write the DRI driver if he ever happened upon the data sheet.
<daniels> He's trying to get datasheets out of #9, FFS.
<infinity> daniels : That's sick.
<infinity> daniels : And not in the Australian sense.
<Treenaks> daniels: I saw Siliconmotion datasheets linked on the DRI wiki
<daniels> Treenaks: yeah, SMI themselves are donating drivers
<daniels> i don't think anyone actually owns siliconmotion hardware, though.
<daniels> I know I don't, and I've been looking.
<Treenaks> daniels: well, I have that laptop ;)
<AndyFitz> anyone going to linux.conf.au ?
<daniels> Treenaks: if you want to give it to me, sure ...
<Treenaks> daniels: when I have a new laptop ;) it's my primary workstation atm :)
<lifeless> AndyFitz: yah
<lifeless> AndyFitz: many
<Treenaks> daniels: (s/primary/only/)
<AndyFitz> lifeless,  awesome.  It will be my first linux.conf.au  ( I missed the one here in brisbane )
<fabbione> jdub: people.u.c/~fabbione/mini.iso
<fabbione> that should do
<fabbione> you still need to boot with expert mode or a DEBCONF_PRIORITY=medium
<dholbach> good morning everyone!
<ajmitch> hi dholbach 
<daniels> seb128: yo, whattup
<seb128> morning
<seb128> daniels: hello!
<daniels> seb128: the gnome-keyboard-applet thing is craaaaaaaaaaaack
<seb128> daniels: oh ? you have pinged svu ?
<rubenv> dholbach: http://bugzilla.gnome.org/show_bug.cgi?id=165655 it's fixed :)
<seb128> daniels: is there a known issue with riva128/xorg in hoary ?
<daniels> seb128: i'm having a look at the keyboard stuff, haven't spoken to svu yet
<daniels> seb128: and yeah, it's resolved in my local tree
<seb128> k
<daniels> seb128: quick hack: sudo ln -s /usr/X11R6/lib/modules/drivers/riva128{,_drv}.o
<daniels> executive summary: nv is stupid
<seb128> k, thanks
<dholbach> rubenv: yes... oh that caused your ploblem... damn - we investigated in the wrong direction :-)
<dholbach> rubenv: i'm waiting for a fix release of bryan and i'll have a look, when gtkmm is complete in debian
<rubenv> dholbach: well, when I burned all ftp stuff from .recently-used, it worked
<rubenv> we were halfway the right way ;)
<dholbach> :-)
<ajmitch> ogra: another py package working
<rubenv> dholbach: the fix release has been released btw 
<pitti> Morning
<seb128> hey pitti 
<pitti> seb128: hey! Hmm, this time I'm awake later than you...
<dholbach> rubenv: you dont mean 0.1.4.1?
<seb128> pitti: you oversleep ? :p
<dholbach> rubenv: i'm waiting for 0.1.4.2 - it contains another issue i spotted on 64bit-systems and includes a better german translation (my first was lousy ;-))
<pitti> seb128: no, I hacked until 2 am
<seb128> me too :p
<ajmitch> heh
<dholbach> couldnt you sleep? :-)
<ajmitch> I had to stay up for the TB meeting which was 5AM :)
<amu> jdub: pong
<pitti> elmo: is it possible to sync from Debian/incoming? or shall I just upload exactly the same source package to Ubuntu?
<daniels> pitti: can't sync from incoming
<seb128> daniels: not true
<daniels> seb128: uh?
<seb128> sync from incoming is possible but elmo prefers from a mirror IIRC
<ogra> morning...
<ajmitch> hey ogra 
<dholbach> hai ogra :-)
<ogra> ajmitch: sorry, i havet looked at your packages yet, but will do it today :)
<ogra> dholbach: hey
<ajmitch> ogra: yeah, I haven't told you where I'm putting them yet :)
<ogra> ajmitch: i just saw your last msg....(just reading up the night ;) )
<ajmitch> yup
* ajmitch checks the specs on the box he's uploading to.. slow pile of junk :)
<mvo_> ping jdub 
<ajmitch> seb128: do you want to update mboxcheck-applet in universe, since it's your package? 
<seb128> what's broken ? python version ?
<ajmitch> yeah, only needs rebuilt & the changelog bumped 
<ajmitch> unlike others which have #!/usr/bin/python2.3 in the source
<seb128> k
<seb128> I'll update it
<pitti> Mithrand1r: did you hear anything bad about the new password algorithm in mailman?
<ajmitch> ogra: do you want the .orig.tar.gz & a Sources.gz file in the dir?
<ogra> ajmitch: the orig please
<ajmitch> ok, will take a little longer to upload :)
<ogra> ajmitch: then leave it, i can grab it from the archove
<ogra> archive even
<ajmitch> most of them are small anyway
<ajmitch> ogra: http://www.gnuenterprise.org/~ajmitch/debs/ubuntu
<ajmitch> there are others in the debs/other dir
<Mithrand1r> pitti: nope
<dholbach> i have a user stating, his warty-release-install-cd installation b0rks when it tries to add a user - instead of adding the user, it starts over again
<ajmitch> I've still got to clean up the (new) packaging for libgsf-cil & libevolution-cil
<pitti> Mithrandir: hmm, so maybe we can fix Warty now?
<ogra> ajmitch: distributuion unstable does not exist in ubuntu ;)
<ajmitch> ogra: which one?
<ogra> currently pyro....
<ajmitch> it's probably one I forgot to change since you looked
<ajmitch> yeah, that's right..
<ogra> ctypes too
<ajmitch> the other 3 ought to be ok for that..
<ogra> revelation is right 
* ajmitch rebuilds, reuploads pyro
<Mithrandir> pitti: I really don't see the need.  The "passwords" are sent in cleartext across the network, they aren't passwords and should never have been labeled as such
<ogra> webcheck and viewcvs look ok too
<ajmitch> revelation, webcheck & viewcvs I did tonight
<ogra> ah, ok... at a first glance they look good....
<elmo> pitti: please don't ever upload where a sync is possible
<elmo> just send me mail and I'll either do it from incoming or do it when it hits a public mirror, depending on urgency
<pitti> elmo: okay, then I wait until after today's Debian katie run
<ajmitch> ogra: I'd hold back on ctypes for now, until I test it with 2.4
<ogra> ok
<pitti> elmo: so sync from incoming _is_ possible? it's a relatively severe PostgreSQL security fix
<ajmitch> ogra: it just failed one of the unittests in the package
<ogra> oh
<ajmitch> yeah :)
<ajmitch> since it dives into python internals
* ajmitch looks for a new upstream release
<YokoZar> Somehow when I'm building my package it's not generating a debian/files file
<YokoZar> When/where is this done?
<elmo> pitti: yes, it's possible
<pitti> elmo: cool, can you please sync postgresql 7.4.7-1? mdz blessed it
<elmo> I can sync anything with a pulse^W.dsc
<dholbach> ogra: would you upload timer-applet-0.5.1 for me? :-)
<seb128> elmo: gazpacho sync please :)
<ogra> dholbach: extensively tested ?
<ajmitch> ogra: any objections to me packaging ctypes 0.9.2, when 0.6.3 is current in universe? :)
<dholbach> ogra: yes... pbuilder did fine, rebuilt and reinstalled it, to check new functionality
<ogra> ajmitch: not really....but waht about the sid version ?
<ogra> dholbach: i'll do a testbuild and upload it then...
<dholbach> ogra: thankssssssssss :-)
<ajmitch> ogra: I'd preferably send my packaged version to the sid maintainer
<ogra> ajmitch: i he takes it... did you contact him/her ?
<ogra> if even
<ajmitch> no, I only just found that upstream is far ahead of debian just earlier
* ajmitch might leave it for now then
* dholbach ->shower
<YokoZar> ogra: Can we talk about MOTUness?
<ajmitch> ogra: I'm going for the low-hanging fruit for now, doing python-irclib
<ogra> ajmitch: thats a good start :) for learning its way easier to pick a small package (and it keeps my effort low, thanks)
<ogra> YokoZar: what do you want to know ?
<YokoZar> Well, what I need to do next, mostly.  I've got my wine package ready for upload (will have another with the next wine release in a couple weeks), and I'm almost done with the winetools package.  I've got a wiki page too.
<elmo> Kamion: ?
<ogra> YokoZar: did you talk to upstream about your package ? 
<YokoZar> I am upstream :)
<ogra> upstream = debian
<sivang> seb128: what's gazpacho's pkg name? 
<seb128> sivang: gazpacho
<seb128> sivang: why ?
<sivang> seb128: :)
<YokoZar> Yeah.  I've been trying to get him to update the package for months now, or turn over maintainership.  He hasn't done anything, and it got to the point where we've been mirroring our own apt repository at winehq.  It got quite annoying telling every Debian user to install from source
<ajmitch> ogra: learning isn't too much of a problem, I'm nearly finished in the NM queue for debian, and maintain ~10 packages in sid :)
<ogra> YokoZar: we want to aviod drifting to far apart from dbian, so its always desirable to have fixes committed upstream.... wine is a quite essential package for many people. (in debian too)
<jdub> ogra: one of the reasons i encouraged YokoZar to get involved was the lack of good wine packages in debian
<marcin_ant> jdub: hi!
<azeem> # [2005-01-30]  Accepted wine 0.0.20041019-1 (i386 source all) 
<YokoZar> Yup.  And that version is 3 months out of date already :)
<ogra> jdub: ah, ok... i didnt follow very much the last days (hal kept me quite busy)
<YokoZar> ogra: Yeah, and it's tragic.  But unless someone wants to crazy NMU my package there's really nothing I can do.  Ove's been away from Wine ever since he left to work for Transgaming.  I'm not sure why he hasn't given up maintainership.
<marcin_ant> jdub: any news about Website Look'n'Feel Competition?
<azeem>    * Mention Scott Ritchie's Wine packages in README.Debian.
<azeem>      Since I have been sick a lot lately, I have not had time
<azeem>      to review these packages yet, but I can at least mention
<azeem>      them. After I bring the current Debian packages up to
<azeem>      date, I'll review his packages, and if I like them, I may
<azeem>      turn over maintainership to him. Until then, I'm only
<azeem>      mentioning his packages with caution.
<sivang> seb128: wanted to install on my system :)
<sivang> seb128: and couldn't finmd the package by that name befoire
<seb128> sivang: apt-cache search gazpacho ...
<seb128> jdub: hey hey :)
<azeem> YokoZar: I wondered what would become of the wine packages when I heard Transgaming were forking it, but I had the impression he kept up maintaining them at some level
<ogra> YokoZar: anyway, wine is a protion to big for me, as i'm still practicing package review myself, for a package of this size please contact haggai
<azeem> (though I don't really follow closely)
<YokoZar> azeem: That's encouraging.  The trouble is that we're releasing them faster than he can update em.
<sivang> jdub: no , seb is right, but I really couldn't find the pkg :) I wonder if I was seraching for the right word :)
<ajmitch> ogra: btw, azeem can vouch for me, he's had the misfortune of sponsoring my package uploads :)
<YokoZar> ogra: Err...too big?  Ok, I'll talk with haggai.  Can you help me with the (much smaller) winetools?  I'm still having this strange problem of no debian/files being generated by debhelper
<ogra> ajmitch: unfortunately azeem is not a MOTU (yet?)
<ajmitch> ogra: I know that, but he's a DD
<ogra> ajmitch: which gives him neither CC nor TB nor MOTU voting rights....
<ajmitch> ogra: I'm not referring to formal procedures
<jdub> marcin_ant: not yet, no
<jdub> sivang: ?
<fabbione> jdub: got the message before?
<jdub> fabbione: nup
<fabbione> people.u.c/~fabbione/mini.iso
<ajmitch> jdub: how's beagle looking?
<fabbione> either you install from sparc.u.c or you need to be sure to have your local mirror in sync (libc6 upgrade)
<ajmitch> I've got gsf-sharp working
<jdub> ajmitch: cool
<sivang> jdub: disregard, EWRONGCONTEXT :)
<marcin_ant> jdub: ok I understand that you are busy etc. , but culd you at least confirm that you got my submissions?
<ajmitch> halfway done on evo-sharp
<jdub> ajmitch: it works, but needs depends love to actually buildd ;)
<jdub> marcin_ant: i have
<ajmitch> jdub: I can give it some loving if you'd like :)
<ajmitch> depends on how hairy it is
<maswan> fabbione: Oh, I saw you(?) got assigned my ravel bug (mptfusion). Want me to test the latest hoary kernel? I haven't managed to build one myself that gives console output or boots properly, the machine is somewhat weird.
<marcin_ant> jdub: ok - thanks for info :)
<mvo_> jdub: are you aware of any problems with the latest gamin when it comes to monitoring a single file for changes?
<jdub> mvo_: hrm, not really
<marcin_ant> jdub: are there beagle packages available?
<jdub> marcin_ant: no
<fabbione> maswan: i got reassigned 50 bugs in a shot... so no.. i don't even know which bug it is...
<fabbione> maswan: i am going trough them slowly
<mvo_> jdub: hrm, ok ... it looks like it does no longer tell me about changes on a file (it monitors directories correctly though). I file I bug with a test-case
<maswan> fabbione: Ah, ok.
<fabbione> maswan: but yes.. test and let me know. that will save me a NEEDINFO
<dholbach> hmmm, why was ubuntu-calendar-february just built for i386?
<ajmitch> ogra: what's your limit on reviewing packages, size-wise? :)
<maswan> fabbione: the hoary install kernel is 2.6.10 too, right?
<fabbione> maswan: yes
* maswan nods and goes downloading
<elmo> dholbach: because it's arch: all
<jdub> fabbione: looks like a successful hoary/sparc install :)
<dholbach> elmo: ah, alright
<seb128> jdub: gamin doesn't work fine, have you noticed that ?
<ajmitch> ogra: uploading pnet for review in a minute
<seb128> (or that's just me ?)
<jdub> fabbione: though i'm not in the sudoers file... (but i was at medium debconf priority, which confused things)
<jdub> seb128: works ok here
<fabbione> jdub: TOTALLY RAD!
<seb128> jdub: if you remove/add menu-xdg do you get the debian submenu changed ?
<jdub> seb128: hrm, will test in a bit
<ajmitch> ogra: you have a choice between reviewing 0.6.10 or 0.6.12 :)
<dholbach> ogra: is there already someone working on monkey-journal?
<seb128> jdub: and the inotify crash is still here :/ (I've crashed while playing with nautilus yesterday)
<jdub> yeah :|
<ogra> dholbach: nope, i dont think so .... you moniitor the UniverseCandidates page ?
<dholbach> ogra: unregularly, yes
<jdub> hrm, my U5 is surprisingly noisy
<ogra> dholbach: if you stumble over nice software... feel free to add it
<dholbach> ogra: right
<jdub> we should totally get rid of net-tools
<jdub> hrm
<jdub> that's a bit harsh
<Simira> morning jdub
<jdub> we should totally not ship ifconfig
<bob2> haha
<bob2> port everything to iproute, first
* rubenv fights for netstat with his life
<YokoZar> Why don't we just switch everything to appletalk?
<jdub> fabbione: dude, what is with ubuntu-desktop on sparc?
<fabbione> i am on the phone..
<fabbione> right a sec
<YokoZar> Also, all images should be in AOL's .art format.
<rubenv> YokoZar: don't forget converting all docs to WordPerfect 5
* dholbach uses the big red button on his deks to open a trapdoor under rubenv's and YokoZar's feet
<fabbione> seb128: i am building test packages to check the new inotify with debugging enabled.
<fabbione> jdub: what is the problem with ubuntu-desktop?
<seb128> fabbione: k
<fabbione> jdub: we still don't have ubuntu-meta.. so that might be a problem
<jdub> fabbione: aha
<jdub> fabbione: ubuntu-desktop installs, but doesn't have any depends ;)
<jdub> fabbione: entertaining ;)
<fabbione> ah because it's an old version
<fabbione> nah.. i knew about it..
<fabbione> i need to get it fixed
<ajmitch> ogra: pnet 0.6.10 is up
<seb128> jdub: I've a patch from Scott to had the gtk bookmarks to the nautilus places menu (in the spatial mode) ... what do you think about including it ?
<fabbione> jdub: as soon as we can get choose-mirror to do the right thing, we will be able to go DEBCONF_PRIORITY=high
<fabbione> jdub: so that should fix the sudo stuff
<fabbione> jdub: i still have one issue with the serial console and no-head to look at + ubuntu-meta
<doko> hi all
<fabbione> given these 3 bits get fixed, we can for sure go live
<jdub> seb128: EXCELLENT
<jdub> fabbione: how soon do you think you'd have a livecd?
<jdub> fabbione: so with base installed, it works very nicely
<YokoZar> Does the warty application's menu work with packages using .menu type objects immediately after installing, or does it require a login/out?
<sivang> seb128: do we have a patch to make g-s-t recognize it's on ubuntu in all the modules?
<sivang> seb128: I've seen something to remove the warning on the patches debian dir, not sure if this is connected.
<seb128> sivang: I don't get the question
<seb128> sivang: you get a message saying that the distro is not recognized ?
<jdub> fabbione: heh, i'll have to put it on the 220R next :-)
<sivang> seb128: no, it's ok, I just wanted to know how the patch is going, I'll look in its code then, basically I want to know if it makes sense to add upstream code to make it know it's on ubuntu like it does for the other distros.
<fabbione> jdub: i dunno yet. i want to have installable at least, before asking Kamion/lamont/mdz to produce CD's
<seb128> sivang: that's debian/patches/05_ubuntu-no-warning.dpatch
<fabbione> jdub: we don't know yet if X will do the right thing, even if i have been careful when we switched from xfree to xorg
<seb128> sivang: it should be listed as a debian
<jdub> fabbione: got some evms b0rkage in my boot output, want me to relay, or do you know about it?
<fabbione> jdub: it's normal
<jdub> ok
<fabbione> evms problem with 64 bit kernels
<fabbione> missing ioctl
<fabbione> but it works fine
<jdub> heh, all my machines have (almost) public ipv6 addresses now :-)
<sivang> seb128: ok, then it would be redundent code :) tnx
<fabbione> jdub: i did for the last 4 years :)
<jdub> fabbione: for your firewall, do you use iptables directly, or a helper tool?
<fabbione> iptables directly
<fabbione> there is no tool out there that can get my config right and sane
<jdub> mmm
<jdub> using shorewall atm
<jdub> but it isn't particularly ipv6 friendly
<fabbione> none of the tools i know of, are capable of handling ipv6 properly
<jdub> bummer
<abelli> sladen: ding
<elmo> pitti, seb128: done
<pitti> thanks
<seb128> thanks
<sladen> abelli: pong
<abelli> sladen: have you seen simplymepis's tricky fb?
<sladen> abelli: nope.  Tell me more
<abelli> ive just seen it on a magazine..
<abelli> it has something like an image in the background
<ajmitch> elmo: can the dependencies of zope-cmfplone be imported into universe?
<elmo> ajmitch: err, where from?
<ajmitch> elmo: sid
<ajmitch> it seems that the cmf1.4 packages weren't imported
<elmo> ajmitch: I need an explicit list of source packages to sync
<ajmitch> ok, just a minute
<elmo> everything from sid is imported into universe - the only reason it wouldn't have been is if it's NEW since the upstream version freeze
<ajmitch> the freeze probably happened during a zope/plone breakage in sid
<ajmitch> looks like that was the case
<Alessio> install zope/plone
<fabbione> jdub: d-i phase0 is GO here too :-)
<YokoZar> Ok, I finished my winetools package
<Alessio> give mismatch error
<YokoZar> Do I have a guinea pig?
<Alessio> plone 1.0.5 ; zope  2.6.4-1.1
<ajmitch> elmo: zope-cmf1.4 zope-cmfcore1.4 zope-cmfdefault1.4 zope-cmftopic1.4 zope-cmfcalendar1.4 zope-dcworkflow zope-cmfactionicons zope-cmfquickinstallertool zope-groupuserfolder zope-cmfformcontroller zope-plonetranslations
<ajmitch> those are the ones that are said to be uninstallable
<Alessio> is there plone 2.0 in hoary?
<elmo> ajmitch: source packages, pls
<elmo> ajmitch: and please get sign off from a MOTMOTU
<ajmitch> source packages are zope-cmf1.4 zope-cmfactionicons zope-cmfquickinstallertool zope-groupuserfolder zope-cmfformcontroller zope-plonetranslations
<ajmitch> and the MOTMOTU just went off to work
<ajmitch> unless haggai is around
<YokoZar> jdub: If you want to try the winetools package to go along with wine, it's on the winehq apt repository now.
<YokoZar> Point and click installation of internet explorer!  Just what linux needs!
<ajmitch> mdz: I see a post on u-user by you about not being able to resize ext3 - I've got an updated ext2online deb that works for this that could possibly go into universe
<ajmitch> s/ext2online/ext2resize/
<Hwolf> Yokozar: Yuk on that!
<maswan> fabbione: Ok, pretty much the same problem (except I had to modprobe mptscsih manually before getting to the real problem). Let me know if you have time to talk about it.
<fabbione> maswan: can you at least tell me the bug number?
* ajmitch sleeps
<maswan> fabbione: 2287
<maswan> short summary: mptfusion disk, after partitioning when writing filesystem, it won't finish, and dmesg logs stuff like this:
<maswan> mptbase: ioc0: LogInfo(0x11070000): F/W: DMA Error
<maswan> mptbase: ioc0: IOCStatus(0x004b): SCSI IOC Terminated
<maswan> lots and lots of those
<fabbione> maswan: you have been asked with a dmesg of both the working and non working kernel, Herbert did ask you to test with a plain 2.6.8.1
<fabbione> did you do these tests?
<fabbione> can you kindly add all the info in the bug?
<maswan> fabbione: Yes, I have been trying to do tests with a plain kernel, but I'm having trouble with that. I can't seem to manage to build one that gives me console output or boots far enough to get network.
<fabbione> compile everything inline
<fabbione> no modules, no initrd
<fabbione> maswan: does that box boot from ide or directly from the scsi?
<maswan> fabbione: from the scsi, that's the only disk in it
<fabbione> if so can you manage to boot a working system from another disk and give me access to it?
<maswan> I can give you access to the system running on the latest working kernel I have, yes.
<maswan> Can you send a gpg-signed email with ssh key to maswan@acc.umu.se, I'll add you. This is the inofficial debian amd64 devel machine btw.
<fabbione> maswan: ok, but it's not priority 1 for me atm
* maswan remembers that it boots the wrong kernel by default and will be right back
<fabbione> i will do as soon as i can spend sometime on it
<maswan> fabbione: ACK
<fabbione> maswan: it would really help if you can stick a normal hd in there where to boot from
<fabbione> to test a fix i need to be able to rmmod and modprobe the dirver
<fabbione> driver
<fabbione> and it doesn't help booting from it
<elmo> libGL warning: 3D driver claims to not support visual 0x23
<elmo> meh?
<fabbione> elmo: that means that your video card sucks hard
<maswan> fabbione: Well, there are no ide hdd spaces.
<elmo> 0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01)
<fabbione> maswan: usb?
<maswan> fabbione: it is a 1U server with two scsi hotswap slots on the mpt.
<maswan> hmm.. yeah, it has usb, that's true.
<fabbione> elmo: right.. that sucks even more :O
<elmo> fabbione: bah
* maswan ponders if he has any usb storage
<maswan> I'll look into that
<fabbione> maswan: the problem is that i can't test a kernel without being able to a) reboot b) recover from crash
<fabbione> elmo: check irc logs from this morning.. someone was discussing Matrox 3D thingy
<pitti> mvo_: why does the update-notifier icon tell me I have 15 updates available, and if I open it, it claims that my system is up-to-date?
<pitti> mvo_: (my system _is_ up-to-date, btw)
<Mithrandir> maswan: if you have a remote power thingy on it, lilo -R should be enough for fabio to test.
<maswan> fabbione: I'll get Mithrandir to go over a kernel config too, since I might be missing something. :)
<fabbione> maswan: it is ok, but please add all these stuff to the bug
<fabbione> maswan: i am not going to maintain the kernel forever
<maswan> fabbione: Yeah, I'll write up a comment.
<fabbione> and who will come after me must be able to keep going
<Mithrandir> thom: what did we end up with wrt NM or replacement love?
<fabbione> seb128: what kernel do you need to test inotify?
<mvo_> pitti: I think because of #6088 (gamin problem)
<thom> Mithrandir: netapplet
<thom> as NetworkMagic pages says :-)
<mvo_> seb128: ping?
<seb128> fabbione: ?
<seb128> fabbione: i386 if that's the question
<seb128> mvo_: pong ?
<fabbione> seb128: flavour? k7? 686?
<seb128> k7
<carlos> mvo_: hmmm, the modem_applet bt is for Carlos Garnacho, right?
<carlos> mvo_: you sent it to me...
<carlos> mvo_: carlosg@gnome.org is his email address, carlos@gnome.org is mine ;-)
<seb128> carlos: stop talking and fix the bug dude !
<ogra> hehe
<carlos> seb128: lalala
<mvo_> carolos: haha :) can you please forward it to him
<carlos> sure
<mvo_> I send you another one a minute ago
<seb128> mvo_: pong pong :p
<mvo_> seb128: I just wanted to ask if we have a debug version of the applets and found it out myself :)
<seb128> k
<seb128> mvo_: BTW have you looked on the translations for update-notifier ?
<mvo_> seb128: yes, thanks. should work now. also i have a problem with the menu not translatable. I'll check that later (it's a bit strange)
<seb128> k, cool
<mvo_> seb128: update-notifier is broken ATM because gamin seems to not tell me about changes in single files. have you seen that with nautilus too ?
<seb128> mvo_: I've got some bugs about notify issues, ie: http://bugzilla.ubuntu.com/show_bug.cgi?id=6086
<seb128> and the panel is not updated (if you add the debian menu by example)
<dholbach> seb128: both libgtkhtml3.1-dev and libgtkhtml3.2-dev provide /usr/lib/pkgconfig/libgtkhtml-3.1.pc - do you know if this intended?
<mvo_> seb128: I wonder if going back to gamin 0.0.20 fixes the problem for the user. it did for my test-case (#6088)
<dholbach> seb128: oh... there is a "conflicts:", alright - so i'll just build-depend on libgtkhtml3.2-dev
<seb128> dholbach: libgtkhtml3.6-dev is the current version dunno about the old stuff, they should be removed
<seb128> mvo_: there is a gamin 0.22 too (jdub has not packaged it yet)
<seb128> perhaps you could try with it ?
<seb128> mvo_: do you have a link with the 0.0.20 ?
<mvo_> seb128: cool, thanks. I'll dl it and see if it helps
<mvo_> seb128: I took it from my /var/cache/apt/archives :)
<mvo_> I'll quickly check out 0.0.22 first and if that fails too I can put the 0.0.20 online 
<seb128> mvo_: do you get #6086 ?
<mvo_> seb128: yes, I see this too (but haven't checked yet if 0.0.20 fixes the problem)
<seb128> weird, that works fine with 0.21 here
<dholbach> seb128: thanks... i'll tell upstream
<mvo_> seb128: don't take it for granted :) I'll do a clean test later. monitoring directories seems to work in my test-case (only single files are a problem it seems)
<Kamion> elmo: pong
<seb128> mvo_: could you upload the 0.0.20 deb somewhere ? I would like to try the panel with it now :p
<elmo> Kamion: usbutils dropped it's -udeb in the recent sync; is that going to be a problem?
<Kamion> elmo: er, uh-huh, YEAH
<mvo_> seb128: they are on people.u.c/~mvo
<seb128> mvo_: thanks
<Kamion> elmo: I'll fix it
<Mithrandir> do we have to get exceptions for universe syncs?
<mvo_> seb128: http://people.u.c/~mvo that is
<Mithrandir> or can they just be requested?
<elmo> Mithrandir: not needed for universe
<seb128> Mithrandir: any progress on the libdb issue on amd64 ?
<Mithrandir> elmo: thanks.
<Mithrandir> seb128: sorry, haven't had the time to look at it yet.
<seb128> do you know if you'll have time soon ? evolution* just crash on amd64 for the moment, that seems to bother amd64 users :)
<dholbach> Mithrandir: seb128 is a bit euphemistic there - ogra would simply love you for fixing it :-)
<seb128> mvo_: 0.0.20 doesn't work better with the panel apparently
<Mithrandir> seb128: give me a few minutes to get a gcc and a kernel compile started and I'll look at it.
<seb128> thanks
<mvo_> seb128: I'm away for a couple of minutes to have lunch, than I'll check out 0.0.22
<seb128> mvo_: k, have a good lunch :
<seb128> :)
<fabbione> seb128: people.u.c/~fabbione/inotify/
<fabbione> seb128: it contains the debugging version of inotify.. can you check if you still get the crash with it?
<fabbione> also.. it has a new soname = reboot mandatory
<fabbione> and it is a newer version of the patch, so it might work
<fabbione> if it crash, it should print crap all over the place
<fabbione> dmesg/logs and so on..
<seb128> fabbione: ok
<fabbione> seb128: thanks
<seb128> np
<fabbione> ps if you can test it ASAP is better :-)
<lamont> Kamion: any reason you can think of why the ia64 livecd boots into the partitioner?
<fabbione> hey lamont 
<Kamion> lamont: didn't mdz answer that? no bootloader-fu
<fabbione> lamont: do you want to send me your ssh public key? so i can setup the access to the sparc buildd?
<Kamion> lamont: try booting with casper/enable=true
<lamont> Kamion: didn't see his answer...
<lamont> Kamion: ok
<lamont> fabbione: will today
<fabbione> lamont
<fabbione> lamont: no rush!
<fabbione> Kamion: yo..
<fabbione> Kamion: 2 success reported for sparc.. we need to fix choose-mirror :(
<Kamion> lamont: unfortunately it's fiddly to fix because debian-cd just takes a boot.img from debian-installer; unlike our other architectures, debian-cd doesn't have its own bootloader configuration
<Kamion> fabbione: no sabdfl at the moment, I'll try to remember when he next appears
<fabbione> Kamion: roger.. that's 33% of the showstoppers for release...
<fabbione> Kamion: i also prepared an update for ubuntu-meta to include sparc
<Kamion> lamont: actually, you need casper/enable=true casper-udeb/snapshot/backing-file=/cdrom/casper/filesystem.cloop
<lamont> amd74xx module must die.
<fabbione> and i need to investigate the prebase-config thingy.. mind to remind me what package does it?
<Kamion> fabbione: generic? (i.e. does it fix the update script to look at sparc.ubuntu.com?)
<Kamion> lamont: how is amd74xx being loaded? it's not hardwired in hw-detect or anything.
<fabbione> Kamion: yes.. i modified the update script
<Kamion> fabbione: that would be prebaseconfig. What exactly do you mean?
<Kamion> lamont: try 'grep amd74xx /var/log/syslog' ...
<fabbione> Kamion: the problem with the inittab.. it works for people with a monitor.. but it is kinda broken (compared to debian) on headless
<Kamion> prebaseconfig, then
<fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/umeta.diff <- ugly patch that works
<Kamion> ok
<fabbione> that creates base-sparc and desktop-sparc
<fabbione> they look ok...
<lamont> Kamion: not sure - need to run the kids to school.  it's being loaded with 'modprobe -v amd74xx', and it's fatal
<lamont> the first two times, you just hit return to the error dialog.  The third time, casper, uh, gives up the ghost.
* lamont must take kids to school
<smurfix> Kamion: Is there a quick way to get an untranslated template string from cdebconf?
<smurfix> Kamion: I need that for translating a keymap name back to a localized string
<Kamion> lamont: please try to find why it's being loaded, because it isn't hardwired as far as I can see
<Kamion> smurfix: see the pile of grotty code in kbd-chooser.
<Kamion> smurfix: this is one bit of debconf I really don't know well, though, I'm afraid
<fabbione> ahhh
<fabbione> hmmm
<fabbione> i think the problem with serial is the switching with udev at installation time..
<elmo> umm, am I going insane, or is per-window/desktop num-lock something new?
<smurfix> Kamion: ... which doesn't actually do what it thinks it's doing. debconf_metaget(...,"Description") returns the same thing debconf_metaget(...,"Description-de.UTF-8") returns, i.e. the translated string
<smurfix> Kamion: My problem is that I want to translate de-latin1-nodeadkeys back to "Deutsch". That text only occurs in the template's Choices: list. I don't really want to split that into heaps of separate text templates
<Kamion> smurfix: I'd suggest asking on #debian-boot; fjp might know, or joeyh
<fabbione> Kamion: thanks for the hint.. i found the bug in prebaseconfig
<fabbione> Kamion: basically the console detection still relies on devfs
<fabbione> and we get it wrong
<fabbione>     console=$(mapdevfs "$rawconsole")
<fabbione> for general case works fine.. but it misdetect the serial ones :-)
<jbailey> Just looking in BugTracking and Uploads and don't see it - do we have anything similar to the (Closes: ####) syntax of debugs?
<elmo> jbailey: nope
<jbailey> elmo: Tx.
<elmo> if someone wants to patch katie to do XML-RPC to bugzilla (or however it is you're meant to talk to it) ... ;-)
<jbailey> I think it's XML-RPC.  What language is katie written in?
<fabbione> elmo: kill bugzilla
<fabbione> :-)
<fabbione> and install debbugs.. nobody is watching now!
<mjg59> fabbione: Hrm. We really need to track down this ACPI problem.
<fabbione> mjg59: really?
<mjg59> Several machines have no battery status at the moment
<fabbione> mjg59: i agreed with mdz to pull in a 2.6.11-rc2-bkX kernel in hoary/universe
<fabbione> so we can see if upstream is fixed or not
<elmo> jbailey: grotty python - you don't really need to actually patch katie tho, just give me a function that'll close the given bug numbers with the given text
<fabbione> also for other subsystems
<fabbione> like ACPI/USB/ACPI/alsa/ACPI
<elmo> jbailey: and I dunno that it's worth spending time on, since the long term goal is malone
<mjg59> fabbione: Worth a go
<fabbione> mjg59: i am going to work on them tomorrow
<jbailey> elmo: 'kay.  If I can do it very quickly, I'll send it to you, otherwise I won't worry about it.
<fabbione> but it will be kernel team task to handle the rest
<Mithrandir> fabbione: I got a plain 2.6.10 booting on ravel now, so it's _something_, _somewhere_ which causes the mpt thing to fall over.  Haven't tested any real I/O yet, though.
<fabbione> Mithrandir: NICE!
<seb128> fabbione: this kernel just crash (tm)
<seb128> kernel_thread_helper
<fabbione> mjg59: i did send an invitation for a meeting next week
<zul> hello
<fabbione> seb128: where does it crash? does it boot?
<seb128> no
<seb128> it crash 1 sec after grub
<fabbione> seb128: or still the inotify stuff?
<fabbione> that's cool!
<seb128> not really :p
<Treenaks> GTK bug!
<fabbione> seb128: sillt k7, right?
<seb128> correct
<mjg59> fabbione: Yeah, saw that
<Mithrandir> seb128: I'm surprised e-d-s haven't fallen over in random ways due to linking against both 4.1 and 4.2 yet.
<Kamion> fabbione: ah. what is $rawconsole?
<mjg59> fabbione: Ok, http://bugzilla.kernel.org/show_bug.cgi?id=4097 says the latest ACPI patch fixes stuff
<seb128> Mithrandir: yep, and now it would be nice to get if fixed before that happens :p
<mjg59> Any chance of pulling that in for the next 2.6.10?
<Mithrandir> seb128: I'm just reverting to use 4.1, but the system-wide 4.1 instead of the local 4.1
* Mithrandir looks at e-d-s installing shit into lib64 and eeeew
<Kamion> fabbione: note that mapdevfs is not actually devfs-specific, despite the name; it doesn't look at the source path, it looks at the major/minor numbers
<seb128> Mithrandir: k, thanks
<Kamion> fabbione: so don't assume that stuff that uses mapdevfs still relies on devfs - that code is part of the essential compatibility layer :)
<fabbione> Kamion: rawconsole is the device.. like /dev/ttyS0
<Kamion> fabbione: no I mean what is its value when you run that
* Mithrandir is kinda surprised mapdevfs is still around.. it was just a quick hack.
<fabbione> mjg59: yes, please send me a patch or something..
<Kamion>     inst_pid=$(pidof debian-installer | cut -d" " -f1)
<Kamion>     rawconsole=$(readlink /proc/${inst_pid}/fd/0)
<fabbione> Kamion: vultus5:~# rawconsole=$(readlink /proc/1084/fd/0)
<fabbione> vultus5:~# echo $rawconsole
<fabbione>  /dev/ttyS0
<Kamion> fabbione: ls -l /dev/ttyS0?
<mjg59> fabbione: It's probably best to go with the whole thing. They've done the usual thing of not splitting up the acpi-ca patchset (which is the important bit)
<fabbione> i don't have the machine in d-i mode now...
<Kamion> fabbione: ok, please try that during your next install test
<fabbione> Kamion: i will have to look at it again
<fabbione> Kamion: sure..
<fabbione> mjg59: is it already in linux-2.6 tree?
<mjg59> fabbione: Linus's? Should be
<pitti> lamont: ping
<fabbione> mjg59: can you please check?
<mjg59> fabbione: Ok
<fabbione> i am really overloaded and you are teh ACPI master here
<mjg59> Sure
<fabbione> cool
<mjg59> http://linux.bkbits.net:8080/linux-2.6/cset@1.1938.498.8
<Kamion> fabbione: BTW, what console= do you boot with?
<mjg59> Is the acpi-ca changes without the rest of the diff
<mjg59> fabbione: Skimming the full patch from the bug (http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.10/acpi-20050125-2.6.10.diff.gz) I think we probably want all of it
<mjg59> I'll figure out which patches we carry that can be dropped and replaced by that one
<carlos> mvo_: around?
<fabbione> Kamion: none.. i never had to add console= in debian.
<Kamion> ok
<fabbione> mjg59: thanks.. 
<Kamion> fabbione: also please check whether /dev/ttyS* actually exists in d-i :-)
<Kamion> should do, udev is configured to create those
<Kamion> at least, I think ...
<fabbione> Kamion: ok.. but i think they are there.. everything work until immediatly after base-config
<Kamion> I mean whether it's called /dev/ttyS0 or /dev/tts/0
<Kamion> (or similar)
<Kamion> if the latter, everything would work except prebaseconfig
<fabbione> Kamion: right..
<fabbione> i will check when i can do another install test.. probably tomorrow..
<fabbione> right now it's building pitti's crack
<fabbione> seb128: i am preparing a stripped k7 kernel for you..
<Kamion> at any rate whatever $rawconsole comes out as needs to exist, and I need to know what mapdevfs "$rawconsole" says.
<seb128> fabbione: k
<fabbione> Kamion: gotcha :-)
<fabbione> Kamion: what provides mapdevfs?
<fabbione> is that some busybox hack?
<Mithrandir> fabbione: nah, something I wrote, it's not in busybox.
<fabbione> Mithrandir: where is it?
<Mithrandir> di-utils-mapdevfs
<fabbione> ok
<Kamion> debian-installer-utils source package, via libdebian-installer
<mvo_> carlos: yes
<carlos> mvo_: could you remove the bu.po file from synaptic?
<mvo_> carlos: sure, why?
<carlos> mvo_: seems like someone added it by mistake, the right locale is bg.po
<carlos> mvo_: there is no bu language
<carlos> mvo_: and it's the same content than bg.po (but an older version)
<mvo_> carolos: thanks, it's gone
<carlos> mvo_: perfect, thank you
<pitti> fabbione: #1891 is a kernel bug that is by far too complex for me (and probably also for you)
<pitti> fabbione: however, keeping it assigned to me does not really make much sense
<pitti> fabbione: any idea what to do with it?
* sivang hides
<fabbione> pitti: close it
<pitti> fabbione: hmm, but the bug is real
<pitti> fabbione: it's just nothing that could be fixed by a poor small Ubuntu developer...
<zul> poor?
<fabbione>  [<c0105dfd>]  sysenter_past_esp+0x52/0x71
<fabbione> HMMM
<fabbione> this looks so much as the same error in the idiotify patch
<fabbione> seb128: new kernel is up
<mjg59> fabbione: Shall I mail you the details?
<mjg59> (summary: drop 3 patches, apply 1 new one)
<fabbione> mjg59: yes please...
<fabbione> i need to leave soon
<pitti> fabbione: hmm, this bug already existed before the word inotify even existed
<mjg59> fabbione: Ok
<fabbione> pitti: it still dies in the same place....
<fabbione> pitti: anyway.. i have no idea.. reassign it to me..
<seb128> fabbione: downloading it
<fabbione> one more or one less won't change my 3948398439 bugs due to ACPI/GTK/USB/ACPI/ALSA/ACPI
<fabbione> seb128: this one contains only the inotify patch
<fabbione> seb128: if it dies in this way..... 
<fabbione> JDUB?
<mjg59> fabbione: Mailed
<fabbione> mjg59: thanks
<fabbione> mjg59: that's easy.. how many will it fix?
<fabbione> bugs..
<zul> fabbione: your bugs are going down...a little
<fabbione> zul: uh?
<mjg59> fabbione: It deals with 5807
<mjg59> Which ought to fix a pile of sleep/wake bugs, too
<fabbione> mjg59: and nothing else?
<fabbione> ahhhh
<dholbach> bbl
<mjg59> Various _WAK methods have been broken because of it
<fabbione> mjg59: ok.. i will need to wait a day or two before i can upload
<Mithrandir> : tfheen@vawad(hoary) ~ > evolution
<Mithrandir> zsh: floating point exception  evolution
<fabbione> first to identify which of the 3 security patches that i added today makes Baby Jesus cry...
* Mithrandir snickers.
<mjg59> fabbione: No problem
<fabbione> and see if the new istupify patch works
<fabbione> if i only didn't have to go to church today....
<jbailey> Is it expected that rookery.ubuntu.com doesn't exist?
<tseng> fabbione: i absolve you of your sins. now back to work
<jbailey> tseng: Demand patches as penance!
<thom> Mithrandir: you've fixed that well, then ;-)
<pitti> fabbione: huh, I thought you still have 13 days of freedom^Wbachelor life?
<Mithrandir> thom: compiling now, so hopefully, yes.
<fabbione> pitti: we need to go and talk with the people there to agree on details
<fabbione> jbailey: use the other domain..
<jbailey> fabbione: Figured that.  Was wondering if that's a bug.
<jbailey> Esp. since the other domain is so annoying to type. =)
<fabbione> jbailey: add it to search in resolv.conf ;)
<seb128> fabbione: just crash (tm)
<seb128> same crash as before
<fabbione> interesting...
<thom> jbailey: people.ubuntu.com works fine ;-)
<elmo> jbailey: why are you using it?
<fabbione> seb128: how can i reproduce the bug?
<seb128> boot the kernel ? :p
<seb128> oh, the inotify
<fabbione> no.. the inotify one
<seb128> sec
<seb128> basically:
<seb128> mount a vfat partition on /mnt/vfat
<seb128> open nautilus on it
<seb128> do "umount /mnt/vfat" somewhere
<jbailey> elmo: Following the instructions in BugTracking that says to use rookery:/srv....
<fabbione> that implies me having vfat
<seb128> not sure
<jbailey> thom: Lovely, thanks. =)
<seb128> I've not tried with an another kind of fs
<elmo> jbailey: ah, yeah.. yeah, it's kind of expected, we're a mishmash of warthogs.hbd.c and ubuntu.c atm
<seb128> lemme try with an ext2
<Mithrandir> thom: actually, it's probably my kernel.
<elmo> jbailey: meh, ignore that REJECT, I'll fix
<Mithrandir> why is 2.6.10 so completely broken?
<jbailey> elmo: thanks. =)
<fabbione> seb128: but if i try to umount it tells me that is busy
<elmo> Mithrandir: 'cos Linus is still maintaining it 1/2:/
<fabbione> ah ok
<fabbione> got it
<thully> hi - is array 4 going to be released today?
<fabbione> seb128: it's FS indipendent
<fabbione> i can get it with nfs
<jbailey> elmo: Mmm, haven't seen the REJECT notice.  Do I need to email upload@?
<mxpxpod> fabbione: are you working on the fs is busy errors on reboot?
<elmo> jbailey: as I said, ignore it
<elmo> or, any lack of it
<jbailey> *lol*  Gotcha ;)
<elmo> actually, no
<elmo> you need to use dpkg-buildpackage -m when doing source uploads
<elmo> you didn't, and that's why you didn't get the REJECT
<elmo> Changed-By: Jeff Bailey <jbailey@ubuntu.com>
<elmo> ^-- should be Maintainer
<seb128> fabbione: right, just crashed with an ext :p
<jbailey> Eh?  Okay.  I thought putting it in the changelog was enough.
<jbailey> elmo: Want me to redo it?
<elmo> jbailey: nah, it's fine, you just won't get the ACCEPT mail is all
<thully> anyone know about this - I talked to someone yesterday and they said array 4 was going to be today - any delays in it?
<elmo> hmm, I might be on crack about this - my brain gets very confused by the Maintainer/Changed-By handling
<fabbione> seb128: ok i can reproduce both bugs...
<elmo> thully: there's plenty of hours left in the day yet
<seb128> fabbione: nice :)
<jbailey> elmo: Got the ACCEPTED notice.
<ogra> jbailey, congrats... your first one ?
<jbailey> ogra: Yeah. =)
<fabbione> ehhehe
<ogra> applause, applause, applause !!!
<seb128> jbailey: how do you feel ? :)
<Mithrandir> seb128: seriously, I can't debug shit on amd64 atm due to evo getting a SIGFPE due to kernel sillyness.
<sivang> jbailey: now you need a cigarrete :)
<seb128> Mithrandir: utch
<jbailey> seb128: Confused.  I've had to read 3 wiki pages to find all of the steps and I haven't finished submitting the patch to Debian yet.
<elmo> oh, MEH
<Mithrandir> seb128: I can downgrade the kernel, but that'll have to wait until I get home or something, I'm at uni atm.
<jbailey> sivang: Two fingers of scotch might be better. =)
<elmo> jbailey: okay, sorry, please ignore the crack about having to use -m, it's Changed-By which matters; the reason you didn't get a reject is katie runs away screaming from things she can't verify the sig on
<elmo> I'll fix the wiki page
<seb128> Mithrandir: k
<ogra> jbailey: if you got a better structure in mind then the MOTU page for the dev docs, feel free to change ;)
<ogra> ...improvements are always welcome ;)
<sivang> jbailey: especially some insight wrt to cdbs would be appriciated :)
<seb128> (cdbs2)
<seb128> (multi-build)
<sivang> seb128: err, now that's that? ;-)
<jbailey> sivang: *lol*  
<Treenaks> Crappy Debian Broken Stuff 2?
<seb128> trooooool
<Treenaks> seb128: sorry :P
<sivang> jbailey: btw, why did you write on cdbs's wiki that you don't want to tell us (the savy newbies) about it? that's it secret etc etc :)
<jbailey> sivang: cdbs has a wiki?
<thom> sivang: because jeff knows cdbs is evil and wrong :-)
<Kamion> thully needs to stop coming in, asking a question, and disappearing ten minutes later
<sivang> thom: I figured so ;)
<sivang> jbailey: common, don't play innocent on me :)
<zul> Kamion: yep
<jbailey> seb128: I now have apps that need multi-build too so I'm more likely to actually hack on it consistantly. =)
<seb128> cool
<jbailey> sivang: Seriously, there's a wiki?
<sivang> jbailey: yes, lemme find it, tesng pointed me at ti sometime
<jbailey> sivang: I merely hack on the damned thing.  I've never made any attempt at documenting it. =)
<sivang> jbailey: hehe
<Kamion> sivang: the wiki page I think you're referring to is https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS ?
<Kamion> sivang: that talks about "while experimenting [with]  this tool", which would kind of suggest that it wasn't written by the author. :-)
<sivang> Kamion: hrm, right, oops (tm)
<sivang> :)
<dilinger> heh
<dilinger>  It |70>< !!!
<Kamion> daniels: planning xorg 6.8.1-1ubuntu13 today?
<jbailey> sivang: Looks like this wiki is by duck_work (Marc Dequnes if I got the spelling right)
<Mithrandir> Kamion: what's the bug # of the grub kernel segfault bug?
<Kamion> Mithrandir: #6082
<Mithrandir> Kamion: ok, so you didn't file a bug about it yourself?
<Kamion> no, I forgot to
<Mithrandir> ok
<Mithrandir> are you or fabio working on it?
<Kamion> Mithrandir: I sent mail to linux-kernel though
<tseng> grr, mailman wont let me subscribe on alioth
<Kamion> Mithrandir: Sort of. I've been intermittently trying to add printks to the kernel in suspicious areas. I haven't managed to get a test case that isn't grub yet, though.
<Mithrandir> Kamion: ok.  Tried with noxec=on on bk1?
<Kamion> Mithrandir: I was just about to :-)
<sivang> jbailey: yes, actually, I just used it assuming cdbs author has written it :)
<Mithrandir> Kamion: thanks
<Kamion> Mithrandir: noexec=off doesn't seem to help matters on the CD, which is weird
<daniels> Kamion: yes
<Kamion> though I could be doing something wrong
<Kamion> daniels: good, thanks
<daniels> Kamion: have a few more debconf tweaks to do first
* lamont returns
<lamont> pitti: ack
<Mithrandir> Kamion: it's not a separate switch for 32 bit noexec?
<elmo> Mithrandir: no, that's what the problematic patch changed
<elmo> removed the noexec32 option and related code
<elmo> 'cos noexec32 use to default to off for amd64
<Kamion> noexec used to default to off as well
<Kamion> rather, noexec=noforce
<Kamion> -  noforce (default) Don't enable by default for heap/stack/data,
<Kamion> -          but allow PROT_EXEC to be effective
<Mithrandir> so does it change if you boot with noexec32=noforce?
<Kamion> there's no such option any more
<Mithrandir> oh, ok.
<Mithrandir> they got merged?
<Kamion> Mithrandir: see http://linux.bkbits.net:8080/linux-2.6/gnupatch@41752e4eX1Y99rE-GhfPoRzKlwh85g
<Kamion> yeah
<Kamion> Mithrandir: -bk1 with noexec=on seems to work ...
<Kamion> Mithrandir: can you reproduce this yourself in the same way?
<Mithrandir> I don't have an amd64 system in front of me now.
<Kamion> as in right now, or in general you don't have a desktop amd64 system any more?
<Mithrandir> as in right now
<Kamion> ok, good :)
<Mithrandir> I'm at university where I currently have a p4, but getting an amd64 soonish
<Mithrandir> does kernel macros have weird semantics?  this looks a bit weird: #define elf_read_implies_exec(ex, have_pt_gnu_stack)(!(have_pt_gnu_stack))
<Mithrandir> or is it just so you can say if (elf_r_i_e(0, true)) { ... } ?
<AndyFitz> jdub: ping
<Kamion> Mithrandir: look at fs/binfmt_elf.c; that file gets #included by other C files, and the macro parameterises it.
<rubenv> is apache2 install borked?
<rubenv> Instellen van apache2-mpm-prefork (2.0.52-3ubuntu3) ...
<rubenv> This module does not exist!
<rubenv> "Instellen van" is the dutch equiv of setting up
<Kamion> T-None: with regard to the ubuntu-desktop issue, try booting today's CD with the 'preseed/file=/cdrom/preseed/ia64-hack.seed' argument
<ericf> I must admit it's in bug 5913, too, but would the Ubuntu developers like the idea of making gksudo grey-out the background when it disables X, like gnome-logout does?
<rubenv> ericf: gnome-logout does a very crappy grey-out imho
<elmo> SYS_0(0x204, 0x7ffffa00, 0x88000282, 0, 0xfc68a60
<elmo> what the heck is that?
<ericf> rubenv: It fades, which is very slow and shakey. But I mean it should just grey-out the background, so you have visual feedback that you can and should only use the active gksudo window
<rubenv> as long as it doesn't hog my pc
<rubenv> gksudo shouldn't stay act
<rubenv> ive
<rubenv> longer then needed :)
<rubenv> but i'm a complete nitwit at usability
<ericf> its *not* about fading
<rubenv> so ignore my opinion :)
<elmo> heh; it's a buildd trying to write "no space left on device" to a log file on the same device.. in a loop.  yay for checking return codes
<Treenaks> ericf: you mean "only when the password dialog is active", right :)
<Treenaks> ericf: (as the password dialog grabs keyboard focus)
<ericf> Treenaks: of course
<rubenv> otoh
<rubenv> i think it would be quite annoying
<Treenaks> ericf: I think it's a cool idea to gray out/fade out the desktop when the keyboard is grabbed :)
<rubenv> having your screen flashing
<daniels> elmo: heh
<Treenaks> rubenv: uh.. you can't type in another window anyway..
<Treenaks> rubenv: that's the point of grabbing
<rubenv> yeah, but going to dark for just that
<rubenv> ssh-askpass-gtk2 did that too once
<Treenaks> rubenv: it still grabs
<Mithrandir> jbailey: #debian-glibc. :D
<rubenv> Treenaks: not talking bout grabbing :)
<rubenv> i mean the visual feedback named fading 
<ericf> well, the current situation is quite confusing, as you just see a window, and the idea of a window is that you can put it next to other windows to use both
<rubenv> i'd drop the window border ;)
<Treenaks> rubenv: really, graying out is cool :)
<Treenaks> but only a small bit.. not too much
<rubenv> yeah, else it gets highly annoying
<lamont> Kamion: how long do I need to keep the livecd fs iamges for you?
<rubenv> perhaps only fade after a couple of seconds
<lamont> 5 days history enough?
<rubenv> like windooze dus
<rubenv> *does
<ericf> I'm not talking about a 4-second fading thing, and not about making the screen black&white either. I'd just like to see a slightly greyed background, so it can be done fast, and there is better visual feedback and thus better usability. 
<ericf> like Treenaks says
<rubenv> my only opinion is that instant greyout could cause highly annoying flashing
<ericf> rubenv: point taken :) It should be taken in consideration
<Kamion> lamont: more than enough
<elmo> nono, keep them FOREVER. oh, no wait, you already tried that ;-)
<lamont> elmo: need more disk space.  kthxbye
<Kamion> lamont: I haven't had to care about a non-current one yet, but I'm betting somebody will come up with a case at some point that means I have to
<marcin_ant>  hi - are there packages with apache Tomcat available for ubuntu?
<zul> have you checked universe?
<marcin_ant> zul: yup
<lamont> marcin_ant: E: Couldn't find package libcommons-modeler-java
<lamont> apt-get failed.
<lamont> that'd be why the build of tomcat4 is failing
<lamont> http://people.ubuntu.com/~lamont/buildLogs/t/tomcat4/4.1.30-6/
<marcin_ant> zul: universe and multiverse too
<zul> marcin_ant: what lamont said
<marcin_ant> lamont: heh - this means that they are not installable, right?
<lamont> marcin_ant: that means that it's not built.
<lamont> marcin_ant: and won't be until there's a  libcommons-modeler-java package in multiverse, or someone uploads a new tomcat4 that doesn't need it.
<marcin_ant> lamont: ok - I'll try co create package
<marcin_ant> lamont: thanks
<Kamion> thully: nobody told you that Array CD 4 would be released today
<Kamion> 16:23 < Kamion> array-3.5-live is stable, although there's localisation breakage; array 4 is the next milestone and will be tomorrow + whenever the udev bug gets squashed
<Kamion> thully: note the last bit; the udev bug has not yet been squashed
<Kamion> (to my knowledge)
<daniels> Kamion: array 4 totally has to block on 6.8.1-1ubuntu13, btw
<Kamion> daniels: yes, that too :)
<daniels> Kamion: cool
<Kamion> that's why I was asking about it earlier
<daniels> Kamion: right
<daniels> i just need to beat the last of the 'omg let's not write a file and let's also be silent about that fact' stupidity out of xserver-xorg.postinst.in
<Kamion> actually I'd consider releasing with udev unfixed if only because it might draw more attention to it and thus help ...
<Kamion> 'cos it doesn't kill the install or anything, just makes it dog-slow for a while
<daniels> yeah, I need to do an install-test
<Mithrandir> Kamion: #debian-amd64; can you test or should I?
* daniels glares at his amd64 sitting with the wrong type of power supply, and thus useless, next to him.
<Kamion> Mithrandir: just seen :)
<thom> daniels: oops
<Kamion> I was in the middle of a noexec=off test
<daniels> thom: yeah.  'it's eatx, really', they said.
<daniels> thom: needless to say, it will be returned tomorrow, and exchanged for something that is actually eatx.
<thom> nod
<lamont> Kamion: amd74xx.ko is insmod'ed by hw-detect - seems to run through drivers/kernel/ide/pci/* in reverse alphabetical order trying to insert them.
<lamont> simply removing that module from the kernel on ia64 is probably a good idea - it's known to not work...
<lamont> If I remove that file, then we die later...
<lamont> cramfs: bad magic
<lamont> Unable to identify CD-ROM format
<lamont> after the cloop message identifying the fs
<Kamion> ah, ok, removing it sounds sane
<Kamion> missing ext2-modules udeb?
<Kamion> is ext2 compiled into the ia64 kernel?
<lamont> could be - will check
<Kamion> CONFIG_EXT2_FS=m
<lamont> yeah - all 4 images
<Kamion> yet there is no ext2-modules udeb
<Kamion> fabbione: ^
<dholbach> re
<Kamion> fabbione: please echo common/ext2-modules > debian/d-i/ia64/modules/ia64/ext2-modules.lnk
<lamont> fabbione: and unset CONFIG_BLK_DEV_AMD74XX=m in all 4 ia64 configs too, please
<lamont> fabbione: and add ext2-modules.lnk to sparc* and hppa, I expect...
<lamont> Kamion: how is amd64 working - it doesn't have that link either
<Kamion> uh ...
<Kamion> ext2 is =y on several arches
<lamont> doh
<Kamion> fabbione: cancel what lamont said about sparc and hppa, they're fine as they are
<Kamion> ./hppa/32:1339:CONFIG_EXT2_FS=y
<Kamion> ./sparc/sparc64:1002:CONFIG_EXT2_FS=y
<lamont> Kamion: yeah - and amd64 as well.
<lamont> which would explain it.
<Kamion> ./amd64/amd64-generic:2392:CONFIG_EXT2_FS=y
<Kamion> right
<lamont> looks like ia64 is the only problem child
<fabbione> re
<fabbione> sorry.. i wasn't here
<lamont> fabbione: also, note that prf11's slow I/O is a problem introduced between 2.6.8 and 2.6.10, fix unknown. :-(
<lamont> fabbione: to sum up:
<lamont> <Kamion> fabbione: please echo common/ext2-modules > debian/d-i/ia64/modules/ia64/ext2-modules.lnk
<lamont> <lamont> fabbione: and unset CONFIG_BLK_DEV_AMD74XX=m in all 4 ia64 configs too, please
<lamont> and then I ran Kamion down a tangent and back...
<fabbione> lamont: done.
<Kamion> :)
<lamont> fabbione: then I guess we might be ready for -14.
<Kamion> gar, this is so annoying, half the kernels I'm building don't support my network card. Can we get that sk98lin update merged upstream?
* lamont cries for his bandwidth
<lamont> mdz here yet?
<fabbione> lamont: no.. -14 is going to be a royal pain and i am still working on it
<lamont> fabbione: or is that -15? :-)
<fabbione> that is -14
<bluefoxicy> moooo
* lamont wants to roll a new ia64 livecd today, you see...
<fabbione> but i am debugging inotify with upstream
<fabbione> and apparently some changes will require also an ABI change
<fabbione> = everything needs to be resynced
<lamont> fabbione: on the bright side, maybe we can find/fix the I/O issue on hppa
<Mithrandir> lamont: any luck with the bushes yesterday or were they still hiding?
<fabbione> lamont: do we have a patch?
<lamont> Mithrandir: didn't get an answer back from him yesterday
<lamont> fabbione: we don't even have a root cause
<lamont> fabbione: we have a symptom: 99% of the CPU is spent in hard interrupts while doing disk I/O.  That's bad...
<Mithrandir> lamont: ook.  I've got multiarch mostly-working on i386 now, which is kinda nice.
<fabbione> lamont: does hppa uses pci irq routing?
<lamont> I expect so, could check
<fabbione> please do so.. if it does i might have an option for you
<fabbione> use something like Linux irqpoll
<lamont> fabbione: as in known issue that's already fixed or some such?
<fabbione> but you need an Ubuntu kernel
<fabbione> lamont: there are plenty of irq routing problems and changes between 2.6.9 and .10
<fabbione> that irqpoll is a patch we stole from Alan
<lamont> ah - fixed in 2.6.11?
<fabbione> no idea :(
<lamont> right
<fabbione> it could be
<fabbione> the plan was to start a .11 packaging branch today
<fabbione> but i will have to delay it to tomorrow
<fabbione> one fix i got from upstream make baby Jesus cry very hard
<lamont> I see.  that gross, eh?
<fabbione> lamont: it doesn't even boot with that fix
<lamont> fabbione: that's not a fix, then...
<fabbione> lamont: eh....
<mdz> lamont: here
* lamont tries to remember what he was going to ask mdz
<lamont> oh.  hppa kernel names
<mdz> jdub: yes, we have the capability to choose a kernel based on CPU, but we don't ship the extra kernels on the CD (this should work automagically on the DVD)
<lamont> hppa32, hppa32-smp, hppa64, hppa64-smp are the current names...
<mdz> Package: linux-image-2.6.10-2-64-smp
<mdz> Architecture: hppa
<mdz> Package: linux-image-2.6.10-2-32
<mdz> Architecture: hppa
<mdz> etc.
<fabbione> the automatic kernel chooser is kinda broken on sparc.. it keeps suggesting -smp instead of up
<fabbione> mdz: http://people.ubuntulinux.org/~fabbione/umeta.diff <- sparc support for ubuntu-meta...
<mdz> elmo: I seeded gnome-btdownload before uploading it; did something go wrong?
<fabbione> mind to review and bless?
<elmo> mdz: I do universe by default; there's no way for me to tell if something should be in main without germinate being able to see it
<elmo> so everything goes into universe/multiverse and gets promoted up if appropriate afterwards
<mdz> ah
<mdz> so no point in trying to update the seeds ahead of time
<elmo> eh, well, it was only in universe for an hour or so - not sure what the problem is?
<daniels> thom: you got your hands on involver?
<lamont> mdz: those are old names... that was fixed by -13, iirc
<fabbione> yeah or -12
<mdz> ah, ok
<lamont> mdz: that is, I noticed it when linux-meta (which used the good names) couldn't install because the kernel used the bad names, so I had fabbione do the rename.. yeah - was -12
<mdz> elmo: I was just under the impression that it saved time or work if I updated the seeds before you processed the package
<rubenv> anyone responsible for apache here?
<rubenv> AFAIK, it doesn't do fresh installs, or I've seriously fucked something
<elmo> mdz: oh, i suppose in that sense it doesn't matter anymore, yeah.  that's why I switched to universe-by-default, so it didn't cause grief when the seeds weren't updated
<mdz> fabbione: ubuntu-meta 0.25 uploaded
<fabbione> mdz: thanks!
<fabbione> are the changes ok?
<Kamion> lamont: if those ever stop beginning with "hppa", please let me know, as I'll need to change base-installer
<lamont> Kamion: right
<thom> daniels: ages ago, yes
<lamont> Kamion: I expect they'll stay 'hppa' forever - not much new hw development there...
<Kamion> yep :)
<mdz> fabbione: I changed it a bit, but no worries
<fabbione> mdz: ok thanks
<mdz> rubenv: a bit more detail?
<rubenv> mdz: well, I uninstalled apache2, nuked /etc/apache2 and now it refuses to install again
<daniels> Kamion: just to be clear -- when running dpkg-reconfigure foo, $RECONFIGURE is set, no?
<rubenv> AFAIK, the problem is in the enabling of the cgi mod
<rubenv> (that's what I could make of the postinst file)
<thom> rubenv: did you uninstall apache2-common?
<rubenv> yes
<mdz> Kamion: you didn't get any replies on lkml about this grub segfault thing?
<thom> and when you install apache2-common, do you have /etc/apache2/mods-available/cgi.load ?
<mdz> daniels: no, I believe it's DEBCONF_RECONFIGURE, check the dpkg-reconfigure source
<rubenv> thom: no
<rubenv> going for a complete nuke again :)
<thom> 17:24 ~% dpkg -L apache2-common|grep cgi
<thom> /etc/apache2/mods-available/cgi.load
<thom> /etc/apache2/mods-available/cgid.load
<thom> /etc/apache2/mods-available/cgid.conf
<Kamion> mdz: no, there's been some conversation on #debian-amd64 but no fix yet
<Kamion> daniels: $DEBCONF_RECONFIGURE
<mdz> speaking of which, I ought to change fontconfig
<rubenv> thom: 
<daniels> mdz, Kamion: thanks
<rubenv> those files show up when doing dpkg -L
<rubenv> but nothing in /etc/apache2/mods-available
<thom> and you've removed apache2-common and reinstalled it?
<rubenv> yeah
<rubenv> could this be
<rubenv> because of some lingering config files
<rubenv> i did not purge em afaik
* fabbione ponders a -14 release without that fix
<fabbione> lamont: -14 might happen tomorrow
<thom> rubenv: interesting
<rubenv> this could be more of a dpkg/apt thing then apache 
<rburton> mjg59: so my x22 bios disables the local apic. would it be a good idea to turn it on with lapic?
<mjg59> rburton: No
<mjg59> Trust the BIOS.
<rburton> mjg59: balls. that means oprofile sucks
<rburton> thanks though
<thom> yeah, it's because of the way dpkg handles unpurged conffiles that have gone away
<mjg59> Oh. If you /need/ apic support, then give it a go (I think you probably want lapic apic)
<pvh> I tried to install Hoary with the installer onto my laptop the other day, and installing the base system failed because I had no floppy.
<pvh> It left my system in an unbootable state. (Not even GRUB)
<mjg59> Some machines that disable it will work if you force-enable it
<mjg59> (Quite a few, in fact)
<mjg59> But in general, if the BIOS disables it we trust its decision
<rburton> mjg59: what happens if it doesn't work?
<Kamion> pvh: because you had no *floppy*? what was the error message?
<mjg59> rburton: Your machine hangs, or you don't get interrupts
<rburton> eek, noticable then
<rburton> bbiab 
<pvh> Kamion: It complained that the kernel could not load the floppy module, which meant base failed.
<Kamion> I doubt that.
<mjg59> pvh: That's not the lack of a floppy, it's the lack of a floppy controller
<Kamion> pvh: there'll be a 'modprobe floppy failed' or some such message in the logs, but it's not fatal
<pvh> Kamion: Well, there was nothing else in the logs to indicate the problem.
<Kamion> pvh: I'd rather see /var/log/* myself than try to diagnose it this way. :-)
<pvh> Kamion: If I'd known I wouldn't be able to reproduce the error easily I would have taken more accurate notes.
<rubenv> thom: in fact dpkg should stat for missing files
<pvh> I'm not familiar with the technique for repairing damaged boot sectors on secondary drives in Linux.
<pvh> I'll see if I can mount it on my desktop though and come back with the log for you.
<rubenv> thom: want me to file a bug?
<mdz> rubenv: you can't simply delete files owned by the package; you need to purge it
<rubenv> yeah, I know, but being the lazy ass I am :)
<mdz> my point is that doing so broke the package
<daniels> Treenaks: could you please bounce me the panel size line (look for 'panel size' or 'Panel Size') from your Xorg.0.log?
<rubenv> either way, apt should be a bit more robust on that, especially in /etc
<mdz> packages don't generally cope with having their files deleted
<rubenv> people have the bad tendency to edit /etc
<rubenv> ;-)
<mdz> editing files in /etc/ is supported, of course, but if you decide to edit /etc/passwd to contain an ogg vorbis stream of me singing a song, that will cause problems
<rburton> mjg59: network and radeon works with "lapic apic" so i'll keep them on
<rburton> and oprofile becomes less crap
<rubenv> mdz: offcourse nobody 'll do that, but if you delete a config file, shouldn't it be restored on reinstall?
<mjg59> rburton: Ok - there's a small risk of hard hangs, but it's probably safe
<mdz> rubenv: no, deleting a configuration file is a change that is explicitly preserved
<mdz> like any other change to a configuration file
<rubenv> ok, then I accept the fact that I was a stupid lazy ass :)
<mdz> dpkg has a --force-confmiss flag if you _want_ it to restore the files
<mdz> but it won't do so by default
<mdz> seb128: here?
<rburton> daniels: your SJ problem is something i've been thinking about
<rburton> daniels: i think i'm going to solve it with two file name format dropdowns, one for single-artist CDs and one for multiple-artist CDs
<mvo_> hi enrico 
<seb128> mdz: yep
<daniels> wow, it really is getting insane outside now
<daniels> rburton: cool
<mdz> seb128: filed #6099
<mdz> seb128: I think I reported the same bug before, but I couldn't find it
<Treenaks> daniels: [1] +  Done                    totem http://www.startrek.com/videouploads/200411/(II) Silicon MotionTFT Panel Size = 1024x768
<Treenaks> uhm
<Treenaks> daniels: [1] +  Done                    totem http://www.startrek.com/videouploads/200411/(II) Silicon MotionTFT Panel Size = 1024x768
<Treenaks> ARGH
<enrico> mvo_: hi!
<mdz> Treenaks: I used to have a bug like that with xterm
<mdz> copying the first line of the displayed portion of the buffer
<mdz> would also get the previous line from scrollback or so
<Treenaks> mdz: yes!
<Treenaks> mdz: entirely correct :)
<mdz> my fix was to switch to gnome-terminal ;-)
<daniels> Treenaks: WHAT THE FUCK?
<daniels> Treenaks: does it really say 'Silicon MotionTFT Panel Size ='?!?
<fabbione> Kamion: at which point inside d-i is mapdevfs available?
<Kamion> fabbione: from after "retrieving installer components"
<fabbione> ok
<Kamion> definitely available by the partitioner
<fabbione> ok
<seb128> mdz: there is some similar bt upstream, but the bugs are closed (not news and recent bugs about this). BTW some fixes have been commited the theme manager this week, perhaps that's fixed, I'll update the package soon.
<seb128> mdz: BTW could you install the dbg packages for GNOME (libglib2.0-0-dbg libgtk2.0-0-dbg libgnomevfs2-0-dbg), so next time you get a good bt :)
<pvh> Kamion: There are no logs on the partition. Sorry I can't be more helpful.
<fabbione> Kamion: confirmed. it's mapdevfs the problem for us.. digging into it now
<Kamion> fabbione: what's $rawconsole?
<fabbione>  /dev/console
<Kamion> ls -l ?
<Kamion> pvh: oh well ...
<T-Bone> Kamion: got your message in the backlog, will test that, but can't tell when yet ;P
<fabbione> crw-rw----    1 root     root       5,   1 Feb  2 18:09 console
* lamont goes to run some errands in town. back in a while
<fabbione> Kamion: lrwxrwxrwx    1 root     root            5 Feb  2 17:56 ttyS0 -> tts/0
<fabbione> lrwxrwxrwx    1 root     root            5 Feb  2 17:56 ttyS1 -> tts/1
<Kamion> I wonder why it's /dev/console, not /dev/ttyS0
<fabbione> Kamion: and console = /dev/console
<Kamion> mapdevfs doesn't know about /dev/console
<Kamion> I suspect if you booted with console=/dev/ttyS0 it would work fine
<Kamion> although I have absolutely no idea how it manages to work in Debain
<Kamion> Debian
<Kamion> fabbione: does /dev/console exist?
<fabbione>    0 crw-rw----    1 root     root       5,   1 Feb  2 18:11 console
<fabbione> yup
<fabbione> it's there
<Kamion> having rawconsole=/dev/console is problematic, since it leaves prebaseconfig no way to reliably determine that it's on a serial console.
<Kamion> /dev/console could just as easily be a virtual terminal.
<pvh> Kamion: I am quite certain that debian-installer reported failure due to insmod failing to load the floppy module however.
<Kamion> pvh: do you say this due to a message you saw in the main interface?
<pvh> Kamion: in the curses interface yes, and with corresponding messages on VT3
<Kamion> pvh: that's not during base installation, though; you reported a problem with the base system failing to install
<Kamion> no such error can appear in the curses interface during base system installation
<pvh> Kamion: Debian-installer marked the step "Install base system" as having failed.
<pvh> And would not proceed beyond that point.
<fabbione> Console: ttyS0 (SU)
<fabbione> Kamion: that's in dmesg
<pvh> Kamion: So I can assure you that whatever the problem may have been, that was where and when it occurred.
<fabbione> i think that's because the sparc kernel does the mapping automatically via OBP
<Kamion> pvh: "would not proceed"?
<Kamion> pvh: I'm sorry, but I can't debug this without exact error messages and logs; what you're reporting conflicts with my knowledge of the code ...
<pvh> Kamion: Fair enough, fair enough.
<Kamion> so, if you can reproduce it again, that would be great
<pvh> Kamion: If I can reproduce it, I'll take detailed notes.
<Kamion> thanks
<pvh> Kamion: As it is though, I have a lot of code to write and need to get my laptop back online.
<Kamion> fabbione: wouldn't that happen in Debian too though?
<Kamion> pvh: understood
<fabbione> Kamion: i hounestly have no idea... but they use devfs, don't they?
<fabbione> so perhpas it does a different mapping...
<Kamion> fabbione: sure, but we use udev with devfs rules
<fabbione> iirc d-i doesn't create the old compatibility devices..
<Kamion> nope
<Kamion> our d-i does
<Kamion> sometimes
<Kamion> check whether /dev/console exists in Debian
<Kamion> Debian d-i, I mean
<fabbione> yes gotcha
<fabbione> i will have to check that
<Kamion> fabbione: hm, can you look in /proc/1/fd and see what init has open?
<Kamion> fabbione: oh, I think I have an idea
<mdz> seb128: ok
<fabbione> Kamion: sure.. just a sec
<Kamion> fabbione: boot with init=/bin/sh
<Kamion> fabbione: nano /sbin/init
<fabbione> Kamion: there is no fd/0 for pid 1
<Kamion> fabbione: add these lines after the similar stuff for /dev/vc inside [ -x /sbin/udevstart ]  (so around line 28):
<Kamion>                 mkdir -m 755 /dev/tts
<Kamion>                 for i in 0 1; do
<Kamion>                         mkdir -m 600 /dev/tts/"$i" c 4 "$(($i + 64))"
<Kamion>                 done
<Kamion> fabbione: I bet that'll fix it
<Kamion> fabbione: oh, then 'exec /sbin/init'
<fabbione> Kamion: ok.. it takes a little while to boot :-)
<mdz> Kamion: did I inadvertently clobber usbutils? argh
<mdz> I could have sworn it was unmodified
<Kamion> mdz: aye, fixed now
<Kamion> elmo gave me a heads-up
<mdz> elmo: could you require an explicit clobber request in these situations, to avoid future foolishness?  in my case, at least, if I don't explicitly mention that it obsoletes a modified Ubuntu version, I'm probably making a mistake
<fabbione> Kamion: mkdir -m 600 /dev/tts/"$i" c 4 "$(($i + 64))" -> mknod ?
<Kamion> fabbione: er, yeah, oops
<fabbione> ehhe
<fabbione> :-)
<fabbione> booting now..
<Kamion> fabbione: it took me ages to realise that I needed to add that stuff for /dev/vc when I was originally porting to udev; I'm not surprised I forgot about the serial console case
<fabbione> Kamion: if it works you get beer :-)
<daniels> amu: aha!!  are you here?
<mdz> gah
<mdz> Kamion: fontconfig calls fc-cache not once, but twice
<mdz> once directly, and a second time indirectly via defoma
<amu> daniels: sure, all time 
<mdz> the defoma bit is added indirectly by debhelper
<Kamion> mdz: er, whee
<daniels> amu: is kdelibs-dev in main, or universe?
<mdz> I think I'm just going to stop reconfiguring fontconfig in casper
<amu> daniels: universe
<Kamion> mdz: thully will hate you
<daniels> amu: guess what dbus requires for linking with qt ...
<fabbione> Kamion: i dunno...
<fabbione> Kamion: you are just a FUCKING GENIUS!
<fabbione> ~ # echo $rawconsole
<fabbione> ~ # echo $console   
<fabbione>  /dev/tts/0
<Kamion> w00t
<fabbione>  /dev/ttyS0
<fabbione> there ya go!
<amu> daniels: i'll say kdelibs ;)  
* fabbione covers Kamion with a lot of love
<daniels> amu: DING DING DING!
<amu> daniels: i got a brand new ibm laptop? 
<fabbione> Kamion: where does that change need to be done?
<Kamion> fabbione: rootskel 1.11ubuntu5 uploaded, thanks for testing
<fabbione> Kamion: i mean.. in what package...
<fabbione> Kamion: ah.. thanks for fixing :-)
<fabbione> now we are down to one problem only..
<fabbione> choose mirror
<Kamion> it'll need that d-i build
<Kamion> s/that/a new/
<fabbione> as well
<fabbione> we need both choose-mirror and the new d-i
<Kamion> yeah
<fabbione> and sparc is ready to fly
<fabbione> ubuntu-meta is done...
<Kamion> well, I can hack choose-mirror to pick sparc.ubuntu.com/ubuntu-sparc, independently of talking to sabdfl; I'll do that tonight
<fabbione> jdub confirmed the fb problem is gone
<fabbione> Kamion: nah
<fabbione> let's do it clean
<fabbione> it can wait
<fabbione> really...
<Kamion> I think that's correct anyway, actually
<Kamion> the default should be sane ...
<fabbione> yeah but sparc is an exception
<fabbione> but you are our d-i god...
<fabbione> so i am nobody to stop you ;)
<Kamion> oh I realise that, but I can easily have architecture-specific defaults in those templates
<fabbione> right...
<fabbione> i need to go and spend sometime with my future wife :-)
<Kamion> have fun :)
<fabbione> she is getting a bit impatience.. -10 days :-)
<fabbione> thanks
<amu> daniels: we should move kdelibs to main     
<pvh> Kamion: I'm trying to restore my aborted install.
<daniels> amu: you'll have to take that up with mdz/elmo, i'm afraid
<daniels> in the meantime, i can hack around it, but I might have to sleep before I upload dbus
<pvh> Kamion: Can you advise me about what the bare minimum I can put on the partition to pick up where I left off?
<Kamion> pvh: you'll have to start the install from scratch I think
<Kamion> pvh: you could install into a smaller scratch partition though
<Kamion> our installer has no significant support for resuming halfway through
<Kamion> pvh: I'm afraid I have to go now, will be back in a couple of hours
<pvh> Kamion: Well, thanks for your advice.
<pvh> Kamion: I don't mean to treat this like a help channel, but I'm definitely in uncharted territory.
<Kamion> pvh: sure, can't speak for anyone else but personally I don't mind interesting installation problems here :)
<zul> fabbione: dont do anything i wouldnt do
<Kamion> (of course, the value of "interesting" varies over time ...)
<pvh> Kamion: Well, I can only hope that by the time you get back I can say "Oh, I documented it on the wiki."
<Kamion> heh
<Kamion> or "Oh, I sent a patch" ;-)
<amu> daniels: all right, take it easy, takes some time till 3.4 will be released, sleep well 
<pvh> Kamion: Even better, and even less likely. ;)
<Kamion> FWIW, most of my systems don't have working floppy drives ...
<daniels> amu: cheers
<amu> mdz: is there any chance to get kdelibs to main 
<mdz> amu: yes
<amu> daniels: cheers  
<amu> mdz: as i remember, please correct me if i'm wrong, it must be supported in order to go into main, right?  
<mdz> yes
<amu> mdz: the upcomming kde 3.4 supports dbus, therefore we need dbus-qt enabled.   
<mdz> ok
<mdz> if you upload a package to main which depends on kdelibs, it will move into main
<mdz> currently no package in main depends on it
<mdz> Kamion: speaking of devices for busybox init
<mdz> Kamion: can we switch to using non-devfs names for those?
<amu> mdz: thx, got it 
<amu> daniels: still awache? 
<mdz> Kamion: it would let me remove one of the gross hacks in casper
<amu> s/h/k
<Kamion> mdz: that's a significantly bigger change and I'd rather leave it until post-hoary
<daniels> amu: sure
<daniels> amu: will do it
<amu> daniels: fire in the hole :)
<Kamion> mdz: because it requires auditing all of d-i for /dev use rather than just pulling the wool over its eyes the way we're doing right now
<Kamion> mdz: and probably inserting at least one fairly significant compatibility layer
<mdz> Kamion: I think we're talking about different things
<Kamion> mdz: you should already have the traditional names available as well for most devices, though
<mdz> I'm talking about disabling CONFIG_FEATURE_DEVFS in busybox-cvs
<mdz> so that it opens /dev/ttyX instead of /dev/vc/X, e.g.
<pvh> Can I put 'linux' and 'initrd.gz' onto my laptop drive
<mdz> pvh: yes
<pvh> into /boot/
<pvh> then install grub onto the drive
<pvh> and have d-i run on the partition it booted from?
<mdz> pvh: yes
<Kamion> mdz: I'd still rather leave that until post-hoary
* amu creeps back under his K-stone 
<mdz> pvh: in fact I was just recently saying that we ought to have a howto document for it
<pvh> mdz: Oh! Well why didn't I think of that before!
<mdz> pvh: I would be grateful if you would document the process as you go along, for the sake of others
<pvh> mdz: I'll take notes.
<Kamion> mdz: that said, it may not be quite as much work as I think, so I'll have a look
<mdz> Kamion: it changes a very small amount of code
<amu> jdub: ping
<mdz> Kamion: essentially only the device names in include/libbb.h
<pvh> mdz: The only problem is that /mnt/ has nothing in it right now, so I can't chroot into it for grub installation purposes
<Kamion> mdz: yes, but several parts of d-i *will* need to be changed; I know of at least one in prebaseconfig alone
<mdz> Kamion: why? I don't follow
<mdz> I wasn't suggesting that we stop creating the devfs nodes on disk yet
<Kamion> mdz: the bits that try to figure out what kind of console is currently in use
<spiral> hi
<Kamion> anyway, I really have to run now
<mdz> later
<pvh> mdz: Can you point me to some documentation on how to write the boot sector on a secondary drive?
<pvh> mdz: The grub documentation is, shall we say, untalkative.
<mdz> pvh: grub-install <grub-device-spec>
<elmo> mdz: the script does require an explicit clobber; I just assumed you wanted to override - I'll double check in the future if the script needs forcing and the request to sync doesn't explicitly say it's overriding
<pvh> mdz: I was afraid you'd say that.
<mdz> <grub-device-spec> is where it will write stage1
<mdz> (hd0) for the first BIOS disk, (hd1) for the second, etc.
<pvh> mdz: Do I need to chroot first?
<mdz> elmo: thanks, and I'll work on smoking less crack
<mdz> pvh: that, or use --root-directory
<pvh> mdz: Ahh
<pvh> mdz: Can't chroot -- no bin dir yet.
<tseng> mdz: if you find a spare moment, would you mind checking on that upload you made for me last night
<tseng> mdz: doesnt appear to have made it through the system
<mdz> tseng: that's odd. which package was it again?
<tseng> tomboy
<mdz> hmm, I no longer have the upload on disk
<tseng> my source was at http://smarterits.com/~brandon/tomboy/
<pvh> mdz: Won't grub-install configure the drive as though it were mounted in its current configuration on my PC?
<mdz> tseng: it was just libpanel-applet2-0 -> libpanel-applet-dev, right?
<tseng> mdz: yep.
<mdz> uploaded
<tseng> thanks muchly
<mdz> no idea what happened, I remember uploading it
<mdz> but I have neither accept nor reject mail about it
<tseng> right.. thought id check with you
<tseng> never came up on -changes or buildlogs
<bluefoxicy> ahhhhhh now to mkisofs the cd
<pvh> mdz: Okay, I've got a boot/grub directory now, and a menu item pointing to the install files
<mdz> tseng: tomboy_0.3.1-0ubuntu3_source.changes ACCEPTED
<tseng> mdz: and a fine lesson on dep checking learned.
<tseng> :)
<smurfix> doko: ping?
<doko> smurfix: pong
<smurfix> doko: I've run into this Python 2.4 bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1098990&group_id=5470&atid=105470
<smurfix> doko: Rather than implement a workaround, pulling that fix from Upstream night be an option until the next point release ..?
<doko> sure, will do.
<smurfix> doko: Thanks
<Mithrandir> doko: I have multiarch working with 3.4 now. :)
<smurfix> doko: I could do it myself, but you're the Python giy
<smurfix> guy ;-)
* bluefoxicy steals hoary's qemu for warty
<doko> Mithrandir: cool ...
<Mithrandir> doko: is there anything stopping it getting working with gcc-3.3?  I'd like to not move to gcc-3.4 unless I have to.
<daniels> daniels@nanasawa:~/canonical/xorg/arch/pristine% sudo sh -c 'echo "# this file has now been customised" >> /etc/X11/xorg.conf'
<daniels> daniels@nanasawa:~/canonical/xorg/arch/pristine% sudo dpkg-reconfigure -phigh xserver-xorg
<daniels> xserver-xorg postinst warning: not updating /etc/X11/X; file has been
<daniels>    customized
<daniels> a little rough, but you get the idea
<daniels> xserver-xorg postinst warning: overwriting possibly-customised configuration
<daniels>    file; backup in /etc/X11/xorg.conf200502030635
<doko> Mithrandir: what is the goal working on multiarch with gcc-3.3?
<Mithrandir> doko: that I can get something stable working now so I can concentrate on stuff I break with multiarch rather than stuff which is broken in gcc-3.4
<tritium> daniels, slick
<mdz> daniels: can we get an extra '.' in that backup filename?
<daniels> mdz: hence 'a little rough' -- already fixed
<daniels> mdz: all that's left for ubuntu13 is pulling a better version of my loader speed hack and then no-oping speedo within that
<doko> Mithrandir: not that I know of ... we disabled biarch for 3.3, because it didn't correctly work
<Mithrandir> doko: hm, ok.
<Mithrandir> I most likely won't bother with it and ignore any problems I stumble into which seems to be gcc-3.4 internal problems.
<rcaskey__> is there an official procedure for becoming an ubuntu mirror? The Uni I work at just got a hd upgrade to the linux server and is pondering picking up debian and I'm trying to get Ubuntu on the list as well
<pvh> Kamion: Just so you know, I managed to get my system back into d-i.
<pvh> Kamion: Here's the short tutorial, which with a little prodding, I can flesh out into a proper installer section.
<pvh> Kamion: 1) format and mount the partition you want to install to
<pvh> Kamion: 2) grub-install <drive name> --root-directory=<mountpoint>
<pvh> Kamion: 3) put a kernel and an initrd.gz into the /install/ folder
<pvh> Kamion: 4) create a menu.lst file pointing to those files
<pvh> Kamion: The only caveat is to make sure that the menu.lst points to what the drive _will_ be in the destination system.
<pvh> Kamion: That, and I suppose picking the right vmlinuz/initrd.gz
<pvh> Kamion: I gunzipped the initrd.gz because I had difficulty with it earlier.
<fabbione> jbailey: nagios plugin is still FTBFS :-)
<fabbione> jbailey: http://people.ubuntulinux.org/~lamont/buildLogs/n/nagios-plugins/1.3.1.0-12ubuntu1/
* fabbione heads off again
<zul> fabbione: ping sorry 
<jbailey> Meh.  I thought build-deps were fine, just not actual depends for installation?
<mdz> rcaskey__: http://www.ubuntu.com/wiki/Archive
<mdz> jbailey: packages in main must build with only packages in main
<jbailey> mdz: I'm not sure what the right thing here is then.  I can disable the radius functionality completely, I guess.  It seems like the wrong answer though.  I can understand not wating to push more stuff into main, though.
<elmo> just like, err, Debian
<mdz> jbailey: is it not possible to build nagios plugins out-of-tree?
<jbailey> mdz: Yes.  They're just little scripts that take parameters and return error codes.  stdout is captured for logging, and the error codes let it know if it's a failure or a success.
<elmo> I don't mind promoting the radius _libraries_
<mdz> that was the resolution we applied for php4-imap
<elmo> hmm, well i suppose the client still gets pulled into extra.. meh
<mdz> extra goes into universe, no?
<mdz> I thought the issue was with a radius server
<mdz> if it's only libraries, that's less of a support issue
<elmo> the original nagios-plugins pulled in some random radius client software  too
<elmo> but I think jbailey fixed that already
<elmo> so, shall I just pull in the radius libs?
<jbailey> I moved the radiusclient to suggests.  But it still build-dep's libradius1-dev
<jbailey> I can split it out easy enough.
<elmo> seems a bit OTT to just avoid libraries - we have bazillions of random libraries already
<daniels> elmo: can we have libc-client too?
<elmo> daniels: you can have a burnt stick in the eye; how's that?
<daniels> elmo: sensational!
<daniels> at that price, I'll take two
<jbailey> daniels: Friends don't let friends use php-imap.
<daniels> s/-imap//
<mdz> elmo: which radius libs are they?
<elmo> libradius1{,-dev}
<elmo> or do you mean which fork?
<mdz> yeah, but that answered that too
<mdz> it's the Livingston library, oh god
<mdz> oh, no it isn't, it's the MERIT one
<mdz> that's somewhat less scary
<jbailey> mdz: All radius libraries suck.   They really do. =)
<mdz> we ought to check whether it has had all 10,000 RADIUS vulnerabilities fixed
<bluefoxicy> the last metroid is in captivity
<daniels> amu: please try the dbus debs from http://people.ubuntu.com/~daniels/dbus/ and let me know if they're any good for you
<bluefoxicy> JUSTIN BAILEY *samus out of suit* But we're going to blow crap up anyway
<amu> daniels: thx, 12h later is fine for y? i'm testing the live atm ...   
<daniels> amu: sure
<jbailey> mdz: Here, I'll just pull it for now.
<jbailey> mdz: We can always leave it disabled for now - I don'timagine there are acually that many radius servers still running out there.
<mdz> jbailey: that's what we did with php4-imap, and we didn't get around to fixing it until the next release
<mdz> does dialup RAS equipment no longer use RADIUS?
<mdz> it still did 4 years ago
<fabbione> re
<fabbione> or tatacs
<daniels> elmo: sorry about the ud-l spam to da-m (again)
* fabbione maintains 2 radius clients...
<jbailey> Dialup RAS usually does  RADIUS, TACACS+, or NT Domain authenication.
<fabbione> zul: fast pong?
<jbailey> fabbione: Any of them that you'd recommend for main?  I could just patch it to use yours.. =)
<fabbione> jbailey: client.. not server :-))
<fabbione> and not in main. sorry
<jbailey> fabbione: client is the issue here.  nagios needs a library to tell if a server is up.
<fabbione> jbailey: that can be easily done using the nagios tcp/udp check
<jbailey> fabbione: Assuming the server isn't hung solid.  But I agree that it's probably good enough for now, with a nagios plugin in universe for radius.
<fabbione> otherwise steal the code from a simple client like libpam-radius-auth
<jbailey> That would work.  I'll just graft it in.
<zul> fabbione: there was a patch in upstream that disable acpi for pnp devices do you want to submit a bug or something?
<fabbione> zul: i don't understand... 
<fabbione> a patch disabled acpi on pnp devices...
<fabbione> and do i need to do what?
<zul> fabbione: ill describe it better in bugzilla my mind is moosh right now with head cold
<fabbione> ehehe ok
<fabbione> i am off 100% now.. FOOD
<zul> k
<daniels> hm, electricity is out at our old house, which is only about 800m away
<daniels> lucky break
<zul> we had a lot of power outages since they have built that big arena in my area
<daniels> we're just having quite incredibly wild storms and a bucket of rain
<daniels> apparently there are no traffic lights on mega arterial roads
<daniels> all shorted out; half the city has no power
<zul> ouch...where do you live?
<daniels> and a power pole exploded (6m tall, exploded down to the stump) when the transformer was hit by lightning :)
<daniels> melbourne, .au
<elmo> isn't it obviousl? ;-P
<zul> heh
<elmo> [how to insult 1/3 of your cow-orkers in one simple statement - lessons in life by elmo #345] 
<zul> it could be worse
<daniels> elmo: yeah, some sort of crazy-arse land where people actually own more than two t-shirts ... heretics
<elmo> eh?
<daniels> elmo: go buy a represent shirt already; not only will it double the size of your wardrobe, but it will give me $us1
<elmo> dude, I so have more than two tshirts; granted, several of them look identical, but nevertheless
<elmo> you really only get us$1 from the sale?
<daniels> really.  i set my margins low, because I'm so generous.
<daniels> and even with my rock-bottom prices, you bastards still don't buy my gear :P
<elmo> I will.. when I can :P
<daniels> heh
<zul> frig...not another fundraiser
<T-None> gnight
<sivang> T-None: night
<thully> does anyone know what the status of array 4 is?
<mdz> there is a showstopper bug in X at the moment
<thully> what - is it the issue I had with X not starting?
<Kamion> thully: I already told you earlier that I was waiting for somebody to get a handle on the udev bug
<mdz> if you tried a recent daily CD, yes, porbably
<mdz> that too
<Kamion> repeatedly asking is not going to change that :-)
<mdz> though I haven't been encountering the udev bug lately
<Kamion> the X bug is, in retrospect, more of a showstopper, in that I'd probably be willing to release array cd 4 without the udev bug fixed, but I'd have to test a fair bit
<Kamion> and, of course, there's the amd64 grub breakage, but that was in array cd 3 too
<mdz> Kamion: are you going to be around for a bit?  I'd like to talk about netcfg sometime soon
<Kamion> thully: however, my fiancee wants me at her house now, so it will definitely not be today; I didn't promise today anyway
<Kamion> mdz: no, sorry
<mdz> ok, tomorrow then
<Kamion> see above :-)
<thully> OK - got to go - bye
* daniels sighs.
<daniels> jdub: 'morning captain
<dholbach> O Captain, my Captain... :-)
<jdub> seb128: 0.22 didn't have any significant changes on top of what we have :)
<seb128> k
<seb128> still no inotify working ?
<jdub> works for me :)
<enrico> jdub: morning.  Elmo's setting up our (we == docteam) canonical svn repository and needs a mail to send commits to.  A ubuntu-doc-commits list would be great: is it possible to have it?
* jdub spanks enrico 
<jdub> sure
<enrico> ouch!
<jdub> that's for using svn!
<enrico> plans are to migrate to baz, but a prerequisite was to have a sandbox to play with
<enrico> no sandbox found yet, and it's controversial if baz is ready for usage by less literate people yet
<enrico> but long term plans are to migrate to baz when it's ready (for some non-pioneer definition of ready :)
<mdz> enrico: I see that lifeless followed up with you; hopefully you can have a meeting to discuss it
<mdz> I'd love to see the doc team on baz if it is feasible
<mxpxpod> why is magicdev in the default session for GNOME if gnome-volume-manager is already
<mako> tseng: http://cplug.net/conference/
<jdub> mxpxpod: it's a failover
<mako> tseng: that's in ha-burg, someone was sending this to info. i guess they're interestd in an ubuntu presence
<mxpxpod> jdub: huh?
<mako> tseng: if you're interested, i can connect you
<jdub> mxpxpod: it'll load if it's there
<mxpxpod> oh, ok
<enrico> mdz: followed up.. where?
<ajmitch> morning
<dholbach> hi ajmitch
<enrico> mdz: I wouldn't mind to discuss that, but I'd really like not to embark on that before hoary releases
<mdz> enrico: as you can see from my earlier messages, I'm even more cautious about it
<mdz> enrico: followed up to ubuntu-doc, of course
<mdz> he CCed me, and Sean Wheller
<srbaker> can someone tell me what multiarch is?
<enrico> mdz: I can't find his mail, I'll try again
<enrico> mdz: can't find it because I didn't get it; however Sean quoted him in the list
<enrico> I could remind something about the mail, but I couldn't reply the mail itself, nor I could find it
<mdz> it's not in the list archives
<mdz> but ubuntu-doc was in the To: header
<mdz> probably it is in the moderation queue
<mdz> yes, it is
<mdz> moderated
<ajmitch> mako: CoC should be attached this time
<mako> ajmitch: :)
* sivang is headed to bed
<sivang> night everyone
<sivang> Zzzz
<enrico> mdz: Heading to bed, I'll reply to that tomorrow: thanks!
<dholbach> sleep tight sivang
<sivang> dholbach: tnx, night
<enrico> jdub: please drop me a note as soon as you have the commit list ready, as I need to communicate that to Elmo
<jdub> enrico: will do
<elmo> or just tell me :)
<Mithrandir> uhm, why isn't there an ubuntu-calendar-february on amd64, just on i386?
<mxpxpod> Mithrandir: it's on powerpc too ;)
<pitti> good night
<dholbach> Mithrandir: i have it on amd64
<jdub> ah, crap
<jdub> now i'm getting spam with list ids
<Mithrandir> dholbach: yeah, just maswan's mirror being out of date.
<Mithrandir> maswan: you mirror is out of date.
<Mithrandir> Kamion: did you get anywhere with the ia32 problem?
<daniels> mdz: think I've slammed everything through, but need to catch a couple of hours.  to get connectivity back, I'd need to reboot my workstation (acx111 is flaky), and it's in the middle of a build, so no.  debconf, live CD, FTBFS, everything but i810 CRTs (and I might be picking up an i845 later today) should all be fixed with this stuff.
<mdz> daniels: perhaps I could upload a version with the dexconf fix?
<daniels> mdz: not worth bothering.  by the time it hits the archives, I'll be up and looking over this build success, and sending it out for testing on davis and concordia before I upload.
<daniels> mdz: (assuming, say, 15min for the upload to katie, 10min for the buildds to get kicked, 2-3h [maybe more?]  for halley to build it, 10min for katie to notice upload, 15min to get included in a pulse; by that time, I've already uploaded ubuntu13, pretty much)
<lifeless> evolution sucks, kthnxbye
<lifeless> ps x | grep spamd | wc -l
<lifeless> 43
<lifeless> just got back 800Mb of RAM.
<HrdwrBoB> it's evolutions fault spamassasin sucks?
#ubuntu-devel 2006-02-06
<zyga> yes
<Amaranth> jdub shaved his head?
<\sh> yepp
<\sh> he looks so...german...now ;)
<Amaranth> picture?
<\sh> they were on p.d.o.
<kent> \sh: whats the url for p.d.o?  I read p.g.o, p.u.o  but I have not heard of p.d.o  :)
<kent> sorry, that should be p.u.c  i think. (planet.ubuntu.com)
<crimsun> delire: using snd-azx would suffice
<azeem> I just checked, p.u.o works as well :)
<azeem> kent: planet.debian.org
<\sh> trying to grab the article again...
<kent> azeem: planet.ubuntu.org?  ubuntu.org is not owned by ubuntu linux..  so I doubt it worked.
<azeem> planet.ubuntulinux.org
<azeem> it works, but p.u.c is preferred I guess
<\sh> http://davyd.ucc.asn.au/photos/index.php?galerie=lca06
<\sh> e.g.
<\sh> ah here are the right ones :)
<\sh> http://www.vergenet.net/~horms/gallery/lca2006/
<\sh> going to bed
<Slant_Mobile> Can anyone help me out with testing a HAL crasher?
<Slant_Mobile> http://tara.shadowpimps.net/~scott/halwatch.py is a test script. Take a look at it and let me know if it works for you.
<Amaranth> heh, he put a hat on after they were done
* zyga is back
<zyga> Amaranth: what did you want, I'm planning on going to bed soon
<Amaranth> zyga: hang on, let me find the bug number
<zyga> Amaranth: k
<Amaranth> what do you think of http://librarian.launchpad.net/1518749/mokcup%3A%20alacarte%20dialog%20style.png
<Amaranth> basically the guy wants to turn it into a capplet
<zyga> Amaranth: not that bad yet but could run into trouble soon
<zyga> Amaranth: lack of space for new buttons
<zyga> Amaranth: anyway -- isn't that SMEG's layout exactly?
<Amaranth> no
<zyga> hmm maybe I got it confused
<Slant_Mobile> zyga: Why have the move-up and move-down buttons? The items should be draggable if that's important.
<zyga> but I'm sure I already saw buttons on the right of the treeview
<Amaranth> i'm thinking drop the edit/delete/revert buttons
<Amaranth> and move up/down
<zyga> Slant_Mobile: for explicitness, both should be there IMHO
<Amaranth> they are draggable
<crimsun> how does that affect a11y?
<zyga> Amaranth: a menu makes more sense 
<Amaranth> zyga: yeah
<zyga> Amaranth: I got confused when I noticed right-click has a hidden delete option
<Slant_Mobile> zyga: That seems too explicit. Nothing else I can think of uses it.
* Slant_Mobile shrugs.
<Slant_Mobile> Hey, whatever. ;-)
<Amaranth> Slant_Mobile: calum (gnome usability guy) says his idea of a menu editor has those buttons :)
<Amaranth> zyga: yeah, you can only delete it if you made it
<Amaranth> zyga: I'm thinking instead of greying it out i should replace it with Hide/Unhide
<Amaranth> but then ones you can delete wouldn't have that option in the popup...
<zyga> Amaranth: graying is good
<Amaranth> zyga: oh, i thought you meant that confused you
<zyga> Amaranth: I didn't know of right-clickability of the treeview
<Amaranth> ah
<Amaranth> well, all of those things are available elsewhere :)
<zyga> I always expect menu entry + right click :-)
<Amaranth> ?
<zyga> Amaranth: menu should be discoverable
<zyga> Amaranth: the user has no way of knowing that particular component has a context menu
<zyga> Amaranth: advanced users might
<zyga> but anyway all actions should be available via the menu
<Amaranth> how would i make that more obvious?
<Amaranth> they are all available via the menu
<Amaranth> ugh
<zyga> Amaranth: I'm not sure really
<zyga> DARN, xchat quits on ctrl+d
<Amaranth> they are all available via the menu
<Amaranth> so it's not an issue
<zyga> oh?
<Amaranth> just a power-user feature
<zyga> Amaranth: right! sorry 
<Amaranth> iirc it's actually the same popup widget
<zyga> I agree
<Amaranth> heh
<Amaranth> the guy also complained about "Run in terminal" being next to the icon button
<zyga> hmm ...
<Amaranth> i layed it out the exact same way the panel launcher did
<zyga> there are bigger issues
<zyga> but if someone feels that A is better than B then be it
<Amaranth> being consistent is better than being correct :)
* Amaranth removes zyga's ctrl key
<zyga> that's it ... xchat goes to it's own desktop...
<Amaranth> to be honest i'm not too concerned with the UI anymore
<Amaranth> it's better than http://dev.realistanew.com/menu-editor/menueditor.png so i'm happy :)
<zyga> it certainly is :-)
<zyga> did you write if from scratch?
<zyga> just curious
<Amaranth> more or less
<Amaranth> i think as of 0.3 i was using pyxdg
<Amaranth> and more and more of what i needed what migrating/getting added to pyxdg
<Amaranth> err, was migrating
<Amaranth> so now i'm a fancy GUI on top of a complex library :)
<zyga> I patched a part of pyxdg :-))
<Amaranth> oh?
<Amaranth> btw, it also looks better than http://markus.wernig.net/en/it/Screenshot.png so i'm doing ok :)
<zyga> Amaranth: i18n related, gettext support for .desktop :-)
<Amaranth> oh yeah, that
<zyga> argh
<Amaranth> did you email upstream about it?
<zyga> eyes hurt with kde theme
<zyga> Amaranth: I'm sure upstream noticed it here but I'll add that to my TODO
<Amaranth> i haven't had any contact with him in quite a while
<Amaranth> i think pyxdg might be maintainerless
<zyga> hmm
<zyga> that's bad
<Amaranth> yeah, i'm looking into taking over
<zyga> I might pick it up if that's the case
<zyga> oh :)
<Amaranth> hehe
<zyga> I re-wrote bits and pieces
<Amaranth> i wrote a decent bit of the MenuEditor class, indirectly
<zyga> most .desktop parsing is written from scratch
<zyga> :-)
<Amaranth> basically i'd write something, he'd rewrite it
<zyga> we have to talk about this soon :>
<Amaranth> you rewrote the .desktop parser?
<zyga> yes
<zyga> and some other things, I don't remember anymore
<Amaranth> why?
<zyga> the code I saw was so so ugly I had to do it
<Amaranth> does it do evals anymore?
<zyga> ?
<zyga> evals?
<Amaranth> maybe that wasn't that part
<Amaranth> eval(), exec, whatever
<zyga> all the crappy validators all over 
<zyga> no 
<zyga> :-)
<trulux> hmm, I'm testing the psc 1315 with hplip in dapper and seems like it won't work
<trulux> some conflict between cupsys and hplip
<Amaranth> zyga: if you become maintainer you'll have me as a user
<zyga> Amaranth: and mvo 
<trulux> brb, rebppt
<trulux> reboot even
<zyga> Amaranth: I've found that bit 
<Amaranth> zyga: basically with lanius i got what i asked for instantly, i have high expectations :)
<zyga> my code is like 100x easier to use than the old part :-)
<Amaranth> zyga: i think one of my requests is what broke gnome-app-install ;)
<zyga> what was that request? :)
<Amaranth> i don't remember, but it caused an API change
<Amaranth> i think i pointed out a problem with a part of the code that needed fixed and he completely changed it instead
<zyga> ah
<zyga> that's my approach
<zyga> get it right first
<zyga> maintain it later
<zyga> http://ubuntu.suxx.pl/2006--1/for-specific-people/amaranth
<Amaranth> zyga: is this in ubuntu's package right now?
<zyga> I didn't finish the rest really
<zyga> Amaranth: no
<zyga> I was talking with mvo about doing something with it but later forgot about it
<zyga> I need to update my TODO list
<Amaranth> hey, while you're poking around in there, CVS has a utf-8 fix that i keep getting bug reports for, don't suppose you could apply it to the ubuntu package
<zyga> Amaranth: I cannot do jack... I'm just a member
<zyga> Amaranth: which cvs is that btw?
<Amaranth> you can give it to seb128 and say "this works"
<zyga> Amaranth: ping me about that tommorow with a bug report and you've got it
* zyga noticed .bzr directory in pyxdg  :-)
<trulux> who was the one that got the PSC stuff working? I'm testing hplip but won't work, it conflicts with hpoj and cupsys
<trulux> in fact, removing hplip it tries to remove other stuff as well: ubuntu-desktop
<delire> crimsun: thanks
<nekohayo> I noticed that the ekiga package misses to install a required dependency (libopal), where/who can I notify about this?
<crimsun> please file a bug in malone
<zyga> night everyone
<Slant_Mobile> Can anyone help me out with testing a HAL crasher?
<Slant_Mobile> http://tara.shadowpimps.net/~scott/halwatch.py is a test script. Take a look at it and let me know if it works for you.
* irvin is away: I'm busy
* netjoined: irc.freenode.net -> brown.freenode.net
<sladen> blow me.  Made a uinput driver for the thinkpad and GNOME already recognises the UP/DOWN/MUTE codes and draws pretty pictures in the middle of the screen
<Lathiat> sladen: yup :)
<mantiena-baltix> hi all
<maswan> hey guys, think you can poke IBM into supporting Ubuntu for their tape library stuff?
<corey__> maswan, did you file a bug?
<maswan> corey__: with ibm?
<corey__> maswan, no, with Ubuntu
<maswan> corey__: No, I didn't think that'd be a brokenness in ubuntu to file a bug about.
<corey__> maswan, if a piece of hardware doesn't work in Ubuntu, it is a bug
<maswan> corey__: I don't know if it doesn't work, but Ubuntu is not on the list of distributions that they have kernel modules for.
<maswan> (kernel modules and other driver stuff)
<torkel> corey__: may I quote you on that? :-)
<corey__> torkel, yes, you can
<maswan> ftp://ftp.software.ibm.com/storage/devdrvr/Linux/ <- list of the drivers that currently exists
<corey__> maswan, does it work ootb?
<maswan> corey__: As I said, I haven't tried anything yet. We don't even have a non-AIX box on that fcal-switch that can talk with the drives (yet).
<corey__> maswan, take a default install of ubuntu and try it with the hardware. If it doesn't work, file a bug
<maswan> corey__: I was more fishing for the IBM stamp of approval this time.
* maswan nods
<corey__> torkel, the only way we are going to get good hardware support is if people stop assuming that things not working is normal and start filing bugs about it
<sivang> maswan: why is this related to the AIX box?
<corey__> then Canonical can go to the manufacturer, point to the bug report and say "Look, we have customers who want it"
<maswan> corey__: What would you put the odds at a binary kernel module for suse's 2.6.5 or rhel 2.6.9 will work?
<sivang> maswan: it would be good first to report abug against ubuntu re that, and you can in parallel poke IBM for that. seeing that there a community demand for something, can push things further.
<corey__> maswan, I expect zero, but I am not a kernel guy
<maswan> sivang: the AIX box is the only box that currently talks to the tape library. we'd like to put in a linux (Ubuntu) box with ability to talk to the tape drives too.
<maswan> But yeah, I'll do that after we try it out.
<torkel> corey__: I know and I agree with you.
<Keybuk> http://arstechnica.com/news.ars/post/20060131-6087.html
<siretart> Keybuk: is pitti around you somewhere?
<corey__> Keybuk, indeed. those that wag tongues will have those tongues wagging. On to NM. I hear good news for NM and madwifi (or just -ng?)
<Keybuk> siretart: pitti will not be around today
<siretart> Keybuk: but he is in london, is he?
<Keybuk> siretart: indeed
<Keybuk> corey__: it's certainly working for me; and I'm working on it
* corey__ hugs Keybuk 
<siretart> Keybuk: I'd like to fix bug #5387, I prepared this patch: http://paste.ubuntuusers.de/1662
<Ubugtu> malone bug 5387 in glibc "clock-applet: first day of week" [Normal,Unconfirmed]  http://launchpad.net/bugs/5387
<sivang> Keybuk: wow
<siretart> but since locales is a quite critical package, I'd like to get a green light first :)
<siretart> Keybuk: jbailey perhaps around?
<Keybuk> siretart: jbailey is around
<sivang> maswan: this is a tape server box, or do you want to replace AIX with ubuntu ?
<siretart> Keybuk: I read in the bugzilla log that he wanted to check something about gtk agreeing glibc. could you please ask him about status and if he was fine with this upload?
<Keybuk> siretart: repeat
<Treenaks> Any news on fixing X breakage this week?
<Treenaks> (ati on mac mini/HP NW8240 are broken for me)
<siretart> jbailey: I'd like to fix bug #5387, I prepared this patch: http://paste.ubuntuusers.de/1662
<Ubugtu> malone bug 5387 in glibc "clock-applet: first day of week" [Normal,Unconfirmed]  http://launchpad.net/bugs/5387
<siretart> jbailey: do you or pitti plan any upload of langpack-locales anyway? are you d'accord with the patch?
<Kinnison> Morning
<dholbach> good morning!
<ajmitch> morning dholbach 
<Keybuk> jbailey: http://arstechnica.com/news.ars/post/20060131-6087.html
<jbailey> siretart: The new locales update apparently already has that update.
<siretart> jbailey: new locales update? you mean that one that has not been uploaded yet or some upload in the past?
<zwnj> where from i can find documentation about the LANGUAGE envvar, which ubuntu (debian?) uses?
<Kamion> it's a GNU gettext thing
<Kamion> the gettext(3) man page mentions it
<zwnj> Kamion: but i haven't seen on fedora/redhat...
<Kamion>        If  the  LANGUAGE  environment  variable  is  set to a nonempty
<Kamion>        value, and the locale is not  the  "C"  locale,  the  value  of
<Kamion>        LANGUAGE is assumed to contain a colon separated list of locale
<Kamion>        names. The functions will attempt to look up a  translation  of
<Kamion>        msgid  in each of the locales in turn. This is a GNU extension.
<zwnj> Kamion: hum, lemme see.  thanks
<Kamion> it's not a Debian extension
<Kamion> (nor Ubuntu)
<jbailey> siretart: The as yet inexistant one.  We have a set of updates that I haven't finished assembling yet.
<siretart> jbailey: ok. allright, then
<sladen> mjg59: please grab http://www.paul.sladen.org/ubuntu/upload/hotkey-setup_0.13ubuntu1-thinkpad-keys.debdiff
<lifeless> mjg59: I mean as in 'my X1 is sporadically hanging on resume, and suspend to disk is still 100% dead'
<mjg59> lifeless: Running what?
<mjg59> And what do you mean by "100% dead"?
<siretart> sladen: that patch would deprecate tpb :)
<Lathiat> siretart: doesn't mention lcd brighteness tho
<lifeless> mjg59: dapper latest
<lifeless> mjg59: same symptoms as when I reported the bug a while back
<mjg59> lifeless: Number?
<lifeless> I try every week or so
<mjg59> (I'm sorry, I've got about 2 billion bugs of "Suspend doesn't work" so it's hard to remember them all)
<lifeless> mjg59: I don't know the number offhand - sorry. I'll see if I can find it
<mjg59> sladen: Would be preferable if you didn't use uinput, but went directly to /dev/input/event(whatever is the first keyboard)
<mjg59> sladen: See acpi_fakekey in the latest acpi-support
<mjg59> That way it looks like it's coming directly from the keyboard, rather than a separate input device
<mjg59> sladen: Also, do we /really/ want to send the volume keys? They act on something entirely different
<sladen> mjg59: r30, r31, r40, r40e, r50e don't have a hardware-mixer.  And the setup seems to work better than I expected... try it
<mjg59> sladen: Hm. Ok - will do in a moment
<sladen> mjg59: ...better than expected on the thinkpad that I have that *does* have hardware mixer
<mjg59> sladen: It would be nice if it could interface with the alsa mixer somehow...
<sladen> mjg59: the slight thing that breaks is  hardware mute, then software unmute
<mjg59> sladen: I'm not too sure that's "slight"
<mjg59> sladen: How about only sending them in the case of it being a machine with no hardware mixer?
<sladen> mjg59: no worse than the current situation;  but at least you get little on-screen boxes now
<sladen> mjg59: the mute issue still occurs as they have hardware mute (but not hardware volume)
<mjg59> Oh nngh.
<mjg59> Bloody hardware.
<sladen> mjg59: I've been using it for a few hours;  run it for a day, see what you think, and in the meantime I'll ponder the Ultimate Solution.
<sladen> good point siretart;  mjg59: add  conflicts: tpb
<mjg59> sladen: Ok. But please do add support for using the event device, rather than uinput
<siretart> sladen: hmm. tpb offers aditional functionality, I think. can't your daemon please be packaged extra, so hotkey-setup and tpb are installable together?
<hunger> My box does no longer shut down properly. The screen turns black, nothing else happens. How can I debug that?
<siretart> sladen: I think of users who prefer tpb
* StevenK hates tpb.
<StevenK> I actually prefer how the OSD stuff looks in Windows.
<sladen> siretart: the 'extra' functionality belongs in the days before ACPI, and Ubuntu auto-hotkey support.
<mjg59> siretart: Which extra functionality?
<siretart> does sladen's daemon detect FN-Thinklight as well as brightness?
<siretart> what about zoom? (fn-space)
<sladen> siretart: they're done in hardware.  I'm looking at exposing them as HID events and hacking gnome-settings-daemon to show a dailogue
<sladen> siretart: yes, that shows up as a normal keyboard keypress
<Burgundavia> siretart, what does that zoom do with tpb? I have a Toshiba laptop with something similar
<fabbione> morning guys
<fabbione> slomo_: ping?
<sladen> Burgundavia: in Windows, it changes the screen to 640x480
<Burgundavia> sladen, and in Ubuntu?
<siretart> Burgundavia: in windows, it zooms the screen. in tbp, you can install a trigger script of you choice
<sladen> Burgundavia: whatever you set  KEY_PROG2  to do.  There's nothing better to map it to presently
<Burgundavia> sladen, ah, so no default functionality
<siretart> yes
<sladen> Burgundavia: you're welcome to recommend something.
<Burgundavia> sladen, I have struggled and completely failed to find anything useful for the key
<jsgotangco> same here
<Burgundavia> sladen, that fits within the concept as outlined by the icon and its use in Windows
<sladen> Burgundavia: probably best to leave it to the user to remap
<jsgotangco> not sure if its possible to even do it on the fly
<mjg59> sladen: Ok, that seems to work better than I expected
<mjg59> So convert it to bind to the keyboard event device and I'll upload it
<sladen> mjg59: I'd prefer it to stay as a separate input device.  I want to be able to add an LED for the mute and possibly an ABS input for brightness.  If there is more than one keyboard in the system (eg a USB one) then it doesn't seem to make sense to me.
<maswan> sivang: We want to store data to our tape library from the linux machine without having to run all the data through the AIX box for performance reasons. This can be done, since the tape drives have some support for this.
<sivang> maswan: I see, interesting.
<mjg59> sladen: We can reliably locate the first keyboard
<mjg59> Given that the keys are actually /on/ it, it seems sensible to put it there
<maswan> sivang: http://www.redbooks.ibm.com/abstracts/tips0118.html?Open
<maswan> sivang: that basically explains it, how to store data with only having to talk to the main server for metadata, not the large data streams
<sladen> mjg59: However, they come from a very separate bus topology.  (NVRAM poking) rather than a serio device
<mjg59> sladen: So?
<mjg59> It makes sense for keys on the keyboard to generate events corresponding to the keyboard device
<mjg59> On the other hand, it does make it slightly awkward to add the LED thing
<sladen> mjg59: I'll go and look at the acpi_fakekey, and think about the mute synching and see what I come up with
<sladen> mjg59: if you can get that out and tested for the comments in the meantime it would be useful
<mantiena-baltix> Kamion, did you got my email (from mantas@akl.lt) ?
<Kamion> mantiena-baltix: yes, and for pity's sake stop hassling me about it
<mantiena-baltix> Kamion, ok, if you are busy I think someone other here could know how to set value of debconf template with python ;)
<dholbach> mantiena-baltix: Write to a mailing list.
<Kamion> mantiena-baltix: you could always try reading the code for other examples
<Kamion> but perhaps that's too difficult
<Kamion> I mean it's not like there are a bunch of examples scattered throughout espresso
<Kamion> and good documentation of the debconf protocol in debconf-devel(7)
<Kamion> I really don't appreciate being harassed every morning because you need me to walk you through things; I've been ill and continue to be busy, and really don't have time
<Kamion> mantiena-baltix: if you'd just left me alone, I would have answered the e-mail in reasonable time
<Kamion> but I won't reward you hassling me like this
<geneo93> anyone around
<hunger> geneo93: Yes... they were a couple of minutes ago.
<geneo93> well i was just about to tell them about nvidia patch for the new kernel
<geneo93> oh well
<hunger> geneo93: Write a wishlist bug:-)
<geneo93> na no time have to move on
<hunger> geneo93: Things said on IRC tend to get forgotten as soon as they scroll out of the screen.
<geneo93> they'll figure it out soon same with alsa
<mantiena-baltix> Kamion, I just asked if you got my email, I don't think it's hassling
<geneo93> sounds lile old linux chat now
<geneo93> bitchy
<jsgotangco> mantiena-baltix, let's not add further friction to this...
<mantiena-baltix> ;)
<mjg59> sladen: Any reason you aren't sending KEY_BRIGHTNESSDOWN and KEY_BRIGHTNESSUP?
<mjg59> Or is it because you want to send the absolute value?
<sladen> mjg59: they're in hardware (and yes, absolute value)  I suppose I could send them and see what happens...
<sladen> mjg59: hmmm/mmm.  Brightness Up sends an ACPI HKEY.  Brightness Down, doesn't.
<mjg59> Heh.
<mjg59> We can ignore the ACPI events, I think
<sladen> mjg59: it would be good to have a HUD daemon that *displays* events, but doesn't do anything with them
<sladen> Head Up Display
<sladen> mmm, funky.  Fn-PgUp now goes to the screensaver...
<sladen> mjg59: I think g-s-d only listens for Brightness when it's compiled on a Mac and then fiddles with the framebuffer
<mjg59> sladen: Currently, yes
<pef> hello
<Gloubiboulga> hey pef 
<pef> Gloubiboulga: heya ;)
<sladen> anyone know the build time and disk-requirements for 'evolution-data-server' (only want to build 'libecal')
<StevenK> Build needed 00:08:51, 173532k disk space
<StevenK> According to terranova
<sladen> hmmm.  /me eyes up df
<dholbach> If you don't build it in a chroot, it won't be that much space.
<simira> hey, where did you guys put Mithrandir today?
<StevenK> In the closet.
<dholbach> simira: He's not feeling weel.
<dholbach> well
<simira> dholbach: argh... asleep, then? :-/
<Kamion> simira: in his room, at any rate; he came down briefly earlier
* jbailey wonders why this doesn't work:
<jbailey> A="Canada/Eastern" md5sum ${A} posix/${A} right/${A}
<sladen> jbailey: work, in what way?
* sladen sees
<mjg59> Woo
* mjg59 gets SDHCI working properly
<Kinnison> mjg59: whassat?
<Treenaks> mjg59: \o/
<mjg59> Treenaks: I've added a hack to make it work on TI chipsets
<Treenaks> Kinnison: SD/MMC cardreader found in lots of laptops
<Treenaks> (basically)
<mjg59> Kinnison: Anything with a PCI class of 0805
<sladen> jbailey: but, if you put a ;   A=Canada/Eastern ; md5sum ...
<Kinnison> mjg59: My TypA tosh SD reader has that
<Treenaks> mjg59: what kind of hack?
<Kinnison> mjg59: yay
<Treenaks> mjg59: a 'Hey you're a TI; *poke*' ?
<Kinnison> 0000:01:0d.0 0880: 1179:0805 (rev 03)
<Kinnison> is that what you mean?
<simira> Treenaks: good afternoon. Are you also in London?
<mjg59> Kinnison: Class of 0805, not device of 0805
<Kinnison> mjg59: Oh
<mjg59> Kinnison: (Sadly)
<Treenaks> simira: no, I'm one capital city to the east ;)
<Treenaks> simira: (Amsterdam)
* Kinnison sobs
<mjg59> Kinnison: There's a chance it might work. Once the updated version hits the kernel, you can try echoing it to sysfs
<Kinnison> right
<Kinnison> This is going into daper?
<Kinnison> erm, dapper
<mjg59> Treenaks: There's a bit that needs to be set in the flash media chipset to tell it to let the sdhci hardware have the SD slot
<jbailey> sladen: Thanks, that turned out to be the best way.
<mjg59> Kinnison: Hope so
<mjg59> I've just mailed the patch to Ben
<sladen> bling.  just the Acceleromator to claim 100% X40 support
<mjg59> sladen: We have the accelerometer driver
<mjg59> Just no way of usefully saving the drive
<Kinnison> mjg59: cool
<Lathiat> i guess a hdparm -y is a bit too slow?
<Treenaks> mjg59: hdparm -Y
<Treenaks> ?
<Lathiat> -Y is bad, it wont wake back up
<Lathiat> -y is better, it is a little on the slow side of happening tho
<mjg59> Treenaks: Not fast enough, and we need to freeze the IDE queue to stop it spinning the drive back up
<Treenaks> mjg59: scary
<mjg59> There's hacky code to do it, but it's not getting integrated upstream
<mjg59> I may look at including it
<mjg59> Wouldn't help the SATA case, though
<Lathiat> hdparm -y works on my sata
<Lathiat> i assume mentioned code is similar, or not?
<mjg59> Nope
<Lathiat> ah ok
<mjg59> You need to stop the kernel sending further requests to the drive
<Lathiat> -Y will do that if you can keep the magic in memory to wake it back up :)
<Lathiat> heh
<Lathiat> the man page says the kernel will wake it back up from -Y if its needed but it doesnt
<mjg59> Lathiat: Nah, -Y just means the kernel shits itself
<mjg59> And still isn't fast enough :)
<Treenaks> mjg59: what _is_ fast enough then?
<mjg59> Treenaks: There's a magic head unload command that the Thinkpad drives understand
<siretart> >> ls -lad /usr/bin/X11
<siretart> lrwxrwxrwx 1 root root 6 Jan 20 11:51 /usr/bin/X11 -> ../bin/
<siretart> does this make sense?
<mjg59> siretart: Yeah
<siretart> never mind, it does
<siretart> er, but isn't /usr/bin/X11/../bin/ equal to /usr/bin/bin/?
<Lathiat> theres no trailing /
<Lathiat> so i assume X11 is in /usr/bin context
<Lathiat> so ../bin is /usr/bin/../bin
<lifeless> siretart: yes, but thats no equal to /usr/bin/X11 -> ../bin/
<Lathiat> but it is confusing
<lifeless> the symlink name is stripped before evaluating the path
<lifeless> is /usr/bin/ + ../bin/
<lifeless> consider a symlink foo->bar
<siretart> ah, sure
<siretart> confusing shit..
<sladen> mjg59: all the harddisk supplied in machines with the accelerometer support two extra instructions that put the disk in a mode where it will not unpark the heads until told to
<mjg59> sladen: So what happens to the commands sent by the kernel?
<sladen> mjg59: they get queued up.  
<mjg59> How?
<sladen> mjg59: and it responds with 'busy' or something to anything it can't answer from RAM
<mjg59> You'll get kernel timeouts and discarded writes
<sladen> just imagine a seek that takes 5 seconds instead of 50msec
<luisv> hey... I grabbed yesterday's daily install CD, md5summed, did the CD's integrity check (all checked out), and then when I did the install, it said packages left and right were corrupt- known problem?
<zul> heylo
<luisv> morning, mako.
<tepsipakki> seb128: why is there no gstreamer0.10-plugins-bad? Is it just that no-one has had time to do it, or will it ever be included (in multiverse)?
<tepsipakki> I just upgraded my laptop to dapper, and noticed I can't listen to my music with rhythmbox anymore ;)
<tepsipakki> it's all .m4a
<tepsipakki> maybe I'll just ask on u-d
<HiddenWolf> BenC: ping
<BenC> HiddenWolf: pong
<HiddenWolf> BenC: regarding bug 29789 you told me to test your kernel-daily build, but there hasn't been one since that comment
<Ubugtu> malone bug 29789 in linux-source-2.6.15 "tv card audio not working" [Normal,Needs info]  http://launchpad.net/bugs/29789
<BenC> HiddenWolf: ooh, there is one, but I didn't move it to the archive...I'll get that shortly, sorry
<HiddenWolf> BenC: right, that's cool. Give me a heads-up when it's there and I'll test asap.
<mjg59> BenC: Don't suppose you've had a chance to look at those patches?
<BenC> mjg59: applying them all today
<BenC> hopefully have a kernel upload tomorrow
<zul> including mine? :)
<mjg59> BenC: Cool
<mjg59> Keybuk: So, what are we going to do about loading mmc_block? :)
<mjg59> Also, could you put a list of cards that don't work with NM up somewhere?
<hunger> Is NM part of ubuntu now?
<tseng> its "part" of ubuntu
<tseng> its not in ubuntu-desktop
<hunger> tseng: Yes... but only in universe. Just checked myself.
<mjg59> hunger: That's the aim
<hunger> So it will be moved into main eventually?
<mjg59> With luck
<hunger> mjg59: Damn:-( Never worked properly for me.
<BenC> oooh, upgrading bluez-utils is bad
<BenC> stops my mouse from working during most of the dist-upgrade
<mjg59> hunger: "Never worked properly" is not terribly descriptive
<HiddenWolf> mjg59: it seems to indicate that it did not live up to hunger's expectations
<hunger> mjg59: brings up the wrong interfaces, does not connect to my wlan, never shuts down interfaces it brought up and restarting interfaces I manually brought down.
<mjg59> HiddenWolf: For all I know he expected it to bring him untold riches, so...
<mjg59> hunger: What was the last version you tried?
<Treenaks> Untold riches? where?!
<HiddenWolf> mjg59: *grin*
<HiddenWolf> Treenaks: ssssht
<hunger> mjg59: last test was a couple of weeks ago.
<HiddenWolf> Treenaks: they are *untold* riches
<mjg59> hunger: What sort of hardware?
<hunger> mjg59: I keep trying it since people claim it is cool:-)
<hunger> mjg59: madwifi wlan, lan uses tg3 driver.
<mjg59> It won't work sensibly with madwifi due to madwifi being awful
<mjg59> Next lrm should improve things
<hunger> mjg59: I hope so... nm did not support wpa either... which is a showstopper for me.
<mjg59> It now supports wpa
<hunger> mjg59: Cool. Have to try it again... even though the applet looks sooooo ugly on my kde desktop:-)
<Treenaks> if you have wpasupplicant
<Keybuk> mjg59: we haven't decided to go with madwifi-ng yet
<hunger> Treenaks: I do... I am connected over a wlan using wpa right now.
<Keybuk> because you suck and don't have an amd64 we can test it on
<mjg59> Keybuk: Well upload the damn thing and see if anyone complains
<hunger> mjg59: I'm waiting for it:-)
<Keybuk> mjg59: I have two packages people can test, but it's not going into the archive until it's known to work
<Keybuk> upstream have said they're sure it's not 64-bit safe
* hunger twiddles its thumbs, waiting for uploads.
<mjg59> Christ
<mjg59> Keybuk: The amd64 I have is locked to HP wireless cards, and the only Atheros I have is with you in London at the moment, so...
<luisv> if you throw me a package, I'm happy to test atheros
<mjg59> luisv: On amd64?
<luisv> oh.
<luisv> missed that detail.
<mjg59> Heh
<luisv> (people have amd64 laptops?)
<mjg59> luisv: Sadly, yes
<HiddenWolf> mjg59: heh, agreed.
<HiddenWolf> Like sticking a v8 in a mini
<luisv> I like to light my crotch on fire from time to time too, but there are more efficient ways than carrying around an amd
<mjg59> I haven't seem an attractive amd64 laptop yet
<HiddenWolf> luisv: you wouldn't be the first with first degree burns to be admitted into an hospital. ;)
<luisv> sadly 'attractive' is not a key factor in the PC market
<mjg59> The HP one is big, heavy and nasty
<HiddenWolf> luisv: altho I have to be fair, most of those people did not put on pants before firing up their laptops
<Keybuk> who wears pants while using a laptop?
<luisv> Keybuk: some of us have to go to 'offices'
<Keybuk> you're not allowed to work naked?
<mjg59> Keybuk: Have you mentioned these test packages on the mailing list?
<luisv> Keybuk: 'law school'
<Keybuk> mjg59: no, adam made them and was going to get round to it before he dropped down dead
<luisv> Keybuk: 'sexual harassment'
<HiddenWolf> luisv: hey, us geeks have to do something to get some sexual attention. ;)
<mjg59> Keybuk: If we don't make a decision soon, there's not going to be time to make sure everything actually works sanely
<Keybuk> HiddenWolf: yes, it's called "showering"
<HiddenWolf> Keybuk: What an exceptional concept, allow me to ponder.
<jbailey> Keybuk: Showering in what?
<dilinger> jbailey: capacitors!
<Keybuk> MONEY
<HiddenWolf> jbailey: keybuk in a speedo. ;)
<luisv> ewwww.
<jbailey> Keybuk: Known to be quite effective. =)
<jbailey> HiddenWolf: That's sort of like raining cats and dogs..  But different.
<HiddenWolf> jbailey: enlightening
<mjg59> Keybuk: (You've killed Adam as well? Bastards)
<Keybuk> mjg59: there's only 5 of us left!
<mjg59> Jesus
<mjg59> You've been trying hard
<JaneW> mjg59: yeah Adam's dead
<Keybuk> I'm being blamed because I'm wearing my "I am Fedora" t-shirt
<jbailey> mjg59: It's the "I AM FEDORA" shirt that Scott's wearing.
<JaneW> 'hear me roar'
<hunger> Is network-manager installable? The postinst fails for me.
<jbailey> JaneW: Already done. =)
<mjg59> hunger: Ought to be. How's it failing?
<Kinnison> Anyone here up on the history of the 2.6.15 packages in dapper?
<mjg59> Kinnison: I'd expect benc to be...
<hunger> mjg59: complaining about some missing file in /etc/dbus-1/event.d
<jbailey> mjg59: Reminds me that I should try hibernate again now that I've logged in and out again
<mjg59> hunger: Your problem reports are a model of information content
<mjg59> Which file?
<AlinuxOS> hello, anyone can package for dapper and breezy a .ttf Georgian fonts... because there is locales ka_GE.UTF-8 without supported fonts... and that's very important for Dapper's native georgian language support.
<mjg59> AlinuxOS: Are there any Free Georgian fonts?
<jbailey> mjg59: It blanked the screeen and then completely failed to hibernate, which I haven't tried otherwise on this laptop.
<jbailey> Lemme do that.
<AlinuxOS> mjg59, free like word ...and not free like beer :)
<mjg59> AlinuxOS: In that case, no
<mjg59> They can't go in main
<AlinuxOS> mjg59, GPL
<AlinuxOS> LGPL
<AlinuxOS> i mean.
<mjg59> Oh, right
<mjg59> So both
<mjg59> AlinuxOS: Got a pointer?
<AlinuxOS> pointer? (sorry for english)
<Treenaks> AlinuxOS: a link
<mjg59> AlinuxOS: Where can these fonts be obtained?
<AlinuxOS> I have them...
<mjg59> jbailey: Was that yesterday's attempt, or today?
<tseng> AlinuxOS: the original source.
<AlinuxOS> http://fonts.ge/?load=welcome here is a big collection
<AlinuxOS> but mainly I've tested 3 type of fonts.
<mjg59> AlinuxOS: Sadly, I don't speak Georgian :) Which ones are LGPLed, and where can we find a link to the license?
<AlinuxOS> mjg59, sadl there is no link to license because it's made by Georgian Institute...and it's open for all...
<AlinuxOS> this site provides only open non commercial fonts.
<mjg59> AlinuxOS: Without an attached license, we can't distribute the fonts
<mjg59> We need to know we can distribute modified versions and that people can use them commercially
<AlinuxOS> http://aiet.qartuli.net/docs/georgian_on_linux_en.php
<AlinuxOS> here is other 3
<AlinuxOS> The provided fonts are licensed for free distribution by individuals and by companies independently, or along with any GNU Linux System or other open-source software, as well for free use of the typefaces for commercial and noncommercial needs.
<hunger> mjg59: Sorry... lost connection to my irc client after NM has hosed my setup yet again.
<mjg59> hunger: NM will not usefully work with madwifi
<hunger> mjg59: I can not even connect to my wlan anymore, not even after deinstalling NM again.
<hunger> mjg59: /var/lib/dpkg/info/network-manager.postinst: line 17: /etc/dbus-1/event.d/26NetworkManagerDispatcher: No such file or directory
<mjg59> AlinuxOS: The text there doesn't give us any permission to modify the fonts
<AlinuxOS> mjg59, so brother ? everything ok?
<hunger> mjg59: The connection dropped when I was about to paste that line.
<AlinuxOS> mjg59, :((((
<AlinuxOS> oh no so fiscal...
<AlinuxOS> we have no other fonts !!
<AlinuxOS> we have very yong UTF Unicdo non commercial fonts...
<AlinuxOS> I'm administrator of Ubuntu Georgian Translation team..
<AlinuxOS> And I do manually everything to have georgian free fonts...
* hunger sighs... wpa is hosed for good again:-(
<jbailey> mjg59: Today's attempt.  I just did a hibernate by hand and I noticed that the previous attempt appeared to have run out of memory.
<jbailey> mjg59: So it might have worked if it hadn't hit that case.
<AlinuxOS> so could you please include georgian free fonts in Ubuntu distro? I knew that Mandrive uses this 3 too...
<mjg59> jbailey: Ok
<mjg59> AlinuxOS: I'm looking into it
<AlinuxOS> mjg59, please.
<AlinuxOS> mjg59, thank you...
<hunger> Need to reboot... at which time the next problem will bite me: On reboot the screen goes blank and nothing happens anymore. How can I debug that?
<hunger> I have a init-script that turns of usplash... maybe that is causing trouble?
<jbailey> mjg59: At some point I should probably collect information from this laptop for why suspend doesn't work.
<mjg59> AlinuxOS: Is there anywhere on the BPG site where I can get these fonts?
<mjg59> http://aiet.qartuli.net/docs/georgian_on_linux_en.php provides no proper license information
<AlinuxOS> mjg59, We have another problem too, we (2 persons) are translating GNOME for Ubuntu, but the main GNOME has no our translations... our Project manager is not working at all from 2.10 version..
<AlinuxOS> there is 0% of translation...
<AlinuxOS> so GNOME can't receve my and my friends tested .po files on Ubuntu Linux.
<AlinuxOS> mjg59, no. It's the source font for fonts.ge.
<mjg59> AlinuxOS: Without a license, we cannot distribute the fonts
<AlinuxOS> http://www.novell.com/products/linuxpackages/professional/bpg-fonts.html mjg59 
<AlinuxOS> even SuSE provides them
<AlinuxOS> http://aiet.qartuli.net/docs/georgian_on_linux_en.php this site is the source.
<Treenaks> AlinuxOS: that doesn't make them legal
<Treenaks> AlinuxOS: uh.. that doesn't make it legal for us to distribute them
<mjg59> AlinuxOS: That's still not a license
<AlinuxOS> Treenaks, ok... if dont' want... I can't force you... I said there is no license here is autor's site: http://aiet.qartuli.net/old_public_html/kafont/index.html
<mjg59> Nnf. Ok, I guess that provides distribution rights.
<mjg59> But not modification.
<mjg59> AlinuxOS: We can put it in multiverse - I'm afraid that's the best that we can do
<AlinuxOS> mjg59, when a georgian user cheks "Georgian in Language Selector" he needs a fonts...
<BenC> just noticed that evolution hasn't crashed on me in awhile...guess that means it's stabilizing :)
<Kinnison> firefox in breezy crashes on me daily
* Kinnison hopes it's better in dapper
<mjg59> AlinuxOS: We will not ship non-modifiable fonts in main
<AlinuxOS> gucharmap without this font displays nothig...
<Kamion> AlinuxOS: what mjg59 said; it doesn't matter how useful they are
<AlinuxOS> so this font are fondamental for GNOME or KDE interface...in another way there is no possibiliy to get georgian GNOME
<Kamion> Flash is useful to some people too, but it's still in multiverse
<Kinnison> BenC: try getting evo to render an email with a line > about 32KiB
<Kinnison> BenC: That reliably seems to crash evo on my breezy box
<Kamion> AlinuxOS: please stop arguing how useful it is
<AlinuxOS> so georgian locales must be linked like dependencie for this fonts.
<mjg59> AlinuxOS: I'm sorry, but we're a free software distribution. Everything that goes in main has to be modified.
<Kamion> AlinuxOS: it would be more productive to put effort into getting the Georgian Institute to declare that these fonts may be modified
<mjg59> Sorry, modifiable. Not modified.
<Kamion> (and that we can distribute modified versions)
<mjg59> AlinuxOS: As Kamion said - we will happily distribute fonts that we can modify, and if you can get the copyright holders to give us that permission we'll do it in an instant
<mjg59> But until then, the best that we can do is put them in multiverse
<AlinuxOS> Oh God, ok.... I'm mailing for a month to this fu**** GNOME "mantainer" that hase provided this fonts... there is no other declarations... he don't responds me :(
<AlinuxOS> what can I do... :(
<mjg59> AlinuxOS: Produce your own fonts?
<mjg59> I'm sorry, but there's really nothing more we can do
<AlinuxOS> mjg59, I know some people... maybe they can help me to find tham...
<mjg59> AlinuxOS: Ok, cool
<mjg59> If you can find fonts that we can put in main, we'll happily do so
<Kinnison> Kamion: can you take a call right now?
<AlinuxOS> mjg59, ok...
<AlinuxOS> I'll ping you bro...
<AlinuxOS> sorry for my emotional speaking :)
<Mithrandir> dholbach: why does ekiga traverse the whole of /dev on startup?
<Kamion> Kinnison: sure
<AlinuxOS> I really love ubuntu and we are only 3 persons who use ubuntu in this moment...
<Kinnison> Kamion: Can you /msg me your cellphone number?
* Kinnison left his cell in the hotel room
<Kinnison> (go me)
<Treenaks> Kinnison: nono.. the "hotel room" is your cell!
<AlinuxOS> but when Ubuntu will speak in georgian :) then things become better :)
<AlinuxOS> mjg59, So I can't understand why SuSE and Mandrake provides this fonts....maybe because they are commercial
<AlinuxOS> ?
<mjg59> AlinuxOS: They provide non-free software
<BenC> wonder if I can convince infinity to include mol.ko build in linux-restricted-modules
<BenC> actually, it's really free, so it could go in the main kernel build under drivers/macintosh/
<Mithrandir> mjg59: if my machine suddenly believes it is very hot and runs the fan at full speed, what's a good way to convince it's not?
<mjg59> Mithrandir: Cool it down?
<mjg59> This is your X40?
<Mithrandir> yes
<Mithrandir>      Thermal 1: ok, 43.0 degrees C
<mjg59> No idea. It's handled by the BIOS.
<Mithrandir> it's running the "omg, I'm dying" mode on the fan.
<Mithrandir> rmmod fan ; modprobe fan didn't fix it.
<hunger> Mithrandir: A can of compressed air helped with my T40.
<hunger> Mithrandir: The fan and its surroundings was so covered in dirt that it did no longer work properly.
<Mithrandir> hunger: well, it just started and didn't make audible noise before that.
<Mithrandir> I'll just try rebooting
<mako> luisv: hola
<luisv> your captcha, is, indeed, ingenious
<trulux> let's see if any upgrade covers the printing stuff
<mako> luisv: i've got a paper on it if you want to know the larger infrastructure that it's part of
<mako> luisv: the paper is not really done yet but it gets the point across
<luisv> am quite curious, definitley send it along
<mako> luisv: cool
<luisv> you could perhaps send it in the same email as the belgian beer document
<luisv> :)
<luisv> trulux: is printing not working for you in dapper?
<mako> luisv: i don't have access to my computer right now
<mako> luisv: i'm locked out of my office :)
<luisv> haha
<mako> but i emailed the paper to someone last night so i have it :)
<trulux> luisv: yep, I had my PSC 1315 working neatly with Breezy and Hoary but with dapper it's not anymore working
<trulux> luisv: at most I get printing
<luisv> all gnome apps hang for me in dapper ATM when I try to print
<trulux> luisv: hplip won't detect devices, hpoj neither
<mako> it was one of those "i remember my keys are inside as the locked door closes" mornings
<luisv> haven't really looked into it
<luisv> mako: doh.
<mako> man.. if people actually ever printed, we would find these bugs earlier
<HiddenWolf> mako: it's that printing is usually such a painful experience that we tend to do it somewhere else.
<lamont-work> mako: and an HP-all-in-one USB printer on an amd64 kernel with 32-bit user space doesn't work either - actually, just the scanner seems b0rked.
<lamont-work> then again, taht's breezy
<bmon> trulux: try ln -s /dev/usblp0 /dev/usb/lp0
<trulux> bmon: let's check
<mako> we choose our battles
<mako> and i gave up on printing in like '98 :)
<mako> it's perhaps time to revisit it
<mako> i traded my printer for a better sound card IIRC
<Treenaks> mako: wasn't it you who told me about CUPS' printer browsing function in Mataro? :)
<Amaranth> i gave up on printing when i installed windows to do school work :P
<trulux> *** Found "psc 1310 series " but failed to communicate with it!
<trulux> doh
<mako> Treenaks: i find that unlikely
<Treenaks> mako: hm, then it was Pitti
<lamont-work> Treenaks: I'd bet on either keybuk or pitti
<mako> oh, i just let other people set up printers and i print from their computers :)
<Treenaks> mako: :)
<bmon> trulux: did you restart hplip/cups?
<trulux> bmon: won't change the status with hplios nor hpoj
<bmon> thats true
<trulux> bmon: hplip seems to recognize it
<bmon> oh yeah
<bmon> cheack your ppd file
<trulux> bmon: let's check if it really works :)
<bmon> mine was corrupted
<bmon> in an upgrade
<trulux> 01/02/06 16:32:36             Tri-color cartridge is low on ink (1502)
<trulux> hah
<Amaranth> 01/02/06?
<Amaranth> oh, damn europeans :P
<trulux> heh
<trulux> bmon: OK, so, udev package/hplip should be fixed
<trulux> bmon: I checked it but missed to verify if device path was the right one
<bmon> bug 28797
<Ubugtu> malone bug 28797 in hplip "hplip only searches for printers in /dev/usb/*, but the device is /dev/usblp0" [Normal,Unconfirmed]  http://launchpad.net/bugs/28797
<trulux> bmon: at least it's an eays issue
<trulux> bmon: good, someone worked on it? I would be pleased of helping
<bmon> trulux: No thats a bug I filed, but as far as I know no one has had time to work on it yet
<trulux> bmon: I will fix it now
<bmon> cool
<trulux> then sleep some time :)
<dholbach> Mithrandir: good questions.
<mjg59> Mithrandir: The X40 fan is not OS controlled
<mjg59> The fan module does nothing
<Bicchi> What is the version number of Gtk+ that comes in  breezy?
<tseng> packages.ubuntu.com
<Bicchi> yeah, but i do not know the name of the library
<tseng> libgtk2.0-0
<Bicchi> thanks
<dholbach> lamont, lamont-work: can you give back ekiga?
<dholbach> please :)
<seb128> who broke the upload queue?
* lamont-work makes the attempt
<lamont-work> seb128: sure it's not just due to excessive gnome uploads? :-)
<ogra> seb128, launchpad ? 
<dholbach> lamont-work: surely not. we took things extra-slow :-)
<seb128> lamont-work: maybe, I blame dholbach
<lamont-work> seb128: blame kiko - it's more fun
<seb128> right
<ogra> lamont-work, not that it would be less fun to blame dholbach ;)
<simira> can someone please fix my weather! It's broken!
<giftnudel> does it have a leak?
<ogra> simira, file a bug please :P
<ogra> we'll care for it then ...#
<lamont-work> ogra: nah - dholbach is too nice... kiko, OTOH, actually made me sign the CoC this week.  finally
<dholbach> so you signed your CoC finally... great. :-p
<ogra> lamont-work, oh i thought it was jane who helped you signing your CoC :)
<seb128> simira: if it crashes don't file a bug, we already have one fo rit
<seb128> for it
<simira> seb128: I know
<lamont-work> dholbach: ogra well, there is that aspect too.
<ogra> heh
<lamont-work> JaneW was nagging me for kiko though
<JaneW> lamont: any excuse will do ;)
<lamont-work> JaneW: and you're good at it.
<lamont-work> and cute while you're nagging too... quite the accomplishment. :0)
<JaneW> heh
<Mithrandir> dholbach: ekiga seems to be missing a dependency on libopal-2.2.0
<dholbach> Mithrandir: I got the bug 15 times now.
<Ubugtu> malone bug 15 in rosetta "PO file import errors should be more verbose" [Wishlist,Fix released]  http://launchpad.net/bugs/15
<dholbach> Mithrandir: I did an upload already which should fix it.
<Mithrandir> haha :-)
<Mithrandir> dholbach: excellent
* Mithrandir ruffles Ubugtu 
<dholbach> malone bug 29195
<Ubugtu> malone bug 29195 in opal "Missing library symlinks." [Normal,In progress]  http://launchpad.net/bugs/29195
<dholbach> that's the one
<dholbach> that's why i asked lamont to give back ekiga
<lamont-work> dholbach: and I'm finally looking at it...
<lamont-work> hrm... ekiga is universe, or main?
<dholbach> main
<dholbach> lamont-work: you're the best.
<dholbach> hey dredg
<dredg> lo
<lamont-work> dholbach: and what you really meant to say was 'please pretend that libopal-dev is available everywhere, kthxbye"
<dholbach> it's not there?
<lamont-work> dholbach: well, dunno -that's why ekiga wasn't building..
<lamont-work> so either it'll build now, or it'll go right back to dep-wait. :-)
<dholbach> it should be there now :)
<lamont-work> but retry it shall.
* dholbach hugs lamont-work
<dredg> dholbach: how goes?
<dholbach> dredg: fine thanks. :-)
<dholbach> dredg: are you still in california?
<dredg> dholbach: no, back in ireland
<lamont-work> dholbach: I try to make my give-back interactions with wanna-build as idiot-savant as possible...
<dholbach> lamont-work: thanks for that. :-)
<lamont-work> the presumption being that y'all expect it to do better this time around :0)
<dredg> dholbach: still laughing at the "omg goole releasing ubuntu-based goobuntu to crush microsoft" stories
<dredg> er, google*
<mjg59> There are people in my office talking about that right now
* dredg sighs
<dredg> i'm convinced that there is a group of people who spend all their time making this stuff up
<dholbach> dredg: so goobuntu isn't going to crush microsoft?
<dredg> not as such, no
<tseng> its pretty unlikely to be made up
<dredg> tseng: there is a goobuntu.
<tseng> there is just a group of people who spend their time exagerating tech industry bits
<tseng> esp. google
<dredg> and that's all i'm allowed say about it. but trust me, google are *not* going to release an operating system
<Keybuk> of course, the rumours about the "HooPbuntu" ...
<dredg> omg someone tell the register
<Menoz> hi all
<BenC> dredg: is it ubuntu with the default home page changed to www.google.com? :)
<Keybuk> and with gnome-lava-lamp in the desktop seed
<dredg> :)
<Keybuk> and gnome-sushi-chef, but only in the US version
<dredg> man i wish we had sushi in the ireland office
<Menoz> do you know a way to say "select always the default option" to the second stage of an installation of ubuntu?
<Menoz> a preseed option?
<Keybuk> Menoz: the debconf documentation is your friend
<Keybuk> hint: priority
<TorbX> Hello
<TorbX> How can I help?
<Menoz> great! thanx!
<jpatrick> http://wiki.ubuntu.com/HelpingUbuntu
<BenC> I've said it before, and I'll say it again...git-bisect is the best tool ever
<BenC> it almost makes me want to look for bugs
<jbailey> BenC: Do we have a similar tool for bzr?
<Keybuk> "bzr-saw" ?
<BenC> jbailey: I mentioned it to them, not sure if it ever got implemented
<BenC> Keybuk: is that an actual tool?
<Keybuk> BenC: not yet
<trulux> ok
<trulux> fix done
<trulux> let's build the packages
<Keybuk> dupload fatal error: Net::FTP: connect: Connection refused at /usr/bin/dupload line 814
<Keybuk> SOYUZ PEOPLE: CAN WE HAVE OUR UPLOAD SERVER BACK, KTHXBYE! :p
<Kamion> tseng: *shrug* as far as I can tell the Register wilfully made up the "coo, are they going to release this then?" from no evidence
<tseng> Kamion: i totally agree that they come to unlikely conclusions
<tseng> from little real data
<dredg> Kamion: i'm reasonably certain that someone in here mentioned something like "new desktop linux distribution called goobuntu" and someone picked up on it
<tseng> haha reminds me of the first distrowatch news on ubuntu
<Kamion> dredg: oh, the existence of goobuntu was real data for them, sure
<tseng> it listed me, jdub, jordi and jono as the developers
<Keybuk> it's been suspected it was mentioned at LCA by somebody
<Keybuk> given the timing
<tseng> none of who really "developed" anything at the time
<tseng> +m
<Kamion> tseng: in fairness, that was a comment rather than the news article itself. :)
<Kamion> (http://distrowatch.com/weekly.php?issue=20040920, comment 14)
<tseng> hmm thats good
<mdz> Kamion: The page you requested is no longer available or it is currently being redesigned. Our apologies for any inconvenience caused.
<Kamion> mdz: WFM
<Keybuk> "Under Construction ... or just missing
<Kamion> (you didn't paste the comma by mistake?)
<mdz> oh, xchat-gnome swallows the comma
<trulux> http://pearls.tuxedo-es.org/patches/ubuntu-all/hplip-udev-fix.patch
<trulux> there we go
<mdz> (which is a perfectly valid character for a URL)
<trulux> bmon: I'll add the url to the malone bug report
<bmon> trulux: cool, thanks
<trulux> bmon: added to bug report
<mjg59> BenC: No git updates for almost 2 days leave me quivering with withdrawl symptoms
<trulux> bmon: works like a charm!
<trulux> bmon: OK, patch works perfectly here
<bmon> trulux: Great! So the next version will have the fix and I will be able to remove the symlink?
<trulux> bmon: ask ubuntu maintainers :)
<bmon> Whoops, I thought you were one :)
<trulux> bmon: hah, I'm waiting for some bounties though :P
<herzi> ogra: ping, https://launchpad.net/distros/ubuntu/+source/gartoon/+bug/30147
<Ubugtu> malone bug 30147 in gartoon "gnome-icon-theme-gartoon has got the wrong GTK_STOCK_GOTO_FIRST icon" [Normal,Unconfirmed]  
<Keybuk> I read that as GOT_FIST
<herzi> Keybuk: that one is missing as well ;)
<BenC> mjg59: lol
<Mithrandir> dholbach: ekiga 1.99.0-0ubuntu3 WFM, but only against ekiga in the other end.  Some other windows program makes it noisy.
<ogra> herzi, no worries its on my list ...
<dholbach> Mithrandir: oh, hm. :/
<dholbach> Mithrandir: I'll talk to pkg-voip people.
<Treenaks> Mithrandir: I filed a bug on that
<Treenaks> (and on another annoying issue, regarding disconnects from the SIP server)
<Mithrandir> dholbach: it also uses an awful amount of time to quit
<dholbach> Yeah, that was a gnomemeeting problem too.
<dholbach> gar!
<jsgotangco> good night
<luisv> grr
<seb128> jordi: around?
<Treenaks> Keybuk: You said network-manager does wpa? (the one in dapper doesn't currently..)
<Keybuk> no, I said it will do
<Keybuk> the one in upstream CVS does
<Treenaks> oh ok
<Treenaks> shit :)
<pitti> Keybuk: speaking of n-m, it should't manage devices which are in /e/n/interfaces
<Treenaks> still no sane/usable WPA support then :)
<Keybuk> pitti: agree
<Keybuk> half the patch is <-- in that window
<Keybuk> or at least it was, gnome-terminal appears to have crashed
<Keybuk> AGAIN
<Keybuk> seb128: a thousand plagues on yourself!
<Keybuk> (once your over this one)
<Kinnison> harsh
<seb128> Keybuk: thank you
<Keybuk> Kinnison: I had a lot of gnome-terminals open
<seb128> Keybuk: did the backtrace has launchpad integration bits, and did you upgrade g-t/restarted it since yesterday?
<Kinnison> is there a way to run g-t in non-factory mode?
<Keybuk> seb128: yeah, upgraded this morning and restarted when it last crashed before lunch
<Keybuk> Kinnison: --disable-factory
<mjg59> pitti: I uploaded a pmount with support for mounting mmc devices
<Kinnison> Keybuk: wouldn't that help?
* Mithrandir hugs dholbach 
<seb128> I blame mvo for g-t
<mjg59> (Since I was getting tired of mounting manually while testing the driver)
<Keybuk> I'll curse mvo when he finishes throwing up then
<Kinnison> Keybuk: it'd certainly reduce the amount of pain each time one terminal dies
<pitti> mjg59: I saw it, thanks; I'll integrate the changes into the upstream bzr tree
<mjg59> pitti: If you could close the bug, that would be great - malone was being nasty to me
<seb128> Keybuk: does the backtrace is still about launchpad integration?
<dholbach> Mithrandir: hm?
<Keybuk> seb128: it didn't give me a core file sadly
<seb128> no bug-buddy neither?
<Mithrandir> dholbach: ekiga.
<Keybuk> seb128: nope
<seb128> bah, bad GNOME
<Keybuk> just "*whoosh*kerplunk*"
<Keybuk> I only switched to the workspace
<dholbach> Mithrandir: ROCK'N'ROLL.
<Mithrandir> dholbach: it seems to work quite nicely, sans the problems mentioned before
<dholbach> :-D
* dholbach dances the Mithrandir-is-happy dance!
<Mithrandir> it always helps to phone home when your head is threatening to explode
<Treenaks> dholbach: now if ekiga would only NOTIFY me of disconnects... :)
<dholbach> Treenaks: PLEASE, file an upstream bug! :-)
<jbailey> Really-tiny-server questions:
<jbailey> Are people likely to want to run mailman on pre-i686 boxers?
<Treenaks> dholbach: I filed a malone bug :) I don't know where the upstream bugtracker is
<jbailey> err.  Boxes.
<dholbach> Treenaks: hrmhrmhrmhrmhrmhrm. :-)
<Treenaks> jbailey: it's python, so as long as python is available... :)
<Keybuk> isn't anything pre-i686 technically a brief?
<jbailey> Keybuk: We're talking "minimal" here.
<Keybuk> ubuntu-server-thong
<jbailey> Keybuk: And if you're running Ubuntu on your thong, I won't NMU for you...
<jbailey> Treenaks: Right.  I'm trying to figure out which componenets would be needed.  I'm guessing Python would be, but if mailman is, then perhaps other python libraries beyond python-base or whatever we call it might be needed as well/.
<pitti> mjg59: yes, of course
<pitti> lamont: ping
<lamont-work> pitti: pong
<ogra> BenC, ping
<BenC> ogra: pong
<ogra> BenC, id mousedev built into the kernel now ?
<ogra> s/id/is
<ogra> (since i cant modprobe it anymore i guess it is)
<pitti> lamont-work: postfix postinst always fails with sth like '...start: postfix already running'
<pitti> lamont-work: do you want to fix that in Debian and we just sync, or shall I fix it for ubuntu?
<lamont-work> grumble/.
<siretart> hi pitti. hi lamont
* pitti waves to siretart 
<lamont-work> pitti: if you happen to have a patch for it, I'd be happy... otherwise I'll work on duplicating it and fixing it for debian tonight
<lamont-work> siretart: hi
<siretart> pitti: I'd like to upload a new pam with this patch: are you d'accord with it? http://librarian.launchpad.net/1546551/pam.debdiff
<lamont-work> pitti: right now I'm working on what I expect will be a love-letter generating NMU to debian
<siretart> this is bug #27515, btw
<Ubugtu> malone bug 27515 in pam libpam0g-dev "security/pam_client.h: Redefinition of internal libc/libstdc++ types breaks unrelated software" [Major,Unconfirmed]  http://launchpad.net/bugs/27515
<ogra> BenC, is mousedev built into the kernel now ? seems i cant modprobe it, so i guess i can drop the hack that adds it to /etc/modules in ltsp, right ? 
<siretart> pitti: according to rleigh, this patch is already in upstream, debian upload also seems somewhat pending. I think it is rather critical.
<pitti> lamont-work: hm, it seems that the prerm didn't stop postfix, and /var/spool/postfix/restart doesn't exist
<lamont-work> pitti: which version of postfix?
<lamont-work> 2.2.8-9 should be current
<pitti> lamont-work:2.2.8-9
<lamont-work> $#W%^&R*T()*^&%*^&)(^_(&^%#^$&%*^(&)
<lamont-work> right then.  on my list for right after my NMU
<pitti> lamont-work: maybe it was just a temporary glitch, no idea
<pitti> if it works for other people, nevermind
<lamont-work> I'll work on reproducing it
<pitti> ok, great
<pitti> siretart: that patch looks just fine
<siretart> pitti: ok. thanks. I'll upload that then in a minute
<pitti> siretart: I had similar breakages in hal (using the __u16 etc. datatypes is eeevil)
<siretart> pitti: I'm playing with new sbuild/schroot. really great crack: sbuild on lvm snapshots and stuff :)
<siretart> and schroot is ftbfs because of this bug
<ogra> BenC, ?
<AlinuxOS> hi pitti ;) I've filed language-pack-ka-base_20051011_all.deb and language-pack-ka_20060126_all.de overvrite problem on malone... but I'm not secure If everything is done in a best way.
<BenC> ogra: yeah, it's built-in
<pitti> AlinuxOS: thanks
<AlinuxOS> pitti, ;)
<ogra> BenC, ah, thanks :) sorry for being pushy but they'll close the room soon and i wanted to commit the change before 
<BenC> no problem
<AlinuxOS> pitti, but I have another strange problem with Dappers gnome-menus: http://alinuxos.no-ip.org/menus.png
<AlinuxOS> the georgian translation dosen't appear at all.
<seb128> seems that the .directory translations stuff doesn't do his job
<pitti> AlinuxOS: what does 'grep Gettext /usr/share/desktop-directories/Accessibility.directory' print for you?
<AlinuxOS> pitti, where do you a output in private or pastebin?
<pitti> AlinuxOS: hm, it seems to work for the panel menu entries (Applications etc.)
<AlinuxOS> grep Gettext /usr/share/desktop-directories/Accessibility.directory
<AlinuxOS> X-Ubuntu-Gettext-Domain=gnome-menus
<AlinuxOS> I'm on breezy now, maybe I must reboot into Dapper ? (that output I made into Dapper's chroot)
<AlinuxOS> pitti, some things also are translated strange... maybe it's .po file issue...that they are a little bit changed from breezy to dapper?
<AlinuxOS> pitti, example I've translate "language selector" .po file but on gnome-menus it still appear in english.
<pitti> AlinuxOS: hm, works fine for me
<pitti> AlinuxOS: are you sure that the ka .mo file of gnome-menus is correct?
<pitti> AlinuxOS: I can change de/LC_MESSAGES/gnome-menus.mo, killall gnome-panel, and it works
<AlinuxOS> /usr/share/locale-langpack/it/LC_MESSAGES/gnome-menus.mo
<AlinuxOS> /usr/share/locale-langpack/en_GB/LC_MESSAGES/gnome-menus.mo
<AlinuxOS> /usr/share/locale-langpack/en_CA/LC_MESSAGES/gnome-menus.mo
<AlinuxOS> /usr/share/locale-langpack/ru/LC_MESSAGES/gnome-menus.mo
<AlinuxOS> /usr/share/locale-langpack/ka/LC_MESSAGES/gnome-menus.mo
<AlinuxOS> it's in a right place....
<pitti> yes, but does it have correct translations?
<pitti> AlinuxOS: msgunfmt /usr/share/locale-langpack/ka/LC_MESSAGES/gnome-menus.mo |less
<AlinuxOS> pitti, moment
<AlinuxOS> msgid "_Applications:"
<AlinuxOS> msgstr "_<9E><9D><90>:"
<AlinuxOS> mmm
<AlinuxOS> I see this strange things in terminal..
<pitti> AlinuxOS: not that one, try 'Accessibility' for example
<pitti> AlinuxOS: hm, maybe it states the wrong encoding?
<AlinuxOS> but fonts are installed in the right way
<pitti> anyway, folks here cry for dinner
<AlinuxOS> but when I open .po file in gtranslator everethyng works great..
<AlinuxOS> pitti, moment...I'll  reboot... and retry
<lucas> MOTU meeting now on #ubuntu-meeting
* rob^^^ goes to lurk
<thisisadeal> these absolutely have to go today.  2 alienware area51-m 5700 laptops $550 each includes shipping, case, wireless router and 1 alienware area51 7500 desktop $700 includes monitor, keyboard, mouse,. speakers.  message me if you wnat to buy any of these items at mcsltd@telusmail.net, aim at ogd443 or yahoo at mcsltd2 thanks and have a good day.
<zyga> ....
<zyga> spam on #u-devel?
<dieman> arugh.
<dieman> i didn't notice hoary's amd64-xeon kernel has DUMMY_IOMMU
<dieman> ok
<dieman> at least dapper isn't that way
<mgalvin> is there a reason why the about thunderbird dialog has no image or is it broken?  http://www.simplifiedcomplexity.com/images/screenshots/dapper/flight4/thunderbird-bad.png
<dieman> mgalvin: trademarks, is my guess
<zyga> mgalvin: It might be related to the fact that those icons are copyrighted trademakrs
<zyga> exactly
<zyga> mgalvin: ubuntu cannot ship those images
<mgalvin> true, but the firefox has an image there (not the trademarked one)
<mgalvin> *something* should be there :-/
<mgalvin> meh, not a big deal, i just noticed it
<zyga> mgalvin: yeah, an ubuntu on a mail envelope logo would be nice
<mgalvin> zyga: thats a good idea, that would be nice
<zyga> mgalvin: go for it, pick up the icon from tango project add the ubuntu logo and ping me
<zyga> mgalvin: high res please :-)
<mgalvin> :), i'm looking for the images now
<zyga> mgalvin: tango-project
<zyga> mgalvin: art.ubuntu.com might help but I doubt you'll find a hi-res logo with transparency
<mgalvin> zyga: yup i know, i got it
<zyga> mgalvin: there is one at the wiki
<Leoric> Which standard should a package maintainer follow to create application menu icons in Ubuntu?
<sladen> zyga/mgalvin: would it be avoid having Ubuntu specific branding on the images.  It makes life easier for derivers
<zyga> sladen: no
<sivang> zyga: what is that logo going to be used for ? :)
<zyga> sladen: make an API for that :)
<zyga> sivang: right now there is NO logo for thunderbird
<mgalvin> sivang thunderbird/about thunderbir
<sivang> ah, logos are important
<mgalvin> i have two make so far, almost done with a third, will post links in a few min
<zyga> k, thanks :)
<sladen> zyga: is it a trademark or a copyright issue?
<zyga> sladen: the former
<zyga> sladen: check the moz website, there is a detailed explanation
<sladen> zyga: it was a rhetorical question :)
<zyga> sladen: but generally it's exactly the same thing as with redhat's icon
<zyga> didn't seem like one
<sladen> I'm too subtle :)
<mgalvin> zyga: http://www.simplifiedcomplexity.com/artwork/thunderbird1.svg, http://www.simplifiedcomplexity.com/artwork/thunderbird2.svg, http://www.simplifiedcomplexity.com/artwork/thunderbird3.svg
* mgalvin reminds zyga he is *NOT* an artist
<mgalvin> but these might not suck *too* bad
<neuralis> mgalvin: they're very nice.
<zyga> mgalvin: looking
<mgalvin> neuralis: thanks :)
<zyga> hmm
<zyga> is it just me or does firefox just display a small fraction of those images
<mgalvin> open them in inkscape
<zyga> k
<zyga> actually nautilus does too ...
<mgalvin> i rush a bit b/c i gotta run... the page size is small
<mgalvin> so ff/naut is not showing it b/c the image is to big for the page
<mgalvin> inkspace will display them properly
<zyga> I see them
<zyga> very nice
<zyga> I'll talk to proper people to get them promoted :)
<zyga> mgalvin: could you send me some info about yourself?
<zyga> and license the images approprietly
<zyga> s/asfdgdgfd/correctly/ :-)
<mgalvin> zyga: cool, thanks, Matt Galvin, i write those DapperFlight overviews, on the doc team, blah blah...
<mgalvin> anyhow i gotta run, should be back on irc i around 30 min or so, ttyl
<zyga> mgalvin: thanks, bye
<hunger> Hmmm... konqui displays those svg images properly if they are rescaled to fit into the page frame in inkscape.
<zyga> hunger: ack, they are larger than declard canvass
<sivang> night all
#ubuntu-devel 2006-02-07
<zyga> night guys
<jsgotangco> what the heck, sabdfl cut his hair
<ajmitch> yes
<ajmitch> he almost looks respectable now
<jsgotangco> he's speaking at the moment
<jsgotangco> yeah
<jsgotangco> he's in a suit now
<ajmitch> scary
<ajmitch> I'm glad LCA is far more casual
<jsgotangco> well i am in a jacket too :/
<jsgotangco> he's more corporate Canonical now that Ubuntu at the moment heh
<nekohayo> I see gst-plugins 0.10 base, good and ugly, but not "bad". Is it planned to include them in repositories?
<tseng> no
<tseng> they are bad
<nekohayo> so users will have to compile from source I presume?
<tseng> ugly means the license is ugly
<tseng> bad means its broken in some way
<nekohayo> ah I see
<nekohayo> about 1 out of 5 testing video files I carry can be played back, so I was wondering if that was the cause
<tseng> mm we still dont have good support for new wmv and mov stuff
<tseng> in gstreamer
<nekohayo> tseng: out of curiosity, is there a page listing what formats work and what not?
<tseng> hm there was one a long long time ago
<BenC> is totem supposed to play dvd's?
<BenC> I can't seem to get it to cooperate, even after installing libdvdcss2
<tseng> BenC: with totem-xine and libdvdcss2
<tseng> gstreamer will not
<jsgotangco> hey tseng 
<nekohayo> I mean I "could" use and recommend using totem-xine for dapper drake final, but it would be kind of a shame...
<tseng> hi jsgotangco 
<tseng> nekohayo: your google is as good as mine
<jsgotangco> dude sabdfl looks like a rep from redhat :/
<tseng> jsgotangco: wheres this
<BenC> tseng: thanks
<jsgotangco> tseng: he's in Manila at the moment...in front of me...speaking to some companies...
<tseng> jsgotangco: hm oh
<BenC> "Totem was not able to play the DVD"  "No reason"
<BenC> correct, yet non-informative
<tseng> I blame seb
<BenC> tseng: any additional items besides libxine-extracodecs I need to install?
<tseng> BenC: oh yeah
<tseng> BenC: someone neutered xine
<tseng> im not sure :/
<tseng> previously libxine1 was the whole shebang
<ajmitch> tseng: possibly slomo_ 
<irvin> umm... why are we shipping totem-gstreamer and not totem-xine by default?
<tseng> umm.. because gstreamer is not patent encumbered and totally modular by design
<tseng> xine had to be hacked to pieces to achieve similar
<tseng> also the rest of gnome uses gstreamer
<jsgotangco> yeah
<BenC> any chance of there being a gstream0.10-dvd anytime soon?
<Amaranth> BenC: If someone ports the 0.8 one :)
<wasabi> .10 isn't really suitable to release without dvd support, imo. =/
<BenC> well, atleast the latest rhythmbox plays itunes shares again
* earobinson is away: I'm currently away, please leave a message
* earobinson is back (gone 00:00:12)
<floam> gnibbles in the current gnome-games packages is fscked (just try to play a game)
<calc> anyone happen to know why a lot of stuff in dapper still depends on xlibs which hasn't been in the archive for a long time now?
<Tm_T> xlibs - X Window System client library transitional package
<Tm_T> humm
<Tm_T> in dapper
<calc> shows as local on my system and has for at least several weeks
<calc>  *** Opt libs     xlibs        6.8.2-77    <none>
<Tm_T> humm
<calc> i'm using archive.ubuntu.com, so its either not there or that server is broken and has been for a while now
<calc> supposedly you can remove xlibs according to the desc after upgrading to breezy
<calc> but if i try to remove it a lot of stuff becomes uninstallable
<calc> well not a lot about 5 things
<calc> lsb-graphics, python2.4-opengl, lsb, python-opengl
<Tm_T>   Candidate: 6.8.2-77
<calc> thats just what is already on my system
<calc> apt-cache showpkg xlibs shows lots of dependencies
<Tm_T> aye
<Tm_T> should be fixed
<Tm_T> file a bug?
<calc> i don't remember my password, and i am about to go to bed, just was wondering if anyone else noticed it yet
<calc> i'll file a bug when i get home tomorrow if its not already there
* calc dislikes the login req for filing bugs :\
<calc> but i also dislike the amount of spam email i get from debian bts since its public too ;)
<Tm_T> haha
<lamont> opal_2.1.2-0ubuntu3  needs the wonderful "use gcc-3.4 on hppa/mips/mipsel" love, or whichever the other 2 architectures were.
<ba> word up! are there less noobs in here then in #ubuntu, i sure hope so
<Tm_T> err?
<Tm_T> ba: what exactly you're trying to say?
<ba> Tm_T: im just saying people in #ubuntu drive me up the wall. 
<Tm_T> support channel, what you expect
<lamont> ba: and #ubuntu-devel is for discussing ongoing development... completely different charter/scope
<Tm_T> aye
<ba> mmmm maybe i should start using the devel then
<lamont> ba: what code are you working on, then?
* Tm_T needs sponsor and timemachine so he can do all artwork he's going to do
<lamont> ba: this isn't the channel for getting help with the current devel snapshot... it's for discussing your proposed fix to whatever problem you have hit...
<ba> non currently. im just getting back into linux after not being so active for awhile
<lamont> cool
<ba> just crossed over from mandriva about 6 months ago
<Tm_T> stop swearing
<ba> http://ubuntuforums.org/gallery/files/6/9/4/1/4/likesleepingonacloudubuntu_original.png
<ba> :D i got this in my mail today
* lamont wanders off to consider creating a w-b instance for his home-local packages
<ba> whats the package you can get for using windows drivers for windows hardware in ubuntu
<ba> like wifi stuff?
<mjg59> ba: This isn't a support channel
<Tm_T> ba: wiki.ubuntu.com
<ba> ya i found it
<ba> http://www.zerohex.org/2005/11/27/wifi-on-ubuntu-510-the-breezy-badger/
<HiddenWolf> ba: please continue in #ubuntu, this channel is for development
<triceratops> what is needed to recommend / wish a new program for dapper+1? Register a new product in launchpad?
<siretart> triceratops: either add it to https://wiki.ubuntu.com/UniverseCandidates or file a ticket in launchpad
<siretart> 
<siretart> [Z
<triceratops> siretart: https://launchpad.net/distros/ubuntu/+tickets ? I thought it is for 'alert the Ubuntu support community'..
<pappan> hi Simira
<Simira> mrn
<Simira> *yawns*
<Simira> everyone in London ok today?
<pappan> what happened in london today ?
<mdke> Simira, they're not here 
<Simira> mdke: what do you mean?
<Simira> they're not awake yet?
<mdke> they're not in the channel
<Simira> right
<sivang> Simira: I heared many folks got ill
<Treenaks> Something about a death plague?
<Simira> yes, Mithrandir at least was better last night. It's a maximum two-days thing, I think.
<Treenaks> They _have_ been handling a dapper drake
<sivang> Treenaks: so?
<Treenaks> sivang: handling poultry can give you scary diseases in some countries today
<sivang> Treenaks: after loooking in dict, "hehe" :)
<sivang> so, google are developing a goobuntu according to RegDeveloper :)
* sivang sometimes doesn't know whom to belive anymore
<sivang> all thos sites, each one saying something else :)
<Treenaks> sivang: The Reg is blowing it out of proportion
<Treenaks> sivang: What I've heard is that some Google people run Ubuntu + modifications on their workstations, and call THAT goobuntu
<sivang> Treenaks: that were my previous rumors, so that's ok :)
<Simira> fabbione :) How are you?
<HiddenWolf> Treenaks: there is no such thing as bad publicity.
<fabbione> morning
<fabbione> hey Simira 
<fabbione> Simira: not too bad
<Simira> fabbione: now you guys take it easy today! Don't get back to being sick!
<fabbione> Simira: i wasn't really sick like the others
<fabbione> i didn't get fever
<Treenaks> .. yet
<sivang> fabbione is a pilot, he can't get sick :)
<dholbach> good morning
<mantiena-baltix> Hi all
<spacey> my colleague is not human, and even he gets sick :p
<Treenaks> spacey: what is he then?
<spacey> i will leave that to your imagination :)
<Treenaks> spacey: he's your pet tentacle monster.
<spacey> :p
<Simira> enrico :)
<enrico> Simira: hi!
<sivang> hey enrico !
<enrico> sivang: :)
<slomo> ajmitch: yes, it was me ;)
<ajmitch> slomo: good to know who to blame :)
<seb128> hi slomo ajmitch
<slomo> hi seb128 :) you pinged me yesterday?
<seb128> yeah, it was about avahi stuff but we figured
<seb128> seems you need to restart avahi-daemon after setting your internet to get it working :/
<ajmitch> hello seb128 
<Lathiat> 'setting your internet' ?
<seb128> so if you use nm avahi just doesn't work
<ajmitch> unlikely
<Lathiat> hrm, avahi works fine in combination with n-m here, i have howeer seen bugs in the past
<Treenaks> ajmitch: it's true for me
<Lathiat> and one from a guy not so long ago
* ajmitch saw a live demo of nm & avahi together at LCA :)
<seb128> Lathiat: that was a random guess, I need to avahi-daemon to get it working
<Lathiat> seb128: can you avahi-daemon -k and then avahi-daemon --debug and get NM to go and send me the output
<seb128> and that's the same for dholbach and mdz
<ajmitch> Treenaks: I even got to meet an avahi author
<Lathiat> or whoever has that problem
<seb128> ok, will do, thank you
<Lathiat> ->lathiat@bur.st
<Lathiat> cheers
<Treenaks> ajmitch: You meeting an avahi author doesn't make it less likely that the combination of network-manager + avahi works for me, because they don't :)
<ajmitch> Treenaks: haha, yeah
<ajmitch> I haven't started using NM yet
<ajmitch> not until I know it works nicely with WPA
<spacey> software is always more reliable if you know the author :p
* Lathiat grins
<Treenaks> spacey: oh THAT's why your code is so broken :P
<spacey> come on, my code does not even run
<ajmitch> seb128: how does avahi fail? do services just not show up?
<seb128> avahi-discover/browse were not listing the machines until avahi-daemon is restarted
<Lathiat> i know we've definately got a bug somewhere because i hit it randomly
<Lathiat> but nothign reliably reproducable yet
<Lathiat> just sometimes it stops picking things on an interface up
<jordi> tseng: wow
<jordi> tseng: I didn't know this
<jordi> tseng: funny. At least distrowatch knew at the time that seb128 sucks quite a bit
<seb128> jordi: what?
<ajmitch> heh
<Keybuk> argh!  "Bugs I'm Subscribed To" includes all the debzilla bugs that have been closed in Ubuntu
* Keybuk mass-unsubscribes
<app> This is a wrong place to ask, but do you know any IRC channels for Windows developers?
* Lathiat laughs
<HiddenWolf> app: try google
<app> I tried. Google is not the best way to find which IRC channels exist, and are worth using.
<JaneW> Lathiat / sivang : ping - Dapper Sataus meeting in ubunut-meeting if you'd like to join us...
<Keybuk> heh, "ubunut"
<JaneW> argh
* ajmitch wonders if it's worth talking about his single dapper goal in the meeting :)
<jordi> seb128: http://distrowatch.com/weekly.php?issue=20040920 ; search Jordi
<jordi> note the date of the article
* seb128 slaps jordi
<jordi> lala
<seb128> jordi: you were replying to some comment about a new article or something?
<Kamion> ajmitch: don't see why not, if there's been interesting progress
<jordi> seb128: yeah, last night tseng mentioned it
<seb128> jordi: URL?
<jordi> I didn't know that article
<jordi> dude I just posted you a link
<jordi> 11:05 < jordi> seb128: http://distrowatch.com/weekly.php?issue=20040920 ; search Jordi
<seb128> oh, ok
<seb128> I though there was a new one after that one
<seb128> you "creme-de-la-creme", what a joke :)
<jordi> no this was on IRC
<jordi> seb128: shuddup
<seb128> jordi: BTW what did you run previous time for evolution intltool issue
<seb128> a localize-update or something
<seb128> I've it on my IRC logs at home but dholbach has the same issue now
<jordi> intltoolise
<seb128> thanks
<dholbach> rocknroll
* dholbach tries
<jordi> they are using a broken one
* jordi watches seb128 and dholbach resort to the creme-de-la-creme
<seb128> bah
* jordi goes away singing.
<seb128> when do you fix gnome-python?
<seb128> you slacker!
<MrFaber> hi all
<MrFaber> Is it possible to support MIcrosft Natural Ergonmic Keyboard 4000 in Dapper?
<MrFaber> A patch seems to be posted in a kernel mailing list
<MrFaber> http://seclists.org/lists/linux-kernel/2006/Jan/0896.html
<Tm_T> kernel... what's in that keyboard that it need kernel patch?
<MrFaber> many keys who are unknown
<MrFaber> And btw it doesn't work if it is plugged in on start at least in Breezy
<MrFaber> I have to unplug and plug it again
<mjg59> MrFaber: Should be - I'm not sure why it wouldn't be happy with the standard driver, though
<MrFaber> I am not sure but this problem doesn't happens with Dapper Live-CD
<mjg59> (Which ought to handle extra keys)
<MrFaber> but I am going to test it
<MrFaber> mjg59: Homepage, Searching, E-Mail, AUdio and calculator keys work
<MrFaber> all others not
<MrFaber> and back and forward :)
<Diziet> I found some bug recently where there's a 128-entry table which gets indexed by the kernel from another table.  The other table starts with some values >=128.
<MrFaber> dmesg doesn't show any unknown key output and xev doesn't react with the other keys
<Diziet> You can't _add_ values >=128 but the defaults are demonically nasal.
<MrFaber> I have another point. I have Vaio Laptop VGN-S5 which works fine under LInux except some little points.
<MrFaber> My pc can't restart under Breezy
<MrFaber> But it works with the 2.6.15 Kernels but somehow not with the latest Dapper FLight (3)
<MrFaber> How can that be?
<dholbach> It's safer to take this to a mailing list or a bug report.
<dholbach> Information on IRC usually gets lost.
<dholbach> And the 'right people' to answer are not there either.
<Mithrandir> pitti: my clock applet still seems happy after an upgrade.
<pitti> Mithrandir: thanks for testing, then I can close that one, too
<MrFaber> thanks dholbach 
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | No uploads on Friday (Soyuz Rollout)
<Lathiat> any installer people about?
<Lathiat> is it a known bug that when downloadin gfiles in the flight cd3 installer, it always says "0s remaining" ?
<Mithrandir> Lathiat: aptitude bug
<Lathiat>  ok
<Lathiat> Who's handling X bugs now?
<Lathiat> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/28648 is a fairly serious regression that needs looking at 
<Ubugtu> malone bug 28648 in xserver-xorg-input-synaptics "Slow movement regression of synaptics touchpad on v0.14.3+seriouslythistime" [Normal,Confirmed]  
<Kamion> Lathiat: 0s remaining> known and reported, even
<Lathiat> Kamion: cool, cheers
<jsgotangco> i confirm this on my tosh M2
<fabbione> hmmm good to know
<Hobbsee> yet another one...
<fabbione> Lathiat: X bugs -> ubuntu-x-swat
<Lathiat> ok to reassign it?
<fabbione> Lathiat: if you want to reassign all X bugs to ubuntu-x-swat that would be nice
<fabbione> it will spare me the time to do it 
<thesaltydog> seb128, is there any further issue of Ubuntu Desktop News, following the one of Dec 15th?
<fabbione> who is familiar with procmail?
<seb128> thesaltydog: vuntz is working on one
<pitti> fabbione: I use it (not familiar with the code, though)
<thesaltydog> seb128, ok. Thanks.
<seb128> np
<fabbione> Lathiat: do you really mean that there are only 2 X bugs in malone?
<fabbione> Lathiat: or are you going to reassign all of them?
* Lathiat laughs
<Simira> is mvo still sick?
<Mithrandir> Simira: I don't think so, he's sitting just here
<mvo> Simira: no, I'm mostly well again
<mvo> (not up to 100% yet, but feeling a lot better)
<Simira> mvo: oh, there you are. My brain mentally censored your nick.
<Simira> mvo: my update icon is gone on the latest update on Dapper on my laptop
<mvo> Simira: it's not runing anymore at all? not availabe in gnome-system-monitor etc?
<Simira> mvo: no, it's not running. I can do some more checking on it when I get home, just wanted to notice you.
<mvo> Simira: thanks, it would be interessting if it has left something in .xsession-errors
<seb128> maybe it's just hanging and eating CPU
<seb128> it likes to do that on my box
* mvo kicks seb128 
<Mithrandir> mmm, crunchy cpu.
<HrdwrBoB> at least you don't have an aacraid card .. I have two and it looks like the driver is flaky
<koke> pitti: I'm not sure, but there may be some problems with postrgresql and the latest langpacks in breezy
<pitti> koke: any details?
<koke> pitti: ops, I think it's not the langpacks
<pitti> well, langpacks have translations for postgresql
<koke> but I'm getting the Error: Could not parse locale out of pg_controldata output
<pitti> (or, should have)
<koke> I was trying to 'clone' a server, so I've installed the same packages, copied /etc and /var/lib/postgresql
<koke> the pg versions are the same
<pitti> koke: do you have the locale available?
<koke> the only difference I've found is the version of the langpacks
<pitti> koke: i. e. the locale that the database has needs to be available on the server
<koke> I've tried locale-gen if you meant that
<pitti> koke: please open a bug (in Debian, preferably) and give me the output of sudo /usr/lib/postgresql/8.0/bin/pg_controldata /var/lib/postgresql/8.0/main/
<pitti> koke: (or 7.4, or whatever version you use)
<pitti> koke: bug against postgresql-common
<pitti> koke: please also check that 'locale -a' shows the locale that postgresql wants
<koke> LC_COLLATE:                           @
<koke> LC_CTYPE:
<koke> :?
<pitti> ouch
<pitti> LC_COLLATE:                              de_DE.UTF-8
<pitti> LC_CTYPE:                                de_DE.UTF-8
<pitti> should look like this
<koke> yep, I have es_ES.utf-8 in the original server
<pitti> and in the new one?
<koke> nothing (pasted above)
<koke> ouch! hint: copied from amd64 to x86 :)
<torkel> seb128: ping
* jsgotangco stops his me too comments on LP
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | No uploads on Friday 1800-2359UTC (Soyuz Rollout)
<seb128> torkel: pong
<torkel> seb128: should evolution really recommend mozilla-psm, now when it is built against firefox?
<seb128> torkel: probably not
<torkel> seb128: want me to file a bug?
<seb128> torkel: yes please
<mantiena-baltix> mvo, hi, some time ago you told me, that you wanna know if my gdebi and gksu backports to breezy work
<mantiena-baltix> mvo, so, they works fine (I've tested on more than 20 different computers in various situations), I've put them to ftp.akl.lt/Linux/Baltix/Baltix-Ubuntu_packages :)
<ritvik> has any one tried installing "VMWare Work Station" on Ubuntu? is it supported?
<Treenaks> ritvik: by canonical? no.
<ritvik> Treenaks, okay. but does it work ?
<zul> vmware workstation 4 with the modification yes...vmware 5 with the modification to the kernel headers yes..
<ritvik> zul, is there any howto available :-) 
<luis_> just use vmware-config.pl
<zul> ritvik: check the wiki
<luis_> it'll say 'you need gcc', etc.
<luis_> it Just Works, assuming you're able to use apt-get ;)
<ritvik> cool i'll try that thanks 
<luis_> (surely if you're at vmware.com, you can ask your own engineering staff about this?)
<ritvik> well new joinee :-).. lets see i'll try to figure out. just installed ubuntu on my machine going to install vmware workstation
<luis_> I'm just saying
<luis_> you could, you know, also ask google :)
<luis_> http://www.google.com/search?q=ubuntu+vmware+workstation+5
<AlinuxOS> pitti, hello ... can you help me please...
<AlinuxOS> I need help bro...
<azeem> AlinuxOS: please ask in #ubuntu
<AlinuxOS> azeem, it's devel question...
<azeem> ah, ok then
<azeem> I overlooked the "pitti"
<AlinuxOS> azeem, no probs bro.
<mvo> mantiena-baltix: thanks!
<pitti> AlinuxOS: hi, just returned from lunch
<AlinuxOS> pitti, buon lunch :)
<AlinuxOS> alles ok?
<pitti> heh, I'm fine :)
<pitti> lifeless: still here?
<Mithrandir> Keybuk: what's the reason for udevinfo not outputting information like the UUID of a file system?  Missing /lib/udev/vol_id ?
<Mithrandir> s/'s/ could be/
* fabbione starts to yell at X again
<fabbione> DIE DIE DIE DIE YOU BASTARD
<mdz> fabbione: suse 10.1 apparently ships with apache 2.2.0; maybe they have patches for the external modules?
<Treenaks> fabbione: isn't daniels there to shout at?
<fabbione> mdz: if they do, they didn't publish anything towards upstream
<fabbione> Treenaks: not anymore
<Treenaks> fabbione: hm.. because I want my xserver-xorg-driver-ati fixage! ;)
<fabbione> Treenaks: do you have a patch for it?
<HiddenWolf> I thought daniels stopped maintaining X?
<fabbione> also.. is there a bug in malone?
<Treenaks> fabbione: he said he had a fixed version, but I haven't seen an upload since he said that
<Treenaks> fabbione: and yes
<Treenaks> fabbione: let me find it for you
<Treenaks> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-ati/+bug/20283
<Ubugtu> malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Normal,Unconfirmed]  
<fabbione> Treenaks: i will try to look at it
<fabbione> please reassing all the X bugs you have to ubuntu-x-swat
<Treenaks> fabbione: OK
<mdz> fabbione: you should set the team to be a bug contact on all of the relevant packages
<mdz> fabbione: if you like, you can make a list of the packages and a launchpad developer can change them en masse
<Treenaks> fabbione: (and done)
<fabbione> mdz: ok i don't know how to do that yet.
<fabbione> Treenaks: thanks
<mdz> fabbione: go to the source package page, e.g. https://launchpad.net/distros/ubuntu/+source/xorg
<Simira> mvo: any other info you needed about the update-thing? I can't find it here... (at home now)
<fabbione> mdz: i can prepare a list, htat'si can
<mdz> fabbione: click "bugmail settings"
<fabbione> that's something i can
<mdz> or make the list and send to me
<fabbione> ok
<mvo> Simira: if there is nothing interessting in ~/.xsession-errors, then I'm afraid not
<Simira> mvo: does "** (gedit:6899): CRITICAL **: gedit_plugin_update_ui: assertion `GEDIT_IS_PLUGIN (plugin)'  failed
<Simira> help?
<sladen> Kamion: on the gfxboot menu, would it be better to swap the blue and white over for the central menu.  White is much brighter and I think would make better sense for the 'highlighted' item.  It would also match the F-key list at the bottom 
<MisterN> hi
<mdz> Treenaks: daniels is here now if you want to nag him via fabbione
<Treenaks> fabbione: Can you ask daniels about the bug 20283 fix he made (and was going to send me)?
<Ubugtu> malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Normal,Unconfirmed]  http://launchpad.net/bugs/20283
<fabbione> MEEEEHHHHHHH
<fabbione> Treenaks: possibly
<jono> hi all
<jono> does dapper include a Report Bug option on the Help menu in applications?
<Treenaks> I think so
<dholbach> No, we dont.
<jono> is this planned?
<seb128> it has a "Get Online Help" item
<seb128> which is quite that
<dholbach> it is support and translation at the moment
<jono> ahhh thats ok
<jono> I can click Get Online Help and then click bugs
<jono> good work chaps :)
<mdz> Kamion: could you update your copy of the published seeds so I can push ubuntu-meta?
<mdz> one of these days we will fix it to pull straight from bzr
<Kamion> mdz: update done
<Kamion> you may have fun with the "transparent" proxy here
<Kamion> I've had issues with it being a little too opaque while doing bzr get
<mdz> Kamion: I do builds on a remote box with a smarter proxy
<Kamion> ah
<Keybuk> jono!
<jono> Keybuk, heya pal :)
<jono> Keybuk, hows it going? you in london ?
<Keybuk> yeah, at the distro sprint of death
<jsgotangco> lol
<jsgotangco> Kamion, i got to meet Hande at last :)
<jono> Keybuk, did you catch the horiffic affliction ?
<Kamion> jsgotangco: cool
<Kamion> jono: Keybuk is one of the few survivors
<jono> Kamion, ugh, I assume you were hit by it
<Keybuk> I survived :)
<Kamion> jono: yeah
<Kamion> TWICE
* Amaranth is lost
<Amaranth> someone should write this COBOL crap for me so i can work on alacarte ;)
<Kamion> Amaranth: there's at least one nasty illness going around at the distro team sprint that's put about three-quarters of us out of action at one point or another this week
<Amaranth> ick
<jsgotangco> and whiprush blames sladen
<jsgotangco> heh
<jsgotangco> (Again)
<jono> Kamion, you poor bugger - should I send  up a basket of fruit ?
<jono> :P
<sladen> jsgotangco: and I haven't even turned up yet ...
<Kamion> we have a surfeit of fruit here :)
<jono> Kamion, :)
<jono> right I am off
<jono> later all
<Amaranth> bye
<fabbione> mdz: SUSE doesn't have all the modules we need for main. I didn't bother to check universe
<fabbione> mdz: they only have a minimal subset for apache2.2
<fabbione> mdz: and that's not surprising
<mdz> fabbione: ah, I see.  thanks for checking into it
<fabbione> mdz: no problem
<fabbione> mdz: do you have time now?
<jsgotangco> goodnight
<Keybuk> pitti: did n-m build for you again?
<Keybuk> ok, figured out why it doesn't build and how to make it build again
<doko> mdz, Kamion: please promote tix (source), tix-dev, tix to main, packages renamed from tix8.1 / tix8.1-dev.
<Simira> have Mithrandir gone sick again?
<mdz> Simira: no, he's standing about 4m away
<Simira> mdz: oh, doing offline, rl-things? Shame on him!
<Treenaks> (people do offline things?! *world ends*)
<Kamion> doko: looking
<pef> hello
<pitti> true, no tix8.1 in dapper any more
<pitti> Kamion, doko: but isn't that only requried to build python2.3?
<pitti> it propbably depends on how long python2.3 will stay in main
<Kamion> I'll promote it for now so that python2.3 can build; it can always be demoted back later
<Kamion> (done)
<doko> thanks, yes, should be demoted together with python2.3
<Kamion> (the newest version of python2.3 has not built, presumably due to this)
<pitti> Kamion: exactly
<pitti> true, anastacia should remind us 
<ritvik> zul, wrt VMWare no need to  modify the kernel headers just a simple "sudo ./vmware-install.pl" works just fine
<Keybuk> BenC: when was #22220 fixed?  It's not fixed in my installed kernel here
<Keybuk> bug 22220 that is :p
<Ubugtu> malone bug 22220 in grub "Ubuntu 5.10 Preview (Breezy Badger) Panics w/ I2O based raid" [Major,Unconfirmed]  http://launchpad.net/bugs/22220
<Keybuk> hmm, that description is wrong anyway
<BenC> Keybuk: It's a dup, and I'm sure it was fixed (had a tester)
<Keybuk> no it's not fixed
<Keybuk> read my comments
<BenC> the crash is fixed
<Keybuk> yeah, but there's still a kernel bug there
<BenC> let me read it again
<Keybuk> there's nothing that specifies that i2o_block needs to be loaded
<Keybuk> ie. no MODALIAS or module depend
<Keybuk> (or, afaik, nothing even in sysfs to specify that the i2o device is a block device)
<BenC> i2o_block and dpt_i2o provide similar functionality
<BenC> one works on some hw, one works better on others
<Keybuk> right, but the kernel can't just say "load whichever you want after magically deciding"
<Keybuk> it still needs MODALIAS love
<Keybuk> it doesn't even say to load both
<Keybuk> ie.
<BenC> that's because they would both be loaded, and it would all depend on the order of load anyway
<Keybuk> so?  we use blacklists to solve that for other subsystems
<Keybuk> i2o doesn't get to be different :)
<Keybuk> it still needs driver-core'ing
<BenC> but then you'd still have to unblacklist one to use the other :)
<BenC> either way, it's going to require people to modify udev files
<Keybuk> no
<Keybuk> that's not what the bug is for
<Keybuk> i2o is a subsystem that hasn't been driver-core'd
<Keybuk> when an i2o device is inserted, an event is generated that contains *no* information about the device
<Keybuk> and provides no link between the device and the available modules to support that device
<Keybuk> (ie. it contains no $MODALIAS)
<Keybuk> that's why the bug is on the kernel
<Keybuk> it's upstream, and something gregkh will probably fix when he gets round to it, but it's still a bug
<BenC> dpt_i2o has a PCI device table
<Keybuk> right, but i2o_block doesn't
<Keybuk> (I'd assume it'd have an i2o device table)
<BenC> and i2o_block is an i2o driver (don't think it's something that can be detected)
<BenC> the only table for i2o is the PCI device table
<Keybuk> right
<Keybuk> that needs to be fixed then
<Keybuk> having modules that have to be loaded after some magical insight are bad, m'kay
<BenC> so i2o should get loaded, but things like i2o_block can't be auto loaded
<Keybuk> "everything works if you load this module, but we're not going to hint or document that" => bad
<BenC> but it's not a case of "it's possible, it just isn't done", it's just not possible
<Keybuk> i2o_block can be autoloaded when an i2o block device is inserted
<Keybuk> why isn't it possible?
<Keybuk> does the i2o bus protocol not provide any information about connected devices?
<Treenaks> Keybuk: I've heard claims that I2O is very braindead in that area
<Keybuk> Treenaks: that's ISA braindead though
<Treenaks> Keybuk: You've seen the ISAPNP device number mess
<Treenaks> with multiple devices claiming the same number, etc.
<Keybuk> Treenaks: even an ISAPNP mess would be sufficient to know whether or not to load the right module
<Keybuk> but going "oh you didn't load this secret module" is not a solution :)
<Treenaks> Keybuk: good point
<Keybuk> otherwise how do we know which of i2o_block, i2o_proc and i2o_scsi we need to load for the device inserted?
<Keybuk> the bus must know for those to work and bind to the right device :)
<BenC> seems that i2o has a class table, defined by i2o specs
<BenC> well the drivers could bind using some magically detection that the bus was dumb about :)
<BenC> but in this case, it seems that there is a class of devices
<BenC> and each i2o class driver has an i2o struct class definition for probe callbacks
<BenC> so it is possible
<BenC> so the call to udev/hotplug doesn't pass any information?
<Keybuk> right
<Keybuk> btw, if you can mail those general pointers to linux-hotplug-devel@lists.sourceforge.net with a subject of "i2o needs MODALIAS love" or similar, that'd be great
<BenC> I guess it should atleast supply the class code
<Keybuk> then gregkh can jump on it
<Keybuk> BenC: yeah, even if it just supplies MODALIAS=i2o:c01 that's enough
<BenC> be better if I just do a patch, and send it
<Keybuk> fair enough :)
<Keybuk> make sure you cover both setting MODALIAS in the bus, and ensuring modules themselves generate alias lines covering them
<ogra> BenC, do you have any experience with the sermouse module or can you point me to a documentation about it #?
<BenC> ogra: none really, no idea about docs either
<ogra> oki, thanks 
<Keybuk> BenC: and if you could do mmc too while you're in that kind of mood <g>
<BenC> module-init-tools will need to know about this too
<zul> hmm...someone mention my name?
<zul> never mid
<Mithrandir> Keybuk: you gotten around to uploading a new udev?
<Keybuk> Mithrandir: to fix which?
<Mithrandir> Keybuk: add the 65_persistent_links and vol_id to udev-udeb
<Keybuk> Mithrandir: not even done that locally yet
<Keybuk> insufficient lap-dance-age
<Treenaks> ... Mithrandir.. lap-dancing.. for Keybuk?
<Keybuk> Treenaks: he put "kthxbye" on the end of the note
<Keybuk> he needs to make it up to me
<BenC> Keybuk: mmc might not be possible
<BenC> Keybuk: there is only redimentary detection aside from the few modules that load for PCI devices
<BenC> the rest is all dependent on odd host drivers that have some really odd detection schemes
<BenC> the best way to approach that might be that if mmc_core gets loaded, mmc_block should be loaded too
<BenC> I can't see mmc_core being useful without mmc_block anyway
<BenC> there are 5 mmc host drivers, maybe add "if this driver gets loaded, load the mmc_block aswell"
<HiddenWolf> BenC, sorry to bug you, but kernel-daily still isn't updated (last I checked)
<BenC> HiddenWolf: working on automating that, but trying to get 2.6.15-15 out right now
<HiddenWolf> BenC, cool, don't mind me.
<BenC> Keybuk: actually, there's only three mmc host controllers we are concerned about and two of them already have device tables
<BenC> I think I'll just make mmc_core and mmc_block as one module
<Keybuk> Who's feeling like dinner?
<mdz> Keybuk: I don't know how dinner feels
<mdz> I feel like a drink
<Kamion> "ask a glass of water"
<OpsVentus> hello all, I'm trying to diside on which GUI toolkit to use, I like Qt but it doesn't look very good on Gnome
<OpsVentus> GTK should look good on Gnome, but then don't look good on KDE
<OpsVentus> is there a toolkit for all desktops?
<Tm_T> I don't get it
<Tm_T> "Qt look good in KDE but not in Gnome" I thought it look the same in both
<Tm_T> and vice verse
<OpsVentus> well, I haven't tryed KDE for myself but, Qt is more for KDE and doesn't look very good on gnome
<OpsVentus> if it looks the same on KDE then it looks terrible
<ajmitch> morning all
<Riddell> Tm_T: qt without any kde themes does look terrible
<Riddell> gtk with only the build in theme likewise
<Tm_T> hum, never seen qt nor gtk without theme
<ogra> Riddell, nah ... gtk with the built in theme looks still usable ... (especially it has a sane default for fonts) QT makes me scream unthemed
<Riddell> ok, maybe gtk just looks ugly whatever the theme :)
<ogra> :P
<Tm_T> haha
<OpsVentus> so themes is the solution here
* Tm_T likes tiblit with Qt: not that shiny, much to configure
<ogra> Riddell, lets rather join Keybuk and Mithrandir and have a beer instead of having stupid arguments ;)
<Tm_T> ogra: yeah, but beer doesn't enlarge your vpenis
* ogra waves and goes over to the bar 
<ogra> Tm_T, i'm at a distro sprint ... large penisses rather hinder you here ;)
<Tm_T> haha
<ogra> night channel 
<Tm_T> gnight
<OpsVentus> night
<MisterN> n8
#ubuntu-devel 2006-02-08
<AlinuxOS> a
<\sh> infinity: do you want a status right now of your madwifi-ng test package?
<AlinuxOS> mjg59, maybe here ? :) hello...and sorry for time :)
<delire> frogfrogfrog: for an insight into the Linux filesystem structure: 'man hier'
<floam> BenC: you around?
<delire> sorry, that was a casualty of having moved IRC clients..
<Toma-> is there going to be any changes to the /etc/security/limit.conf settings in dapper?
<Toma-> or will forkbombs be a useful system tester?
<Lathiat> what implements the policys in that file?
<Toma-> libpam-modules
<Toma-> email the packager?
<Lathiat> Toma-: so, i doubt there are.. is there any reason too?
<Lathiat> Toma-: keep in mind the maintainer is the debian person and that any changes they may plan to make may or may not be reflected in dapper
<Toma-> ummm increased security?
<Lathiat> Toma-: whats wrong with the current settings?
<Toma-> its unlimited...
<Toma-> any user can run a million process's if he/she wants
<Lathiat> sure, if you want to change that yourself you can?
<Lathiat> imposing arbitrary limits at the distro level can break things
<Toma-> ok then.
<Lathiat> did we ever not have them unlimited?
<Toma-> i spose...
<Toma-> but its a weakness
<Toma-> and just a suggestion :)
<Lathiat> Toma-: i mean, if you wanted to discuss implementing defaults at the distro level you could, i wouldn't
<Toma-> but surely, a simple realistic limit would be better than no limit at all?
<Lathiat> Toma-: thats arguable, what is a "realistic limit" ?
<Toma-> say, 100 proc's?
<ajmitch> far too small
<Lathiat> i break 100 procs regularly
<Toma-> at user level?
<Lathiat> yep
<ajmitch> certainly
<Toma-> wow.
<Lathiat> system level too, like, apache
<Toma-> yeh id say for server something like 10000
<Lathiat> 1000 would probably be approaching more reasonable, if not more
<Toma-> i see
<Toma-> maybe ill just write a howto/wiki on beefing up security!
<Lathiat> sounds good :)
<Toma-> :)
<Lathiat> well you helped me today, i had no idea those files in /etc/security existed :)
<ajmitch> Lathiat: shame on you ;)
<Toma-> hehe. they exist, but nothing is set in them :<
<Lathiat> bur.st has ulimits set in the bash profile :)
<ajmitch> it's not as nice
<Toma-> so thats all going to be unchanged in dapper? so a wiki on it will still be useful with breezy+dapper?
<ajmitch> we can hardly state that it'll be unchanged, since release isn't until april :)
<ajmitch> it will probably stay as-is, unless there's a good reason to change it
<Toma-> ha, but no changes *planned*
<Toma-> ok cool
<nekohayo> hello, is there any rough ETA for flight 4?
<Yagisan> lamont: ping
<lamont> Yagisan: si?
<Yagisan> lamont: Could I kindly request you sync nmap 4 from debian ? The reduced memory requirements over what is in dapper would be good.
<lamont> you certainly could.
<lamont> so can I (and have done so)
<Yagisan> lamont: thank you :)
<lamont> Yagisan: against us is the fact that we're 3 weeks past upstream-version-freeze
<Yagisan> lamont: I know. IIRC it is functionally equivalent to what is in dapper, but a much smaller memory footprint.
<lamont> newer fingerprints, etc, etc.
<lamont> Unpacking x11-common (from .../x11-common_7.0.0-0ubuntu13_hppa.deb) ...
<lamont> Can't exec "locale": No such file or directory at
<lamont> oopd.
<lamont> oops, even
* lamont uploads a few random packages
<lamont> all with xorg-transition love
<seth> bah
<seth> ndiswrapper still not fixed
<crimsun> seth: wait for 2.6.15-15.20
<seth> well, I was going to just compile my own, but ndiswrapper-source still builds a -modules that depends on >= 1.8-1 instead of >= 1.8-0
<crimsun> oh, you can just hack the control template
<seth> right, I did that but it overwrote it, and I was too lazy to poke anymore
<seth> and according to malone #29842 it should have been fixed by -0ubuntu2
<Ubugtu> malone bug 29842 in ndiswrapper ndiswrapper-utils "ndiswrapper not installable" [Normal,Fix released]  http://launchpad.net/bugs/29842
<ajmitch> seth: but you're trying to build ndiswrapper-modules from ndiswrapper-source?
<seth> mm, I was reading that wrong. -utils installed, ndiswrapper happy now
<ajmitch> crimsun: alsa-driver patches need a bit of love to work with rc3 :)
<crimsun> ajmitch: ooh, nice
<crimsun> I guess I'd better update svn
<ajmitch> things like the make -j patch didn't apply
<ajmitch> looks like it might be included upstream now
<ajmitch> yeah, built fine without that 1 patch
* ajmitch is still waiting patiently for the kernel biulds to finish up
<guest21> the launchpad bug reporting tool for ubuntu is failing to accept my bug report
<guest21> i get "Oops"
<guest21> and it tells me to email you'
<guest21> how can i submit the bug report?
<Lathiat> guest21: you could file a bug against malone
<Lathiat> http://launchpad.net/products/malone/+filebug if that also OOPSes then send an email as described
<guest21> what ismalone?
<Lathiat> malone is launchpad's bug tracker
<Lathiat> its just the name for it
<Lathiat> like bugzilla, etc
<guest21> eh, well do you have somethign other than launchpad for reporting bugs?
<guest21> this one is critical
<guest21> kernel issue
<Lathiat> if you file a bug then please include as much info aabout what you were putting in the bug includin gthe url your tryign to file at
<Lathiat> guest21: No, but please file a bug about your problems filing a bug so it can be fixed
<guest21> i have a lab with 20 machines, all showing the same issue
<guest21> eh, ok
<Lathiat> guest21: breezy or dapper?
<guest21> breezy
<lamont> guest21: and this is the channel to discuss your patch.
<guest21> im not that bad an admin ;-)
<lamont> #ubuntu is the place to talk about the bug...
<guest21> lamont, the patch is out there apparantly -- but not verified
<guest21> not sure if anyone has tested it...
<guest21> the whole damn launchpad ubuntu is down
<guest21> https://launchpad.net/products/ubuntu
* lamont mumbles something about this not being a support channel, but wonders what the bug is
<Lathiat> guest21: no, thast the wrong url
<Lathiat> guest21: you want https://launchpad.net/distros/ubuntu
<Lathiat> guest21: what page are you tryign to file a bug at?
<guest21> eh sorry yea
<guest21> nope
<guest21> this isnt my first time having problems with launchpad..
<guest21> oh well, ill try to file tomorrow
<Lathiat> guest21: can you please file the bug against malone about the failing bug report? it can't be fixed if they dont know how to produce it :)
<guest21> Lathiat, i dotn know what package they want
<guest21> i mean what would i even say
<Lathiat> guest21: go to the url i pasted above
<guest21> i did
<Lathiat>  http://launchpad.net/products/malone/+filebug 
<lamont> guest21: https://launchpad.net/products/malone
<lamont> ah, Lathiat's is even better.
<Lathiat> :)
<guest21> im there but no idea wtf to say
<guest21> never mind
<guest21> i have to go to sleep
<lamont> guest21: "I did this and malone said this"
<guest21> been up 110 hours straight
<Toma-> if you took away read access for users+all from /boot/ would you break the system?
<lamont> Toma-: I don't see why...
<Toma-> yeh neither. nevermind :) i got help from the help chan... as i should have in the first place, sorry
<lamont> heh
<Toma-> <:)
<sladen> so, how am I supposed to use 'quilt'?  at the moment I'm guessing
<Lathiat> man quilt? :)
<lamont> sladen: mitzi prefers to use a quilt over her legs while watching TV.
<sladen> touch debian/patches/468_sudo_hint ; quilt push -a ; quilt add -p 468_sudo_hint src/su.c
<sladen> however, that just barfs
<lamont> debian/patches/series is the clue I needed for NMU'ing debian's glibc this week...
<lamont> but nfc how to use quilt
<Lathiat> you nmud glibc? scary :)
<sladen> and then gets into fusses over getting the wrong number of stiches in a line and getting her knitting needles crossed
<Lathiat> lol
<lamont> Lathiat: it needed it.
<lamont> no package is safe from Captain NMU
<Lathiat> ah hppa issue
<lamont> yeah
<lamont> it met my  "Zero Tolerance for Porting Issues" NMU policy :0)
* sladen is going to have Zero Tolerance for quilting very soon
* Lathiat grins
<Lathiat> for some reaosn i really laughed far too hard then :)
<viviersf> whens the next flight gonna be ?
<lamont> viviersf: whatever the schedule says, modulo the conversion to soyuz from DAK (build infrastructure changes affect lots of stuff)
<lamont> viviersf: mind you, that's just my guess.....
* lamont sleeps
<viviersf> hmmk
<dholbach> good morning
<Keybuk> *hugs*
* dholbach hugs Keybuk
<jsgotangco> hi dholbach Keybuk 
<Keybuk> hmm, I wonder how interesting it would be to collect the contents of /dev/.udev/failed from everyone
<mdz> I have 7 items theer
<mdz> there
<sivang> morning all
<mdz> 4 PCI and 3 PNP
<sivang> does anybody know what's the package name for mvo's upgrade tool? I want to dist-upgrade a laptop here and I want to give his tool a good test
<Keybuk> yeah, probably your PCI Bridge, ISA Bridge, SD/MMC Slot and a bunch of unknown PNP stuff
<seb128> 8 PIC, 4 PNP, 1 IEEE for me
<Keybuk> could be a good thing to add to the hardware database thing ... stuff that we don't have modules for
<jsgotangco> i have 10 items
<jsgotangco> 1 IEEE, 5 PNP, 4 PCI
<Keybuk> what's the IEEE ones?
<jsgotangco> class@ieee1394@000039000074fa13-0 
<Keybuk> what's in /sys/class/ieee1394/000039000074fa13-0 ?
<sivang> oh, found the fridge entry.
<Treenaks> Keybuk: on my mac mini, class@ieee1394@001124fffe74df0a-0 fails too
<Keybuk> mdz: cat /dev/.udev/failed/*pnp*/id
<mdz> PNP0200
<mdz> PNP0c04
<mdz> IBM0068
<jsgotangco> my /sys/class has at 4 IEEE dirs
<Treenaks> Keybuk: /sys/class/ieee1394/001124fffe74df0a-0/ has a 'device' and 'uevent' dirs
<jsgotangco> same here
<Keybuk> Treenaks: does device/ have anything interesting in it?
<jsgotangco> mine does
<jsgotangco> 9 files
<Keybuk> named?
<Treenaks> Keybuk: http://paste.ubuntu-nl.org/7935
<jsgotangco> address  ieee1394:000039000074fa13-0  length  specifier_id  version
<jsgotangco> bus      ignore_driver                power   uevent
<Keybuk> hmm, nothing really descriptive there :-/
<Keybuk> was hoping for a "name" or something
<Treenaks> Keybuk: I can tar it up and send it to you...
<Keybuk> Treenaks: nothing useful there, other than the device id
<slomo_> mdz: hi, avahi 0.6.6 was released yesterday... another (mostly) bugfix release :) do you have any objections against a UVF exception? changelog is located here: http://avahi.org/milestone/Avahi 0.6.6
<mdz> slomo_: please send mail, otherwise I may forget
<slomo_> mdz: ok
* sivang hugs pitti 
<mdke> morning all
<jsgotangco> hello
<pitti> hi everybody
<fabbione> hey slomo
<janimo> dholbach, mdz, xfce/thunar/exo UVF exceptions as requested on motu-list. Pinging both as they are in uni now but approved for main 
<janimo> hi pitti
<slomo_> hi fabbione :)
<fabbione> slomo_: xine is properly fixed now. it was an upstream bug. did you see the changes i did apply?
<dholbach> janimo: I send the requests in batched way to Colin and Matt.
<dholbach> janimo: did you do the sync/upload already?
<slomo_> fabbione: one mom, i'll take a look at cvs
<janimo> dholbach, no uploads yet
<dholbach> janimo: I'll pass it on.
<fabbione> slomo_: i did apply the patch only to our pkgs
<janimo> I asked for permission to have it in time for when I actually want to sync ;)
<janimo> dholbach, thanks
<fabbione> slomo_: http://people.ubuntu.com/~fabbione/xine.diff
<dholbach> janimo: I do this weekly, as explained on the mailing list.
<fabbione> slomo_: that's the diff between ubuntu2 and 3
<janimo> dholbach, ok I just saw that most other uvf mails got answers on the list but this didn't :)
<dholbach> janimo: answers, but after several days
<slomo_> fabbione: thanks
<dholbach> janimo: and those that got answers get passed on to Matt and Colin.
<Lathiat> who do i need to speak to about packages not appearing right? (iirc this binary name was moved from 1 source package to another)
<dholbach> janimo: (sufficiently good answers)
<fabbione> slomo_: as i explained to siretart, in theory after you change configure.ac you should autoreconf
<dholbach> janimo: you may have seen the "batch" mails
<fabbione> sladen: but it was failing, so i used a trick to propagate the option to configure
<slomo_> fabbione: autoreconf is definitely not failing ;) i used it to get our stripped tarball... anyway, this patch works... what do we want more? ;)
<fabbione> slomo_: nothing..
<fabbione> it might have been my environment that was wrong.. 
<fabbione> just that you know..
<fabbione> that's it
<dholbach> janimo: just a headsup: lots of xfce-ish stuff is still (build)depending on xlibs stuff
<janimo> dholbach, I just commited a fix for undepending on static-libs
<janimo> any other?
<dholbach> I notived yesterday.
<janimo> yes I got a bug in LP today so fixed it
<dholbach> it were around8-9 packages?
<janimo> hmm libxfcegui and a few other -dev libs depending on it
<dholbach> ah ok
<janimo> I''l have to look maybe I missed some
<janimo> thanks for the headsup :)
<janimo> have you escaped the plague?
<dholbach> Yeah. :-)
<dholbach> I just felt tired one day.
<dholbach> So that was fine.
<jsgotangco> "the distro sprint of death"
<Keybuk> we don't count him in the list of survivors
<sivang> heh
<dholbach> infinity: could you please try to give back gnome-icon-theme?
<infinity> dholbach: Sure.
<dholbach> infinity: Woohoo!
<pitti> mdz: openssl097 can go as well
<Keybuk> mjg59: reject the fix to bug 30335 if you don't like it
<Ubugtu> malone bug 30335 in linux-source-2.6.15 "mmc subsystem needs MODALIAS love" [Normal,Fix committed]  http://launchpad.net/bugs/30335
<infinity> pitti: \o/
<infinity> pitti: Whacking mozilla as we speak.
<pitti> infinity: mysql-dfsg just went to universe, 4.1 is close
<pitti> infinity: you mean enigmail?
<mdz> pitti: anastacia confirms
<dholbach> Wow.
<pitti> CLEANUP DAY!
<dholbach> pitti: smurf said something about gnutls transition. 
<pitti> I just need to fix the libtool breakage of redland-bindings for mysql 4.1
<pitti> dholbach: yes, that's still on the list
<pitti> dholbach: openldap has trouble with gnutls12
<dholbach> pitti: maybe smurf knows more about it.
<seb128> GNOME1 to universe!!!
<dholbach> ROCK'N'ROLL!
<infinity> dholbach: Built.
<dholbach> XMMS to Universe!
<dholbach> GTK1 to Universe! :)
<dholbach> infinity: WOOHOO!
<seb128> run away from mvo
<infinity> pitti: Yes, enigmail being done so mozilla can move.
* dholbach hugs infinity
* pitti hugs infinity 
* mvo weeps
* pitti hugs mvo, too
<dholbach> seb128: gnome-icon-theme built :)
* mvo sniffs
<seb128> ock
<seb128> rock
<Mithrandir> Riddell: are you done with the monitor soon?
<Riddell> Mithrandir: yeah, take it
<jbailey> Isn't xmms in universe yet?
<dholbach> nope
<dholbach> evms-gui is the other culprit
<jbailey> It's notlike there's ever been a security hole or update in it, why bother having it in main?
<fabbione> meh don't touch xmms :)
<dholbach> Hehe.
<fabbione> pitti: ping
<fabbione> pitti: ping
<fabbione> no you don't get pings :)
<dholbach> pitti: hey
<Mithrandir> jbailey: because users might want support on it.
<jbailey> Mithrandir: I think on average most users won't have a clue that it's there.
<Treenaks> jbailey: or we point them to beep-media-player, which is GTK2
<Treenaks> or we fix rhythmbox/gstreamer of course
<Mithrandir> jbailey: sorry, I was talking about evms, not xmms
<Mithrandir> and I figure most users won't know about that either, but they won't know about apache or squid either
<jbailey> Mithrandir: Well, my statement somewhat truer for evms than xmms, but so far I'm not advocating the evms go away. =)
<Mithrandir> I would be _very unhappy_ if evms was thrown out of main; I'd rather have not build the gtk frontend
<jbailey> i'd expect that the target audiences of squid and apache do actually know that it's there.
<jbailey> Right. =)
<jbailey> I'd rather evms not eat partition tables and that upstream care about it on ppc, but I'm a bit picky that way.
<Mithrandir> never ate a partition table for me
<jbailey> Mithrandir: Lucky you. =(
<infinity> Maybe it just wasn't hungry enough.
<jbailey> Tried it on ppc? =)
<Mithrandir> no, not yet.
<jbailey> Recommend that you don't.
<Mithrandir> I'd probably rather just fix it.
<jbailey> At the time it was my main machine so my next goal was only getting my data back.
<jbailey> I'll probably try to fix it sometime after my pegasos box works again.
<Mithrandir> heh
<Mithrandir> yes, I'll do it on my peg too.
<Mithrandir> it's a peg1, though. :-(
<jbailey> Suck.
<jbailey> I have a peg2, but I instaled one of Svenl's newer firmwares.
<Mithrandir> it broke?
<jbailey> Unfortunately, neither linux or grub2 will boot now.
<Mithrandir> that's slightly unfortunate
<jbailey> I apparently need a newer yaboot to get everything to run, and I didn't have time to burn a CD with a recovery setup.
<jbailey> And then.
<jbailey> well
<jbailey> apathy set it.  y'know?
<jbailey> s/it/in/
* Mithrandir blinks at Kamion's amd64.
<Mithrandir> it's _clearly_ smoking crack
<Kamion> Mithrandir: hmm?
<Mithrandir> Kamion: it booted off the USB hard drive just fine, somehow, then didn't find hd2,2 (since it was 0,2)
<Mithrandir> Kamion: any chance we could have usb_storage in the netboot images? :-)
<Kamion> they're in hd_media presumably ...
<Kamion> err ... surely for netboot you can get usb_storage before needing to access any disks.
<Kinnison> hi Kamion, how're you today?
<Kamion> i.e. get it from the network
<Mithrandir> Kamion: well, if choose-mirror wasn't falling over, sure.
<Kamion> Kinnison: tired and sore-throat but otherwise recovering I think
<Kamion> Mithrandir: that would be the root problem then ...
<jbailey> Kinnison!
<jbailey> Kinnison: Seems it was just the tube. =)
<Kamion> netboot ain't really designed for the case where it doesn't work
<Mithrandir> Kamion: cdebconf-priority could be useful, too
<Kinnison> jbailey: yay
<Kinnison> jbailey: I'm glad. because I wouldn't want to have to think bad things about Tito's
<Mithrandir> Kamion: shocker. :-)
<jbailey> Kinnison: Keybuk's assertion that simply the presence of the tube can make one ill seems to be accurate. =)
* Kinnison grins
<jbailey> Kinnison: Right. =)  Still a litle greasier than I like, but I would actually be willing to try it again on another trip here.
<ogra> Mithrandir, oh, please dont make the image bigger again with hd drivers in the netboot image ...
<Kinnison> jbailey: yay
<Kamion> Mithrandir: I agree on that one
* ogra is operating at the edge of 55MB thin clients here ...
<Kamion> (cdebconf-priority)
<ogra> (every byte counts) :)
<Kamion> ogra: not that I'm arguing hd drivers should be added, but the installer should work in 32MB now
<Kamion> please do test that, might be +/- a few MB
<ogra> Kamion, we should probably have an option to add single selected modules to one of the initramfs modes then ...
<Keybuk> jbailey: the great thing about the tube is, of course, the fact the inter-carriage doors are openable
<Keybuk> so you have *no* excuse for throwing up inside
<Mithrandir> Kamion: I'll do the cdebconf-priority change upstream too, it seems it's done for m68k, but nobody else.
<Kamion> ogra: the installer's memory consumption and the installed system's initramfs are *still* unrelated
<Kamion> Mithrandir: yeah
<ogra> Kamion, err, yes ...
<Mithrandir> Kamion: actually, I'll just move it to base.  I can't think of a single place where it should not be.
<jbailey> Keybuk: you live in a city where they installed urinals ourside of the national art gallery that are only open between midnight and 6 am so that the ravers wouldn't erode the historic building.  Yours is a practical country.
<jbailey> Well, I guess you don't actually live here.
<jbailey> But you live closer than I do. =)
<\sh> moins
<pitti> hey \sh 
* jsgotangco goes out for friday night parties
<\sh> hey pitti :) defeated the island plaque? :)
<pitti> \sh: yes, finally :)
<Keybuk> muahahahaha
* Keybuk slices yet more crap out of alsa
<ogra> *giggle*
<\sh> pitti: good to hear that you all are recovering :) 
<JaneW> \sh: yeah, but sladen just arrived... be afraid, be VERY affraid!
<jsgotangco> lol
<\sh> JaneW: lol...sladen is a quaker...he meant no harm....;)
<siretart> morning!
<JaneW> \sh: :)
<JaneW> jsgotangco: where are my pics? 
<jsgotangco> oh
<jsgotangco> wait
<\sh> JaneW: or the plaque came from scotland :) blame riddell then :) *eg*
<jsgotangco> JaneW: http://www.flickr.com/photos/headgeekette/
<jsgotangco> these are not mine though (have yet to transfer mine)
<jsgotangco> its just sabdfl in a black suit and gold tie
<JaneW> \sh: actually we suspect it's from cambridge
<JaneW> jsgotangco: nice haircut (you and mark...)
<jsgotangco> ill upload the ones with malcolm and hande later
<\sh> who is marks wardrobe manager? he should be killed for this golden tie thing around marks neck...it hurts my eyes ;)
<Treenaks> Is there a reason we don't enable dir_index on ext3 filesystems by default?
<sladen> does anyone undersatnd quilt.  quilt refresh ; quilt pop ; quilt push says "File series fully applied, ends at patch"  (missing off the one that was pop and refusing to reapply it)
<Kamion> Treenaks: IIRC last time it came up upstream advised us not to do it yet
<Keybuk> mjg59: remind me ... /etc/apm and /etc/acpi are entirely separate, right?
<mjg59> Yes
<Keybuk> and we still support apmd and stuff
<mjg59> Yes
<Keybuk> right, just making sure I don't get too carried away with ^K
<Keybuk> I still can't decide between; in /etc/modprobe.d:
<Keybuk> install some-module modprobe --ignore-install some-module && { modprobe -Qb some-other-module ; : ; }
<Keybuk> vs. in /etc/udev/rules.d:
<Keybuk> SUBSYSTEM=="module", ACTION=="add", NAME=="some-module", RUN+="/sbin/modprobe -Qb some-other-module"
<Keybuk> ... I really must stop editing /var/lib/dpkg/status to test upgrads
<jordi> hmm, what does an ubuntu system do when you boot runlevel 1?
<jordi> does it just log in as root, without asking a passwd?
<Keybuk> drop you to a shell
<Keybuk> yeah
<jordi> I never tried that
<jordi> ok
<Keybuk> after all, if you can boot to runlevel 1, you can stick init=/bin/sh instead
<jordi> 88yes
* StevenK waits for his new machine to boot up again.
<StevenK> It's a novetly having a desktop machine that's quiet.
<Mithrandir> I'm looking forward to getting home and not sitting besides a 2U rack server any more.
<StevenK> Heh.
<StevenK> My Dual Athlon (with 8 fans, sounds like a jet turbine) has been replaced with a SFF amd64.
<Mithrandir> heh
<Mithrandir> my amd64 has three fans: one on the GPU and two 12cm case fans.
<Mithrandir> quite quiet
<StevenK> This has two.
<StevenK> One for the CPU, and one for the PSU.
<StevenK> And I can't hear either of them.
<janimo> jordi, you can drop the thunar po upload, as upstream was not unanimously interested in rosetta. thanks
<StevenK> Oh blah, the power just dipped again.
<jordi> janimo: thanks
<jordi> janimo: only we can't remove anything from the queue just now :)
<jordi> it'll be gone eventually, thanks for the notice
<mdz> Mithrandir: no CPU fan on your amd64?
<Mithrandir> mdz: nope, just a big heatsink
<maswan> Mithrandir: you should get a fanless gpu?
<Mithrandir> maswan: I had one, but it wasn't dual-dvi.
<maswan> Mithrandir: Ah
<Mithrandir> it's very, very hard to find decent fanless GPUs with dual DVI which doesn't cost two arms and a caravan of camels.
<maswan> Mithrandir: The amd64 I'm on now has just one big fan, IIRC.
<maswan> might be a gpu fan there that I dont' remember though
<Mithrandir> maswan: dual dvi and 6600GT or better? :-)
<maswan> Mithrandir: nVidia Corporation: Unknown device 0161 (rev a1)
<maswan> ehm.
* maswan tries to figure out how to get hold of that data :)
<Mithrandir> pciids.sf.net
<maswan> GeForce 6200 TurboCache(TM)
<Mithrandir> yeah, those are easy to get, but their 3d performance isn't too good
<maswan> well, some screensaver stuff goes aroudn in 3d, I think.
<maswan> in other words, no, I don't care about 3d performance. :)
<fabbione> Mithrandir: actually a camel i Egypt is worth about 700USD
<Mithrandir> fabbione: just think about what a whole caravan would be
<fabbione> Mithrandir: i have been offered a few for my wife.. but i wasn't really sure if it was a good deal.. for the other guy :)
<ogra> fabbione, thats a grown up ?
<Keybuk> mjg59: laptop-mode seems to be mysteriously on for people
<mjg59> Keybuk: Fun
<\sh> A camel == 700USD? 
<mjg59> Keybuk: (Nowhere near a laptop right now - /etc/acpi/power.sh fiddles with that, and it's supposed to do something sensible on boot)
<freeflying> Mithrandir: hi
<Keybuk> hmm, ENABLE_LAPTOP_MODE=false
<Keybuk> I suspect you have a shell bug ;)
<\sh> fabbione: do you think a camel is more worth in Dubai? 
<Mithrandir> freeflying: hi
<Keybuk> no... it's even more obvious than that
<Keybuk> /etc/rc2.d/laptop-mode ... :)
<Keybuk>            ^S20
<freeflying> Mithrandir: would you mind give me some advice on remaster dapper's livecd ?
<Mithrandir> freeflying: was it you I mailed the other day, or was that somebody else?
<freeflying> Mithrandir: not me 
<Mithrandir> freeflying: (I wouldn't mind in either case if you write it up in some sensible way and put in on the wiki)
<mjg59> Keybuk: Yeah, that's only supposed to put it into automatic mode
<Mithrandir> freeflying: basically, all you need to do now is to mount the cd, mount the image, copy the contents of the image to somewhere and then chroot into that and customise that.  When done, do mksquashfs on the place you customised and you get a file out which you put on the cd instead of the current filesystem.squashfs
<freeflying> Mithrandir: have there a scripts now for doing that ?
<Mithrandir> freeflying: none I know of.  Should be easy enough to write one, though
<freeflying> Mithrandir: thx
<ritvik> when i switch to a tty and then switch back (ctl+alt+F1 <====> clt+alt+F7) X-server crashes. any idea ?
<mjg59> ritvik: Sounds like a bug. What driver are you using?
<Kamion> I've just demoted a big load of xserver-xorg-input-* to universe
<Kamion> xserver-xorg-input-acecad xserver-xorg-input-aiptek xserver-xorg-input-calcomp xserver-xorg-input-citron xserver-xorg-input-digitaledge xserver-xorg-input-dmc xserver-xorg-input-dynapro xserver-xorg-input-elographics xserver-xorg-input-fpit xserver-xorg-input-hyperpen xserver-xorg-input-magellan xserver-xorg-input-microtouch xserver-xorg-input-mutouch xserver-xorg-input-palmax xserver-xorg-input-penmount xserver-xorg-in
<Kamion> if any of these are sufficiently important to you that you think you can make a case that they're supportable and should stay in main, please tell ubuntu-devel@lists
<mjg59> Kamion: Cut off after penmount
<ritvik> mjg59, any thing specific you want to know? just a fresh install
<Kamion> xserver-xorg-input-penmount xserver-xorg-input-spaceorb xserver-xorg-input-summa xserver-xorg-input-tek4957 xserver-xorg-input-void
<Lathiat> unrar-nonfree was changed to produce the 'unrar' binary and it hasnt gone properly into ubuntu, who do i need to ask to sort that out?
<mjg59> ritvik: You haven't changed anything? Not installed nvidia or ati drivers? If not, file a bug and include the output of lspci, /var/log/Xorg.0.log and /etc/X11/xorg.conf
<ritvik> mjg59, nope no extra direvers .... cool i'll file one bug then 
<Mithrandir> grr, md5sum mismatches on the internal mirror here in the hotel
<Keybuk> right
<Keybuk> that's alsa butchered
<Keybuk> muahahaha, if anyone's sound card works, file a bug :)
<Mithrandir> mine haven't, for a little while.
<Mithrandir> I think I'm blaming dmix, since it seems to fall over when ekiga and muine both try to touch it
<Keybuk> actually, this hopefully fixes the silly boot errors and stuff
<Mithrandir> Keybuk: you broke alsa.  Please fix, kthxbye.
<Keybuk> Mithrandir: ...
<Mithrandir> (postinst looks for /usr/share/alsa-base/snddevices)
<Keybuk> it does?
<Mithrandir> that is, alsa-base.postinst.
<Keybuk> which postinst?
<Mithrandir> line 120
<Mithrandir> so my syslog claims
<Keybuk> oh, bah, hang on, didn't catch that one
<ritvik> mjg59,  back after another crash :-) #30395
<mdke> dholbach, can you avoid doing an ubuntu-docs upload for the next few days pls? 
<dholbach> mdke: Yeah.
<dholbach> mdke: just tell me, when you're settled again.
<dholbach> mdke: I'd rather have not uploaded from here.
<jsgotangco> mmm?
<Diziet> checking whether  accepts -g... no
<Keybuk> http://people.ubuntu.com/~scott/20060202_new-world-order_keybuk.ogg
<Keybuk> THREE HOURS TO GO!  UPLOAD NOW, WHILE YOU STILL CAN!
<\sh> I hope you guys are on duty tomorrow :)
<jpatrick> Keybuk: for what?
<Keybuk> jpatrick: katie go bye-bye
<\sh> jpatrick: soyuz lands 
* Kinnison suggests you don't upload lots and lots now
<Keybuk> interesting fact ... the soyuz crash lands
<Treenaks> Keybuk: I had a reboot a few hours ago, and evms took ~ 30 seconds
<Kinnison> because otherwise the builders won't quiesce in any sane amount of time
<Keybuk> http://www.astronautix.com/graphics/s/soy1crs3.jpg
<tseng> Keybuk: haha
<\sh> Keybuk: soyuz or shuttle....both can crash 
<Keybuk> \sh: yes, but one is designed to during normal operation
<\sh> hmm...I just said something FREUDish, right?
<Diziet> I'm not sure it counts as a crash if it comes down in quite that many pieces.
<Keybuk> is that like the Challenger?  it didn't crash, and didn't explode ... so when asked what happened, the best reply is "bad things"
<Diziet> Both of them disintegrated, I think.
<mdz> Challenger certainly didn't; some very large pieces were recovered
<Treenaks> Black dragon scale mail.
<\sh> well, at least, the last crew knew that something is happening'
<Treenaks> Keybuk: (watching the video) I can test 2 USB gamepads ;)
<Keybuk> do it then :)
<Treenaks> Keybuk: in an hour, when I get home :)
<Treenaks> (hm, I have one connected to my mini-mac, but there's no device for it I think)
<Treenaks> how do I test?
<fabbione> dear desktop team, please gconf-tool2 sucks less
<Treenaks> fabbione: No pony for you!
<seb128> Keybuk: should the network-manager bugs be assigned to you?
<Keybuk> if you like
<seb128> ok, doing so
<Treenaks> Keybuk: I have a /dev/input/js0, but only when I manually load joydev
<Keybuk> Treenaks: "udevmonitor -e", plug it in, paste output somewhere in my direction
<Treenaks> Keybuk: I can't get to the plug atm.. it's ~50 km away :)
<Treenaks> I can manually load/unload the modules...
<Keybuk> that doesn't help
<Keybuk> I need to see the add event that _doesn't_ load joydev
<Keybuk> it's probably a "not a joystick" bug :)
<Treenaks> Keybuk: hm.. ok :)
<Treenaks> Keybuk: I'll try in an hour then :)
<Mithrandir> Keybuk: can we support UUID=$uuid and not just /dev/disk/by-uuid?
<Keybuk> Mithrandir: on the kernel command-line?
<Mithrandir> Keybuk: yes
<Keybuk> sure, but that's an initramfs-tools thing
<Keybuk> get it to convert UUID=$uuid into ROOT=/dev/disk/by-uuid/$uuid
<Keybuk> (as it has to mount it anyway)
<Mithrandir> true
<Treenaks> oh, speaking of which, my /dev/sda1 moved to /dev/sde1 in dapper (from a breezy install + upgrade)
<Treenaks> which kind of sucked
<Mithrandir> infinity: ^^ ?
<Keybuk> Treenaks: bug me about it when you have that machine nearby
<Treenaks> Keybuk: I'm working on that machine now
<Keybuk> do you have another machine you can work/irc from while you reboot that one? :p
<Mithrandir> infinity: currently, it dies with a failure to parse UUID= in parse_numeric.
<Treenaks> Keybuk: not really, but I can report back after rebooting :)
<infinity> Mithrandir: Mmkay.  And what if you pass me both UUID and ROOT, who wins? :)
<Treenaks> Keybuk: (and I won't leave irc, as my client is running on another machine)
<Mithrandir> infinity: root=UUID=blah root=/dev/sda3?
<Mithrandir> infinity: arbitrary.  Don't do that.
<infinity> Ahh.
<infinity> I idn't catch the root=UUID= magic.
<infinity> Easily handled.
<Keybuk> Treenaks: it suggests you have two scsi cards
<Mithrandir> infinity: coolie.  When can I have it? :-)
<infinity> May.
<infinity> (Or in a few mins...)
<Mithrandir> infinity: a few minutes sounds lovely.
<Treenaks> Keybuk: I have 1 SATA hard-disk, and 4 USB memory-card slots
<Keybuk> Treenaks: what are sda-sdd?
<Treenaks> Keybuk: CompactFlash, SD, MemoryStick, xD
<Mithrandir> infinity: if you want extra brownie points, supporting root=LABEL=blah would be nice too
<Treenaks> (or something like that)
<Mithrandir> to be converted into /dev/disk/by-label/blah, obviously
<infinity> Mithrandir: /dev/disks/by-label/
<infinity> Mithrandir: Right.
<Mithrandir> yes
<infinity> Mithrandir: You'll have them both after I'm done listening in on this discussion.
<Keybuk> Treenaks: what's PCI bus id of your SCSI card and those 4 things?
<fabbione> what is an ftp client that can do ssl?
<Keybuk> lftp
<fabbione> ok thanks
<Treenaks> Keybuk: the SATA controller is 0000:00:1f.2 0106: 8086:27c1 (rev 01)
<Treenaks> Keybuk: and the smart card readers are on USB
<Treenaks> uh
<Treenaks> memory card
<Keybuk> and what's the USB controller PCI bus id?
<Treenaks> 0000:00:1d.7 0c03: 8086:27cc (rev 01)
<Keybuk> ok
<Keybuk> that's why your disk is later then :)
<Keybuk> it'll find the USB controller first
<Treenaks> That's not the problem-- the problem is that it changed from breezy, which broke booting :)
<Keybuk> that's because we support USB-booting now
<Treenaks> sure, but does that imply breakage? :)
<Keybuk> yeah
<Treenaks> hmm, isn't that bad?
<Keybuk> I'm not sure there's a way to avoid it
<Keybuk> your USB controller also probably takes less time to initialise and wins the lower ids
<Keybuk> well, not an easy way
<Keybuk> certainly not a fast way
<Treenaks> I bet I'm not the only one with this problem
<Treenaks> But I understood it'll be avoided for the future bby using uuids/labels for mounting in 'new' dapper installs?
<Keybuk> that's one way
<Keybuk> we have other bugs where a controller moved from hda to sda
<Treenaks> 'Dapper Release Notes' ISBN: XXXXXXXXXX; 500 pages.
<Keybuk> dapper release is long enough off that we expect to fix this kind of stuff
<Keybuk> assuming people file bugs :)
<Treenaks> Keybuk: Filing already ;)
<PandabeaR> Can someone help me by any chance?
<Treenaks> Keybuk: on what though?
<Keybuk> Treenaks: ude
<Keybuk> udev
<PandabeaR> I was pasting something the terminal was spitting out at me
<PandabeaR> and the admin in ubuntu thought I was spamming
<Keybuk> PandabeaR: this isn't a support channel
<PandabeaR> and I didnt get to explain... could somone tell the admin in ubuntu channel to let me back in?
<PandabeaR> I know...thats where I am trying to go... :(
<PandabeaR> I would be very grateful if somone would do that for me though.
<Keybuk> talk to them directly yourself
<PandabeaR> I dont know how :(
<Keybuk> /query theirnick
<PandabeaR> servas?
<PandabeaR> i forgot their nick lol :((
<Kamion> you should have got a message saying who you were kicked by
<Kamion> sounds like seveas
<PandabeaR> ty
<Treenaks> Keybuk: bug 30418 :)
<Ubugtu> malone bug 30418 in udev "Root moved from /dev/sda1 to /dev/sde1 in breezy-&gt;dapper upgrade" [Normal,Unconfirmed]  http://launchpad.net/bugs/30418
<Treenaks> Seveas: your bot broke :)
<PandabeaR> Whats that?
* Keybuk wonders why a lot of his bugs involve 'e'
<Keybuk> sde and hde
* Simira wonders where Mithrandir went
<ogra> Simira, he sits to my right at the floor
<Keybuk> Simira: there's a group discussion going on atm
<Simira> ah, right
* Keybuk thinks this is just a diversion to stop people uploading and let the buildds catch up before THE END OF THE WORLD
<Treenaks> Keybuk: at least your bugs don't involve /dev/hd
<Treenaks> (or /dev/sd
<Seveas> Treenaks, broke?
<sladen> http://www.paul.sladen.org/ubuntu/bug-buddy/find-source-package.sh
<Treenaks> Seveas: &gt;
<Seveas> ah
<Keybuk> Treenaks: why didn't you use the Unicode  ?
<Treenaks> Keybuk: because I have no clue how to type that (except using gucharmap)
<Keybuk> Ctrl-Shift-2192
<HiddenWolf> Keybuk: don't tell me you know that by heart...
<Keybuk> HiddenWolf: ok, I won't
<sladen>  ... ah, so that's why I could send ctrl-shift-6 to the cisco 20minutes ago
<Treenaks> HiddenWolf: I suspect Keybuk knows all of unicode, or at least large chunks of it
<Keybuk> sladen: ?
<Keybuk> Treenaks: the pretty parts ;)
<sladen> Keybuk: ^^ is the cisco break sequence;  I couldn't send it
<Keybuk> is that like the old CTCP PING sladen +++ATH bug? :p
<Seveas> Treenaks, bug 30418
<Ubugtu> malone bug 30418 in udev "Root moved from /dev/sda1 to /dev/sde1 in breezy->dapper upgrade" [Normal,Unconfirmed]  http://launchpad.net/bugs/30418
<HiddenWolf> Root moved?
<HiddenWolf> ah
<mdke> dholbach, great thanks
<dholbach> mdke: de rien
<ritvik> ritvik_zzz
<Kamion> criawips/universe has an unsatisfied dependency on i386: libgoffice-1-1 (>= 0.1.2)
<Kamion> libcriawipshelper0/universe has an unsatisfied dependency on i386: libgoffice-1-1 (>= 0.1.2)
<Kamion> libcriawips0/universe has an unsatisfied dependency on i386: libgoffice-1-1 (>= 0.1.2)
<Kamion> anyone want to look at those? removing libgoffice-1-1 now
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | Soyuz rollout begins 1800 UTC, please hold of
<pitti> Kinnison: is it ok to upload to -security?
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | Soyuz rollout @ 1800 UTC, no more uploads ple
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | Soyuz rollout @ 1800 UTC, no more uploads pls
<desrt> pitti; who is mh21?
<Kinnison> pitti: You still do that to katie
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | SOYUZ ROLLOUT AT 1800UTC DO NOT UPLOAD
<Kinnison> that's neater, thanks scott
<pitti> desrt: it's a friend of mine, why?
<Kamion> Kinnison: we've still been changing some overrides as of very recently
<Kamion> Kinnison: I'm assuming you're carrying over the NEW queue and that we don't need to process it all first?
<desrt> pitti; just filed a bug.  was wondering if he's a newcomer to the gnome scene?
<Kamion> konq-kim          | 0.8.3-0ubuntu1     | source                                 | 3 days old
<Kamion> konq-encrypt-menu | 0.3-0ubuntu1       | source                                 | 3 days old
<Kamion> pybaz             | 1.5pre1-1          | all                                    | 1 day old
<Kamion> vim               | 1:6.4-006+2ubuntu1 | all amd64 hppa i386 ia64 powerpc sparc | 1 day old
<Kamion> python-soappy     | 0.11.3-1.4ubuntu1  | all                                    | 5 hours old
<Kamion> ^-- current NEW queue state
<pitti> desrt: well, he did some private hacks here and there, so he's a bit familiar with it; and he has lots and lots of hacking experience in general
<desrt> pitti; cool.  send him my cheers for catching my oops :)
<Kinnison> Kamion: I'll ask elmo what he'd prefer to do
<Kinnison> Kamion: please wait
<Kinnison> Kamion: elmo says "I will deal with it before we move to soyuz. You can process anything you need now if it's urgent"
<Kamion> Kinnison: there's nothing there I need
<Kinnison> Kamion: right, elmo will deal with it all then
<Kinnison> Kamion: so you can relaz
<Kamion> fine, thanks
<Kinnison> Kamion: if you feel understressed, feel free to come over to the office and laugh at us as we do our headless chicken impressions
<Kamion> I think that making further efforts to spread the death plague to you lot might not be the best idea
<Kamion> much though it might amuse from a distance
* Kinnison grins
<Amaranth> how many people ended up getting that?
<Kamion> Amaranth: getting what?
<Amaranth> whatever is going around
<Amaranth> sounds like a pretty nasty flu
<Kamion> Amaranth: about three-quarters of the Canonical distro team
<zul> i blame billie g
<Kamion> so 12 or 13 or so
<Amaranth> ouch
<pitti> desrt: I'll do once I'm back home :)
<Amaranth> i hope it wasn't anything like the one that was going around here a month or so ago
<Amaranth> i was completely down for 4 days
<Amaranth> although that was probably all the cold pills and cough syrup
<fabbione> E: Couldn't find package libavahi-compat-howl-dev
<fabbione> gobby B-D on libobby
<fabbione> obby B-D on that
<seb128> we don't package the howl compat stuff 
<Keybuk> REMOVE GOBBY!  QUICKLY!
<Kamion> how did the current obby ever build then?
<Kamion> which it manifestly has
<dholbach> Kamion: thanks for noting - will  rebuilt criawips.
<Kamion> libavahi-compat-howl-dev has never been in the archive AFAICT
<tepsipakki> Mithrandir: what was that firewire-thing that you wanted to be tested a few days back?
<tepsipakki> I'm now able to do that
<mdz> Kamion: obby didn't used to require avahi/howl
* ..[topic/#ubuntu-devel:pitti] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | SOYUZ ROLLOUT AT 1700UTC DO NOT UPLOAD
<Kamion> ah, I see, the current version of obby has never built
<Kamion> only a previous version
<ogra> it wasnt supposed to be synced :/
<ogra> obviously my fuckup :(
<pitti> ogra: upload a fix :-P
<Mithrandir> tepsipakki: already done, but please do test that the current daily live cd works for you.  If not, tell me.
<Mithrandir> pitti: uh, 1700?
<ogra> apparently :(
<Mithrandir> gnnr
<pitti> Mithrandir: just adapted the topic to reality :/
<mdz> Kinnison: ...
<Kinnison> please wait
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | SOYUZ ROLLOUT AT 1800UTC, UPLOADS QUEUED
<pitti> Kinnison: ok, sorry, somebody just mentioned that uploads were not working again any more
<pitti> s/again//
<desrt> soyuz = fear
<Kinnison> pitti: whoever said that is labouring under a misapprehension
<Keybuk> Kinnison: jbailey says you told him not to make an upload
<Keybuk> (and showed us the /msg where you said this)
<Kinnison> I told him it wasn't worthwhile if it wasn't essential
* kiko laughs
<kiko> you guys make storms in teapots
<Keybuk> "make hppa work" seems quite essential ?
<Kamion> kiko: this particular one was kind of important to get in before the deadline
<kiko> well
<Kamion> since the port in question will not be able to fix the issue for some time
<mdz> hppa can suffer
<kiko> then upload it -- but do note that hppa builds will not work for a while.
<tepsipakki> Mithrandir: but what was the command, /lib/udev/... something ?-)
<Keybuk> so can we upload, or can we not upload?  and if we can, for how long?
<kiko> you can upload up to 18:00
<kiko> as we agreed before
<Kinnison> Indeed, we will queue uploads after that
<mdz> but be sensible
<kiko> correct.
<mdz> don't upload something which will take hours to build
<Kinnison> but at 18:00 the buildds are being disabled, etc
<Keybuk> ok, then Kinnison shouldn't have put "no more uploads" in the topic :)
<ogra> Keybuk, that was pitti
<Mithrandir> tepsipakki: /lib/udev/path_id /dev/firewiredevice
<kiko> excuse Kinnison we're a bit busy preparing right now
<Keybuk> * Kinnison [Topic]  + no more uploads ple
<Kinnison> Look, it's irrelevant, let's just drop this conversation because it's wasting people's time
<kiko> right
<kiko> see you all on the other side
<Keybuk> have fun :)
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | SOYUZ ROLLOUT AT 1800UTC, UPLOADS QUEUED
<mdz> (breezy is old news)
<HiddenWolf> mdz: no, really. ;)
<Kinnison> Soyuz rollout messages will be provided in #SoyuzRollout -- That is a moderated channel so we'll try and keep it neat
<seb128> oh, double click on a chan name do /join, nice xchat-gnome :)
<pitti> seb128: xchat has that option, too :)
<seb128> pitti: ah, didn't know, I double clicked to select it in fact :)
<fabbione> Kinnison: are you going to wait for the buildd to flush the queue or are you going to close * down at 18:00 ?
<fabbione> i need to know if i have to stop my buildd now or wait for the first reject.
<Kinnison> umm, pretty much close down at 18:00
<fabbione> ok
<Kinnison> We're certainly stopping cron.unchecked then
<fabbione> ok
<fabbione> both of them will stop with the next uploads,.. if they can get in good... otherwise tough
<ogra> slomo_, ping
<Keybuk> 2s out!  damn
<Treenaks> Keybuk: I have the output of udevmonitor -e
<Keybuk> Treenaks: does the joystick (probably the /inputX UDEV event) already have PHYSDEVDRIVER=usbhid or something?
<Treenaks> yes
<Keybuk> cool
<Keybuk> fixed that already then
<Treenaks> NAME="Logitech Logitech RumblePad 2 USB"
<Treenaks> wow.. it knows that
<Keybuk> the funny thing is that's hardcoded in the device
<Treenaks> cool
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | SOYUZ ROLLOUT IN PROGRESS, UPLOADS QUEUED | The revolution will not be televised
* ..[topic/#ubuntu-devel:desrt] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | SOYUZ ROLLOUT IN PROGRESS, UPLOADS QUEUED | What revolution?
<Mithrandir> seb128: should I whine at you or dholbach about icons looking weird?
<Mithrandir> (missing thumbnails and some ugly default icons)
<seb128> dholbach is doing most of the work on icon stuff nowadays
<dholbach> that was fixed in libgnomeui recently
<Keybuk> does dholbach deal with all packages beginning "libg" and you deal with "g" ?
<dholbach> Keybuk: no
<Keybuk> how do you split it up?
<Kamion> lucky there aren't so many packages beginning 'u', I guess
<Keybuk> who does u?
<Kamion> you
<seb128> dholbach just won the "x"
<delire> hmm, new Novell screenies look v'nice: http://www.flickr.com/photos/gamehack/sets/1506658/
<Mithrandir> what's the command line tool to get the mime type of a file?
<delire> icons have had a complete workover.. they using tango?
<Mithrandir> they're using jpegs for screenshots?
<delire> hehe it would appear so.. suspicious
<HiddenWolf> delire: they are *mockups*
<HiddenWolf> delire: IE, a vision of how it should or could look, rather than how it actually looks.
<delire> HiddenWolf: hmm that would explain why they look so good.
<delire> HiddenWolf: i realise what a mockup is.. so fixated was i upon the images i didn't see the word "mockup" itself :/
<delire> gorgeous nonetheless.
<Keybuk> shiny
<HiddenWolf> delire: they should be quite possible.
<HiddenWolf> looks quite polished indeed.
<Keybuk> looks like a total rip-off of Vista
<delire> Mithrandir: could you use 'file' +/or 'extract'?
<HiddenWolf> Keybuk: hey, if it works...
<delire> Keybuk: wouldn't know, i've yet to see screenshots of it
<Mithrandir> delire: no, there's a gnome-ish tool to do it.
<HiddenWolf> I thought vista was a lot more blinig-ish, last I checked
<Keybuk> also the little icon in the bottom-left looks more Sun-ish than Novell-ish
<Mithrandir> delire: basically, I wonder why gnome-vfs seems to think an attachment I downloaded is some kind of a movie rather than a tnef
<delire> Mithrandir: for interfacing with the gnome-mime-data db? i don't know..
<delire> Mithrandir: hehe yes, a good question.
<Keybuk> HiddenWolf: nah, is reasonably elegant
<HiddenWolf> Keybuk: I don't trust that new "banner" thing MS has got going.
<Mithrandir> delire: I found it; gnomevfs-info
<HiddenWolf> Keybuk: looks utterly unworkable to me.
<delire> it does look like they are using Tango.. nice to see the awful old gnome ~/ icon gone from a gnome desktop.
<Treenaks> delire: aww.. I liked it ;)
<HiddenWolf> delire: yeah, go figure, novell started the tango project and funds it.
<delire> Treenaks: hehe yes, for *sentimental reasons* i would guess ;)
<delire> HiddenWolf: a logical connection..
<Treenaks> delire: 'Those who forget their past are destined to re-live it' or something like that
<delire> that Novell desktop does seem a tad 'Blue'. why so many desktop environments default to this scheme i don't know. 
<delire> Treenaks: and those who relive the past are probably already dead..
<HiddenWolf> delire: blue is a color that is linked to calm, serenity, clear days, happy emotions, and upper class.
<Treenaks> and Windows crashing
<delire> HiddenWolf: blue blood perhaps, yes.
<Treenaks> HiddenWolf: So what's wrong with brown? :)
<delire> HiddenWolf: it is in fact sky blue that is linked to calm. 'navy blue' evokes agitation and nervousness in many prisoner test cases.
<HiddenWolf> well there you have it. :)
<Treenaks> we want GREEN windows :)
<HiddenWolf> Treenaks: a lot, but I like it.
<HiddenWolf> Treenaks: skin it.
<delire> purple apparently is the colour inspiring thought, and intellectual rigour. though purple for a desktop is a big call.
<HiddenWolf> delire: you'd have to shoot me before I'd use purple.
<Treenaks> HiddenWolf: pink, maybe ;)
<HiddenWolf> Treenaks: always, anytime.
<delire> Treenaks: pink would gain you a small but very committed audience.. 
<HiddenWolf> delire: heh, that's what he's getting at. ;)
<Treenaks> HiddenWolf: yes, the little girls! :P
<delire> Treenaks: speaking of green, a new Cinelerra theme is completely green. called "Greenelerra" no less.
<delire> HiddenWolf: ;)
* HiddenWolf watches Queen of the Desert one more time
<delire> Treenaks: those using it tend to make environmental documentaries. i'm lying of course.
<Treenaks> delire: scary (found a screenshot)
<HiddenWolf> delire: so, will we make dapper look all spiffy? ;)
<delire> Treenaks: it looks a hell of alot better, but it's interesting how there are some colours that force themselves upon you and some that don't.
<Treenaks> HiddenWolf: All colors of the rainbow
<Treenaks> delire: I know
<Treenaks> delire: I know quite a bit of color theory :)
<MisterN> Treenaks: no brown, then
<HiddenWolf> Treenaks: we. want. pink.
<Treenaks> MisterN: why not? it's very calming :)
<delire> HiddenWolf: sheesh, "spiffy" is a bad start.. i think brown is working well. Brown isn't a colour associated with being "refreshing" but that is exactly the response i get from so many when i roll our Ubuntu on their machine.
<MisterN> Treenaks: ain't in the rainbow
<Treenaks> MisterN: so?
<Treenaks> doesn't mean it's not a color
<MisterN> of course
<HiddenWolf> delire: it's just that dapper does look allmost exactly like my warty's
<HiddenWolf> delire: We need some new art!
<Treenaks> HiddenWolf: no, the shade of brown changed a bit, and we lost the naked women along the way :(
<HiddenWolf> Treenaks: which is a total plus!
<MisterN> when i upgraded from breezy to dapper i thought the gtk+ theme changed a tiny bit. and i disliked this tiny bit so i switched to mist.
<HiddenWolf> MisterN: it did, clearlooks is now using cairo for almost everything, and has gotten slower to prove it. :)
<MisterN> HiddenWolf: heh well... and... well... i didn't like how it looked. my machine's fast enough *g*
<delire> HiddenWolf: i agree.. frankly those icons need a total overhaul. they really throw Ubuntu back in time.
<HiddenWolf> MisterN: machines are never fast enough, developers always manage to choke em up. :)
<Treenaks> HiddenWolf: All we need is good RENDER acceleration (EXA) in all drivers
<MisterN> HiddenWolf: true enough.
<Treenaks> HiddenWolf: then Cairo is fast again
<delire> HiddenWolf: people hang off the screenshots on osdir.. if they look just as before then fewer people will adopt and/or upgrade.
<Treenaks> HiddenWolf: on _all_ machines, even old ones
<HiddenWolf> Treenaks: I guess you could dream about that. ;)
<MisterN> cairo would probably be better when using GL which is experimental for now
<MisterN> (better=faster)
<delire> HiddenWolf: i'd like to see pretty solid beagle integration and an option for composite mode on install if direct rendering is detected. that'd be a start.
<Treenaks> MisterN: EXA would be enough for 'most' cases
<MisterN> Treenaks: hmm k.
<delire> i definitely think we could take a leaf from Novell Desktop where those panel balloon 'applets' are concerned. they are good.
<HiddenWolf> Hm
<HiddenWolf> When breezy and gnome 2.12 where coming up, I was all excited.
<HiddenWolf> For 2.14/dapper not so.
<HiddenWolf> Can't pinpoint why.
<Treenaks> HiddenWolf: you haven't seen enough new l33tness on the planet :)
<delire> nautilus's old icons that appear to have absolutely nothing to do with the broader Ubuntu theme. they should finally be laid to rest.
<HiddenWolf> delire: that's all just waiting on $someone to step up and design something.
<HiddenWolf> delire: not many people can/will do that, unfortunatly
<delire> HiddenWolf: i thought there was a bounty on those that was fulfilled
<delire> "Ubuntu Artwork"
<HiddenWolf> delire: I must have missed that.
<HiddenWolf> delire: point still stands, someone who can do it has to step up
<delire> hmm i can't find it now.. will keep looking.
<delire> HiddenWolf: really i think Ubuntu is in a perfect position to offer the challenge to a Design Academy as part of a student project.
<delire> it's not everyday that students have an opportunity to design an icon set for an operating system.
<HiddenWolf> delire: why not pitch the idea to some people then? mdz, Kamion, sabdfl, others?
<delire> HiddenWolf: perhaps i will do this. ubuntu-devel list?
<HiddenWolf> yeah, with a cc to the art-team list, I guess.
<delire> HiddenWolf: good thought..
<delire> sadly while art.gnome.org has a few contrib icon sets, none of them really seem to "fit" ubuntu.
<HiddenWolf> delire: and most are incomplete to an extent.
<delire> HiddenWolf: it would seem so..
<delire> HiddenWolf: what would you like to see change? anything specific?
<HiddenWolf> delire: nothing. I'm not an artist, so I'll keep out of it. save that what ubuntu is currently using does not feel modern at all.
<delire> HiddenWolf: right.
<pmjdebruijn> hi
<pmjdebruijn> I'm trying to create an Ubuntu package for a GNOME application
<pmjdebruijn> but the GConf schemas installed in the Makefile are ofcourse not installed
<pmjdebruijn> how do I accomplish this in my .deb
<Keybuk> are the installed into debian/$pkgname when you do $(MAKE) install DESTDIR=$(CURDIR)/debian/$pkgname ?
<pmjdebruijn> Keybuk, the schemas are installed into /usr/share/gconf/schemas when I install my .deb
<pmjdebruijn> but they are not installed into gconf itself
<Treenaks> pmjdebruijn: do you dh_gconf ? (I read something about that a few days ago(
<Keybuk> oh, no idea
<pmjdebruijn> Treenaks, thanks
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | SOYUZ ROLLOUT IN PROGRESS, UPLOADS QUEUED | The soyuz revolution, silly
<pitti> Riddell: http://people.ubuntu.com/~pitti/packages/xpdf-poppler-3.0.1.tar.gz, in case you want to forward this to that Gentoo guy
<Riddell> pitti: thanks
<delire> hehe "If your initramfs is broken in any way, please save a copy for infinity"
<delire> will dmix still be used as the native ALSA sound mixer in Dapper? still at a loss to understand how apps that explicitly use /dev/dsp (skype/gaim/numerous others) can happily co-exist with ALSA friendly apps in a typical modern desktop computing session (listen to music, receive call in skype, audio email notification from system).
<Amaranth> delire: Only one app can use /dev/dsp at a time so those are still not going to work.
<Amaranth> delire: But apps that use ALSA should work fine.
<delire> do you see any solution for this? this has been a showstopper 'bug' for many Ubuntu adopters, and linux adopters generally.
<Amaranth> delire: Make developers fix their code.
<delire> sure, this should at least be communicated to the user. i feel it would be wise to somehow notify the user that an app that explicitly writes to /dev/dsp is not compatible with ALSA..
<delire> skype for instance, is considered by millions to be a 'vital' desktop application.
<Amaranth> flash appearently uses /dev/dsp as well
<HiddenWolf> skype is a POS with regards to playing nice. :/
<delire> yes it does..
<siretart> delire: tell them to you ekiga, or better tell skype to fix their code
<Amaranth> i think there was some work on making it possible for multiple apps to use /dev/dsp but it was decided that it wasn't possible
<HiddenWolf> siretart: non-skype can't communicate with skype
<delire> siretart: skype has been told this again and again. they do not listen, but competing VOIP solutions are not in the foreground enough for people to bother sticking with poor performance on Linux.
<delire> poor skype performance..
<siretart> delire: thats one reason why I don't use skype anymore
<Amaranth> gizmo, google talk, ekiga
<delire> regardless, from an adopters perspective, this is a showstopper. worse, most if not all new users of Ubuntu will not know why their app doesn't play nice with ALSA
<Amaranth> this are all better solutions
<Amaranth> and they can even all talk to each other, i think
<delire> Amaranth: now that is interesting.
<Amaranth> i know gizmo and gtalk can talk to each other
<siretart> delire: in fact, I didn't have problems on my computer using skype along with other applications on my hardware
<delire> if users could even import buddies from Skype to another IM/VoIP client, we'd be rolling.
<Amaranth> delire: not possible, unless those buggies where using the other client
<siretart> skype is overrated. really
<Amaranth> delire: because Skype uses a proprietary protocol
<delire> siretart: can you make a skype call and receive a system notification, or while having xmms playing at a low volume in the bg?
<delire> Amaranth: yes it does.
<siretart> delire: sure
<siretart> delire: you just need a soundcard which does real hardware mixing, like sb live
<delire> siretart: right, which cuts out most portables.
<Amaranth> siretart, delire: Or dmix
<siretart> delire: do you have a proposal how to solve this technically?
* delire looks at ekiga
<Amaranth> but neither one of those fixes /dev/dsp
<delire> siretart: no, i've just started looking into it really. i work in the educational sector, mostly as a teacher, though often in areas of Linux/FOSS advocacy. this has come up in the past as a complaint while a school was performing feasibility analysis, "Linux has broken audio".
<delire> siretart: so they defaulted to Apple machines, which suffer no such issues.
<siretart> better don't try to run broken applications
<delire> siretart: sure, one can encourage them to avoid the large number of applications which do not play well with ALSA. this however cannot be enforced and being non-developers, they are simply unaware why it doesn't work. this is a problem as Linux (and all the good ALSA apps) are taken down with it.
<siretart> delire: what 'large number of applications' are you talking about. up to now, you only mentioned skype
<siretart> even doom3 or quake4 play nicely alsa
<delire> realistically it will be several years before third-party developers like those at Skype or Nero, or Alias get it together and realise that ALSA really isn't an option.
<Simira> are London people out now?
<delire> siretart: sure, there are many games that do work. Flash is a fairly important client for many users. 
<delire> siretart: there are several games that don't however.. i forget which but it comes up from time to time. 
<pmjdebruijn> delire, why isn't ALSA really an option?
<delire> i believe gaim is another.
<delire> pmjdebruijn: i am saying that there should be no choice as to whether or not to use ALSA. just use it.
<pmjdebruijn> delire, oh like that... right... indeed...
<siretart> delire: gaim uses esd and has no problems with alsa
<AlinuxOS> mjg59, here ? :)
<delire> in other words, and yes i put it badly, "ALSA isn't an option" - it's the only way.
<kiko> ALSA is the future
<Amaranth> ALSA is the only thing we have, and it's great
<Amaranth> people just need to use it
<siretart> people DO use it
<delire> agreed, if only big name third-party developers that want to support Linux, would use it.
<kiko> why don't we drop oss?
<Amaranth> skype and flash and gaim don't :P
<kiko> that
<Amaranth> kiko: because programs still use it
<kiko> 'd fix the problem :)
<delire> those three applications are critical for many users..
* kiko trolls
<Amaranth> kiko: only if linus did it
<kiko> indeed.
<delire> hehe
<siretart> delire: sorry. I don't have the impression that ppl who think that applications like skype and flash are critical would want something else than windows anyway.
<kiko> hey skype is useful
<delire> ridiculous as it may sound, it would be good to have an audio router/wrapper that passed writes to /dev/dsp to ALSA subsystem instead..
<siretart> kiko: skype is crap. it would be useful if it would work
<delire> siretart: you underestimate many many Ubuntu users.
<kiko> it works for me somewhat
<kiko> (and it's used daily to harass launchpad people)
<siretart> delire: dropping alsa is not an option, because alsa has many many features that oss does not have.
<siretart> delire: oss is supported via alsa oss emulation. this is intended as interim solution for legacy application which need to be ported
<delire> siretart: i was not suggesting dropping ALSA at all.
<delire> siretart: i was saying that application developers should know that they must use ALSA, that writing to the sound device directly would render their project considered 'broken'.
<pmjdebruijn> siretart, that OSS emulation breaks some appjes, like the binary Quake 3, because they use direct memory mappings for performance
<pmjdebruijn> siretart, anyway the icculus.org folks fixed that, now q3 uses ALSA
<delire> pmjdebruijn: i thought that was only their distribution of q3.. did that move upstream to idsoftware's binary?
<pmjdebruijn> delire, no
<delire> AFAIK they are still distributing the client..
<delire> right
<pmjdebruijn> delire, I should have said ioq3 now uses ALSA
<siretart> delire: you think skype wouldn't know that?
<delire> siretart: i have no reason to think that they do know that.
<neuralis> siretart: hey there
<neuralis> siretart: are you still planning on getting NetbootManagement in for dapper?
<siretart> delire: http://support.skype.com/index.php?_a=knowledgebase&_j=questiondetails&_i=189&nav=+%26gt%3B+%3Ca+href%3D%27index.php%3F_a%3Dknowledgebase%26_j%3Dsubcat%26_i%3D11%27%3ESkype+for+Linux%3C%2Fa%3E
<siretart> neuralis: I don't think I will have time left do do that :(
<siretart> neuralis: things have not been going as I wanted them to go :(
<neuralis> siretart: that's alright, I just wanted to check.
<delire> siretart: good to see.. 
<delire> siretart: maybe i can give skype a go again now ;)
<siretart> delire: they have this entry for AGES. I lost all hope that they are really working on that
<delire> siretart: last time i used skype it absolutely locked down the card during a call.. i'll try it again.
* delire notes Audacity doesn't seem to be ALSA aware.
<delire> how ridiculous. from their page: "Audacity can use ALSA natively if you compile it to use PortAudio v19 instead of the default, v18. Note that v19 is still evolving and not as well tested, but it is the only way that Audacity supports ALSA."
<delire> .. the only capable audio-editor on Linux (outside of the megalithic Ardour)..
<kiko> mdz, what is this I hear about a bald fabbione?
<mdz> kiko: we have a wager
<kiko> thanks for your support
<jdub> Generating locales... en_AU.UTF-8... up-to-date
<jdub> elite!
<tseng> jdub: Cancel, hey?
<jdub> hrm?
<tseng> i find en_{AU,CA}.UTF-8 locales amusing
<jdub> oh
<delire> does that exist?
<\sh> uh..oh...everyone is working...soyuz lands...ubuntuusers.de is moving to another location...rock
<tseng> en_UK ill buy
<jdub> up-to-date <- the interesting bit
* delire checks
<kiko> soyuz soyuz soyuz
<delire> what is all the fuss about.. 
<\sh> kiko: tell kinnisson he should delete the logfiles or he should move to canada to get more space on the target :)P
<kiko> heh
* \sh has to much java in his head
<\sh> s/to/too/
<mdke> jbailey, around?
<mdke> jdub, did you see my mail about yelp customisations?
* mpt sprinkles some soyuz sauce on his breakfast
<mdke> jbailey, unping
<Kinnison> mpt: mmm tastes like binary packages
<pmjdebruijn> tseng, http://www.xs4all.nl/~bruijn9/temp/corbicula_0.0.20060203-4_i386.deb
<Simira> jdub :) Where in the world are you today?
<\sh> ok...
<\sh> going to bed and movie time
<\sh> kiko: Kinnison: good luck with the migration to soyuz :)
<kiko> thanks \sh 
<kiko> you should try watching the movie before going to bed
<\sh> kiko: well..I'm going to lay down in bed and watch the movie...but I know me, in the middle of the movie, I'm falling asleep :)
<kiko> I used to do that all the time.
<kiko> then I put the TV in the room where the couch is
<kiko> now, I wake up on the couch
<kiko> I feel like I'm 30
<Simira> :)
<\sh> kiko: hehehe..
<\sh> kiko: well..that's life..and think about me...I'm 35 :)
<kiko> oh, that's right, I am 30.
<Simira> \sh: THAT old... 0_o
<Simira> ;p
<Simira> \sh: are you in London?
<\sh> Simira: no :)
<\sh> Simira: just turned 35 last month
<Simira> \sh: oh, so you just got that old. How does it feel?
* Simira feels like 35 also, just didn't get there yet
<\sh> Simira: well, it feels like 34 and 12 months...but it's more difficult to find a job
<Simira> \sh: more? Isn't it just difficult, period?
<\sh> Simira: well...it was difficult during the dot.com crash periode, but now it's _much more_ difficult because of the age 
<\sh> looks like, that I have to do some more freelancing work...
<\sh> anyways...bed is waiting...
<Simira> \sh: actually it got much better here during the last year. If you're stuck, move to Norway. It's actually a lack of people in IT now
<Simira> sleep well
<\sh> Simira: I'm waiting for some updates of my job applications next week..so I have to see what is happening anyways...
<\sh> ok...cu in a couple of hours
<Mez> infinity/lamont/someone who knows a bit about the buildds - ping
<AlinuxOS> mjg59, here brother?
<AlinuxOS> or someone who can tell me how can we include georgian fonts in "main" for ubuntu?
* Kinnison thought you'd had it explained very carefully to you before
<AlinuxOS> Kinnison, ;)
<AlinuxOS> hello
<AlinuxOS> si I'd like to tell you that...we have talked with font's author..
<Kinnison> Telling me won't help, I'm not an Ubuntu developer
<AlinuxOS> and he is agree to make them GPLed...
<AlinuxOS> but he is asking us , how and in wchich form we must do it...
<AlinuxOS> what about mjg59 ? I guess he is devel ?
<AlinuxOS> no?
<Kinnison> He is, but he concentrates on power management
<Kinnison> Most of the ubuntu developers are asleep or going to be very soon
<Kinnison> because it's 22:42 local time at their conference
<Kinnison> Also, the Ubuntu archive is moving to launchpad tonight
<Kinnison> so I think they're probably all taking a well earned break
<AlinuxOS> so what can I do?
<AlinuxOS> when can I talk with them?
<kiko> write to ubuntu-devel I'd suggest
<AlinuxOS> kiko, I've alredy written...
<kiko> really? and what happened?
<AlinuxOS> 2 days I'm waiting for an answer.
<AlinuxOS> kiko, I know that you are lauchpad developer :) is not true ? :)
<kiko> that is quite true
* Mez yawns
<AlinuxOS> ;) how can I apply for a couple of fonts GPL or LGPL text ? there is some ritual to do ? or what ?
<AlinuxOS> I'm quite confused :)
<kiko> AlinuxOS, I'd suggest talking to dholbach or ogra on monday
<AlinuxOS> sd-tux, sign this nicks :) We must ping them monday :)
<kiko> they are the best guys to start off talking to
<torkel> AlinuxOS: you can also check: http://www.gnu.org/licenses/gpl-faq.html#FontException and http://www.gnu.org/philosophy/license-list.html#Fonts
<AlinuxOS> http://www.kde-look.org/content/show.php?content=16645  torkel
<AlinuxOS> so author can add a text behind a fonts download link... with specification that fonts are gpl...
<AlinuxOS> and + link to GPL license.
<torkel> AlinuxOS: another link which describes howto use gpl in your fonts: http://www.gnu.org/licenses/gpl-howto.html
<AlinuxOS> torkel, thank you a lot....
<AlinuxOS> we are writing a letter :)
<AlinuxOS> to this guy....
<AlinuxOS> ;)
#ubuntu-devel 2006-02-09
<torkel> in short yes, but to be on the safe side you should ship the license with the font, not link to it, as a link can be changed without notice
<trulux> what package provides xmlparse.h in dapper?
<trulux> it's missing from expat package
<kiko> something -dev
<torkel> trulux: http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=xmlparse.h&searchmode=searchfiles&case=insensitive&version=dapper&arch=i386
<desrt> the revolution is ......
<trulux> torkel: thanks, then there's a bug regarding this file. libwww brings it's own one but refers to /usr/include/xmlparse.h instead of w3-libwww/xmlparse.h
<kiko> that happens sometimes
<kiko> when the package author has too many drinks before running dput
<Kinnison> kiko: dude, get back under your bridge
* kiko swings club
<desrt> kiko; your type has throwing axes these days
<Kinnison> kiko is way too useless to throw an axe properly
<kiko> I am a lame troll
<Kinnison> he can throw a good strop
<kiko> nickisson needs to go pay attention to the soyuz rollout and leave me alone
<Kinnison> desrt: so, how're you dude?
<desrt> Kinnison; awful
<Kinnison> desrt: never mind, we're worse
<kiko> night of the living troll
<desrt> :)
<desrt> been a weird week and now i find out the archive is dead
<desrt> :(
<Kinnison> it's not dead
<Kinnison> it's just sleeping
<kiko> it's actually UNDEAD
<desrt> i should be sleeping.
<Kinnison> you should?
<Lathiat>  the archives dead?
<desrt> Lathiat; tried using apt lately? :)
<Kinnison> desrt: you're saying archive.ubuntu.com is down?
<Lathiat> im updating now happily?
<desrt> Kinnison; the last term of school is a bit of a joke
<kiko> so am I actually
<desrt> 0% [Connecting to ca.archive.ubuntu.com (206.75.218.53)] 
<desrt> ...
<Lathiat> well, maybe ca. sucks
<ajmitch_> desrt: ah, but that's ca.
<Lathiat> archive. works fine :)
<kiko> !!! blame it on canada
<Lathiat> haha
<desrt> pfah.  you guys love to give canada the shaft
<ajmitch_> everyone can blame canada
<kiko> it's free
<desrt> yay.  workage.
<kiko> the clown that admins that mirror should be woken up and sent to fix it
<desrt> that "clown" is me, jerkface
<Lathiat> uh akk, big words
<kiko> language!
* Lathiat hides
<slomo_> lol
<desrt> awesome.  new evolution
* desrt hopes against hope that the tray icon is gone
<kiko> isn't calling people jerkface against the CoC?
* kiko hides
<desrt> clown too.
<Lathiat> desrt: evolution just wants to be mor elike kmail, so it got a tray icon
<kiko> I NEVER SIGNED
<slomo_> desrt: that's hopeless :)
<desrt> ya well
<desrt> i also never signed
<desrt> -ahem-
<Kinnison> please stop making us laugh, we have work to do
<desrt> Kinnison; i aim to make you cry
<kiko> is the noise disturbing the publisher?
<Kinnison> desrt: I don't think you've yet succeeded
<kiko> after all, it's ONLY TAKING UP 2388m of RSS
<Kinnison> kiko: is that all?
<kiko> well it is going up
<Kinnison> that's 600M more than it was a while ago
<Kinnison> yeah
<Kinnison> gotta love the ram hog
<desrt> in light of the term 'publisher' '2388m of RSS' could really mean 2 things
<kiko> that is true
<MisterN> n8
* lamont returns home
<kiko> just in time
<Kinnison> hey lamont
<Kinnison> guess what?
* Amaranth waits impatienly
<Amaranth> +t
<lamont> Kinnison: you love me???
<Kinnison> lamont: You know I always have and always will
* lamont feels touched.
* Kinnison will keep his hands to himself in the future
<lamont> although he fears it's not as touched as he's gonna feel.... :)
<lamont> so how about them hppa binaries?
<Kinnison> Well, they're too smelly to be in the new world order, sorry
<Kinnison> you'll have to ask kiko to dial the bits in by hand
<lamont> Kinnison: does that mean I should keep uploading, and kiko will give them the love they so desparately desire?
<lamont> or should I grab my ankles?
<lamont> oh, and when can I start uploading source changes again?
<Kinnison> grab your ankles and brace for impact
<Kinnison> we're queuing source uploads currently
<lamont> ah, so ok to upload, just don't expect any binaries in the next 10 minutes, yes?
<kiko> right
<lamont> libaio uploaded
<lamont> kiko: fwiw, all of the hppa uploads are signed with this key (and nothing else)
<lamont> pub   1024D/3CE5C004 2005-02-01
<lamont> uid                  Ubuntu hppa build signer <hppa@mmjgroup.com>
<lamont> s/and nothing else/and nothing else is signed with that key/
* StevenK tries to remember what the wiki page detailing the Soyuz stuff was.
<lamont> Kinnison: so kiko is moonlighting as a librarian, then?
<kiko> uhm
<kiko> Kinnison, can you tell lamont you were joking, pretty please?
<Kinnison> kiko: won't
<lamont> kiko: the ideal short-term solution (albeit __WRONG__ on so many fronts) would be to allow that key to upload hppa binaries (and nothing else)
<lamont> manually shoving them into the archive would be painful
* Kinnison points out that currently there's no way we can permit binary uploads in that fashion
<Kinnison> we need a db change first
<Kinnison> lamont: easiest is for you to get us an hppa box to have locally to be a buildd
<lamont> having katie live just enough to manage the hppa repository on jackass and merge it with launchpad at publish time would be my personal choice 2, although that also causes pain...
<lamont> Kinnison: yes.
<lamont> working on that...
<kiko> if you give us a box I will help karl carry it around the datacenter
<Kinnison> lamont: merge? how?
<Kinnison> lamont: the world is already hard enough
<Amaranth> Kinnison: if that happened hppa builds wouldn't hold other archs back, would it?
<kiko> it wouldn't
<lamont> Amaranth: the whole discussion is on how to glue hppa onto the side of launchpad's archive...
<lamont> Kinnison: I have an idea...
<Kinnison> lamont: I already don't like it
<lamont> so we have soyuz schedule the hppa builds on $random_machine, and that buildder has access to the REJECT queue where all the hppa binary uploads go.....   it's as simple as connecting the dots...
<kiko> my aren't we the trolls tonight
* lamont ducks
<Kinnison> lamont: seriously, hppa will just have to wait
<lamont> Kinnison: on a more serious note...
<Kinnison> lamont: "connect the dots" inside the launchpad database?
<Kinnison> not likely
<lamont> no no
<lamont> "build" == wget from the REJECT pile
<lamont> on a more serious note..
<Kinnison> pardon?
<lamont> I'm assuming that the hppa binary uploads get dumped in the equivalent of the katie REJECT queue, yes?
<Kinnison> essentially, yes
<lamont> if that queue were readable by some random buildd machine, it could "build" the hppa binary by fetching and verifying the sig.
<lamont> but yeah, I'm gonna see how quickly I can find a box.
<Kinnison> I don't see how it would do the build considering it'd be invoking sbuild
* lamont knows of one in the london area, I just need to convince its owner that he wants to trade his A500 for a J6000.
<Kinnison> the launchpad buildd infrastructure is much more locked down
<lamont> wget-from-reject instead of sbuild - it'd have to have some custom code there...  --> not gonna happen.
<lamont> that wasn't a serious suggestion
* Kinnison nods. You got the last three words right
<Kinnison> NOT GONNA HAPPEN
<Kinnison> :-)
<lamont> unless you thought it was good, of course...
* Lathiat grins
* Kinnison rarely thinks wget is good
<lamont> more seriously...
<Kinnison> .../ignore lamont's crazy schemes
<lamont> if we assume that it's going to take a 3-4 weeks before I can get machines there...
<Kinnison> I can't guarantee we'll have time scheduled to cope
<Kinnison> hppa may have to fall seriously behind
<lamont> if I kept an "official" repository of hppa bits, could those be merged into launchpad once the hppa machines get there?
<Kinnison> In theory I can hand-process those in batches
<Kinnison> it'd be a lot of work though
* lamont doesn't have enough units of $BEVERAGE, he fears.
<Kinnison> indeed not
<Kinnison> considering I have house-move stress too
<lamont> oh joy.
* lamont considers pointing out how _STUPID_ that is (moving at a time like this), but decides not to.
<Kinnison> dude, I've been trying to move for months
<Kinnison> it's not my fault that day one of the rollout sprint I get a call saying "right, the offer is in and accepted and the solicitors instructed"
<lamont> "NOT GONNA HAPPEN"???? :-)
<lamont> still, awsome that things are finally moving forward --> GONNA HAPPEN
* Kinnison grins
<lamont> you're already london, yes?
<Kinnison> sparc is rumoured to be due at the DC within days
<kiko> RUMORED
<lamont> so I heard
<lamont> Kinnison: ignoring the "fall behind" part of things for the moment...
<lamont> my real question is: can I let the buildd keep building things with the expectation that they will become the actuall debs in the archive, or should I just shut the buildd down and deal with scrounging hardware?
<lamont> with the assumption that those binaries may all arrive in one big fat pulse once the machines are in the DC
<lamont> hrm... actually, I have one A500 (currently doing multiple-duty as w-b host and buildd and hppa/sparc build-log publishing host)
<lamont> I could just have that shipped on monday
<lamont> which puts us a week or so from having hardware in the DC
<zakame> hi devs :)
<Kinnison> lamont: Don't expect anything you build to become official debs
<lamont> OK,
<lamont> in that case, I'll shut down the buildds, and plan on shipping at least one A500 on monday.
<Kinnison> Cool
<Kinnison> one hppa box at least will get on with trying to keep up
<lamont> next question...
<lamont> do you think elmo would kill me if I also set him a non-remotely-manageable 2U box or 2 with that A500?
<Kinnison> how stable are they?
<lamont> they tend to just stay up
<jsgotangco> wow nice hair keybu
<jsgotangco> k
<Swe3tDave> i've been trying to create my own ubuntu install cd, with language-support-fr(and its dependencies)  integrated on the cd, but so far i only got a semi-automated install, how do i tell d-i to copy language-support-fr(and the rest) to the target system along with ubuntu-desktop... i mean i even tried to rebuild ubuntu-meta.. i've been working on this for 1 week now.. anyone tried this before?
<Kinnison> lamont: He says he can deal with them, but he'd prefer A500s if at all possible. Slow machines aren't useful
<lamont> I've been rebooting them some, but as it currently sits the 2 hppa buildd's are an A500 and a J7000 - I haven't walked over to touch the J7000 in at least a month or 2, since I set it up
<lamont> J6000 is faster than the A500
<kiko> send them in
<Kinnison> which is the box?
<Kinnison> James wants to know what you're proposing to send him
<lamont> the other issue is that the current "fast" hppa boxes are PA8800-based, and that has cache coherency issues, at least as of yesterday (still)  That's being worked on, but precludes getting the really fast boxes shipped yet.
<lamont> J6000
<lamont> I currently have 1 A500 and 2 J6000 that I can send
<Kinnison> elmo says "that's fine by me"
<lamont> hrm... then there is that little issue...
<kiko> ok ok
<kiko> we promise not to swap them for cocaine
<lamont> I'll preinstall them with something, so he can upgrade/hack around with them...
<lamont> otherwise, install must be netboot, since breezy's kernel doesn't support the IDE chip that reaches the cdrom.
<lamont> or external scsi cdrom.
<lamont> iz a feature.
<lamont> I'll try to arrange to have one of the J6ks turn into an A500 once it gets to london, if elmo wants.
<lamont> anyway, kid time.
<lamont> both hppa buildd's quiescing - they'll still upload whatever they're building, but then they're done
<Kinnison> lamont: elmo says he'll prod you on irc in a bit
<lamont> Kinnison: and I'll work on getting even better boxes to trade them out for... I'm assuming y'all won't mind shipping the old bodies off to loving developers once I send you faster/better boxen. :-)
* lamont will be gone for at least 2 hours
<Kinnison> okay perhaps you should converse on email then?
<tseng> is there an email or similar annoucement explaining this soyuz business
<kiko> yes
<kiko> u-d-a
<kiko> sent yesterday
<kiko> jamesh
<kiko> err actually
<kiko> elmo
* kiko is fucked
<tseng> yeah, i didnt get it
* tseng checks spam
<tseng> kiko: on lists.u.c at least. thanks
<kiko> yeah
<kiko> enjoy
<tseng> kiko: dude, soyuz!
<kiko> yeah, you said it
<tseng> the package/buildlog viewer is awesome
<kiko> ah, thanks -- you shoudl thank cprov since he did that work, and mpt, because he did most of the design work
<tseng> cprov++
<cprov> tseng: thx
<psusi> anyone know who was playing around with squashfs-lzma?
<Amaranth> Mithrandir
<psusi> ahh, cool...  that's two things I need to ping him about...
<Amaranth> squashfs-lmza + lmza (7z) for packages would be awesome
<Amaranth> fit more stuff on the CD either way, plus smaller downloads
<psusi> I've been pondering the idea of moving old email in a Maildir to a squashfs image and mounting it with unionfs so the old mail can be compressed yet still appear to be normally availible
<psusi> but I've noticed that the normal squashfs only gets about 4:1 compression on my lkml Maildir
<psusi> a tar.7z gets 10:1...so I thought squashfs-lzma might do better
<floam> why does it need to be tarred? shouldn't 7zip do that?
<psusi> yea... I think I'm the one who started the 7z for packages thread... or maybe I just chapioned it a lot... I forget now ;)
<floam> that kind of kills one of 7zips features (being able to figure out what's in it without decompressing)
<psusi> floam, 7zip's archive format does not store posix stuff like the chmod and owner
<floam> oh, lame.
<psusi> I don't really care, I'm quite happy with .tar.7z
<psusi> I'm after the huge compression ratio not easy directory
<floam> still be quicker if you didn't need to untar afterwards
<floam> someone should bug the 7z people
<psusi> you can do the two in one step
<psusi> tar cf - /dir/to/backup | 7z a -mx=9 -si backup.tar.7z
<psusi> I do that with my current lkml Maildir and it goes from 100 MB to 10 MB
<psusi> never had a problem with it at home but a server at work I tried using 7zip to compress the full tar backups and it crashes at random places during the compress
<psusi> and gdb it seems is utterly incapable of debugging a multithreaded app
<psusi> reports all kinds of insane information when it catches the segv, and sometimes the process appears to terminate without gdb knowing
<psusi> very frustrating when the debugger doesn't work right
<psusi> it's also very frustrating when you can't terminate a process because the kernel decided it would be a good idea to enter an uninterruptable sleep while waiting for some dirty buffers to flush
<lsuactiafner> install disk of ubuntu 5.10 i386 doesnt have badblocks 
<lsuactiafner> so tell me how do i proceed to check the integrity of the disks?
<lsuactiafner> badblocks is a huge oversight 
<lsuactiafner> mistakes like this makes me think that 1/2 of the sytem is also done half-way only
<StevenK> steven@liquified:~% sudo which badblocks
<StevenK> /sbin/badblocks
<StevenK> lsuactiafner: /sbin/badblocks is in e2fsprogs which is Essential: yes
<lsuactiafner> on the install cd
<lsuactiafner> when it loads the install system up.
<StevenK> You'd like to run badblocks in the installer?
<lsuactiafner> yes
<lsuactiafner> why would i want to install a whole system on a broken system?
<StevenK> I thought there was an option to do that....
<lsuactiafner> last night i spent 3hrs to get the system configured
<lsuactiafner> to wake up to a currupted disk
<lsuactiafner> so now i would like to check my disk before i install it
<StevenK> My only suggestion is the Live CD, which ought to give you badblocks.
<lsuactiafner> StevenK : even if there was an option i ran mkfs.ext3 -cc and badblocks was missing. tried which badblocks and it wasnt there.
<StevenK> However, if your filesystem corrupted overnight, I'd suggest a new disk first.
<lsuactiafner> this pc is for entertainment, needs to load 5G from the 80G and everything else will be on the network
<lsuactiafner> but the disk will be a pain
<lsuactiafner> am using slackware 10.1 now to check the system
<lsuactiafner> but thats hardly the way to do it, doesnt inspire confidence
<StevenK> I'd also suggest you file a bug, which means that it may get fixed for Dapper.
<lsuactiafner> i hate bugzilla but someone should file a bug report to make sure badblocks will be included in the installer.
<lsuactiafner> i can hack my way thorugh this problem but most ppl that ubuntu cater for cant
<StevenK> Ubuntu doesn't use Bugzilla anymore.
<zakame> yay
<StevenK> lsuactiafner: By that reasoning, most people Ubuntu caters for won't know badblocks exists.
<StevenK> I actually haven't needed to run badblocks for quite a while. It's usually easy to replace the disk.
<StevenK> s/easy/easier/
<StevenK> Damn mplayer distracting me from typos.
<zakame> lol
<StevenK> zakame: I got a new amd64 last night, so I'm setting up the ia32 chroot so I can actually wish flesh-toned videos.
<StevenK> s/wish/watch/
<zakame> StevenK: w00t! I so wish I have an amd64 :P
* StevenK takes a photo.
<StevenK> zakame: http://wedontsleep.org/~steven/img_0920.jpg
* zakame checks
<lsuactiafner> StevenK : you only need a --enable-static compile with cpu-runtime detection and compile as 32bit code and you can use it to run wmv codecs
<lsuactiafner> ubuntu 64bit cant compile it but i used gentoo and slackware systems for my 32bit binary
<StevenK> Hrm. A large binary or a 332Mb chroot.
<lsuactiafner> 8mb binary
<StevenK> lsuactiafner: Could I, uh, borrow that?
<zakame> StevenK: beauty
<lsuactiafner> StevenK : its not the latest cvs
<lsuactiafner> and wmv only works in my console
<lsuactiafner> and it takes around 30m for me to upload it
<lsuactiafner> still want it?
<pitti> world: hello
<mdz> good morning pitti
<Kamion_> lsuactiafner: we don't include badblocks because it's redundant
<Kamion_> lsuactiafner: parted already provides that functionality via its check command
<Kamion_> lsuactiafner: which the installer runs automatically
<Kamion_>  /* Checks for physical disk errors.  FIXME: use ped_device_check()
<Kamion_> [...] 
<Kamion_> ped_geometry_check (PedGeometry* geom, void* buffer, PedSector buffer_size,
<Kamion_> [...] 
<Kamion_>         ped_timer_set_state_name (timer, _("checking for bad blocks"));
<zakame> ooh
<fabbione> pitti: Depends: ssl-cert (>= 1.0-11ubuntu1)
<fabbione> rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
<fabbione> rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
<rob> amd64 testers, do we need any?
<jbailey> rob: In a development distribution, testers are always needed. =)
<rob> jbailey, where should I point people?
<rob> someone just asked me
<Keybuk> spare amd64s wouldn't go amiss either :)
<jbailey> rob: I usually ask people what they're interested in.
<jbailey> It's easier to have fun when it's something thats..  mm fun.
<jbailey> Too early in the morning to come up with adjectives. =)
<Keybuk> rob: the Flight CDs are a good start (subscribe to ubuntu-devel-announce) as those can be downloaded and installed like any other ... then upgrade daily and file bugs when the magic smoke escapes
<VoX> anyone looking for an amd64 tester for dapper?
<VoX> :)
<Keybuk> VoX: we need as many testers of all creeds as possible
<rob> Keybuk rob: the Flight CDs are a good start (subscribe to ubuntu-devel-announce) as those can be downloaded and installed like any other ... then upgrade daily and file bugs when the magic smoke escapes
<rob> VoX, ^
<VoX> rob, is it possible to just dist-upgrade to dapper, or am i looking at a complete re-install?
<Kamion_> VoX: sure, just dist-upgrade
<rob> no, you can dist-upgrade
<Kamion_> installation tests are also welcome, but just to a spare partition or whatever if you like
<dholbach> you can test the dist-upgrade tool
<VoX> hmm
<VoX> what's the likelyhood that a dist-upgrade from breezy to dapper is going to break lots of things? i understand that there's no garuntees, but.. :)
<pitti> mvo: ^ that shouldn't be so bumpy any more, right?
<Keybuk> please file bugs if anything breaks :)
<pitti> VoX: we recently got a large number of reports from the dist-upgrade tool and fixed lots of issues
<dholbach> http://launchpad.net/malone will know about known breakages
<VoX> hmmm
<mvo> VoX: what pitti said :) currently it works pretty well, but quite a few packages give us trouble during the upgrade (file-overwrite errors, postinst failures etc)
<mvo> VoX: if you don't mind cleanup up afterward with apt-get install -f etc, then you can give it a try
<VoX> ah i dont mind as such, i'm just concerned about loss of data i guess
<rob> just back up
<rob> onto dvds or the like, I do mine onto an xbox
<pitti> VoX: a dist-upgrade should never wreck /home, it can just trash your system so that you might need to reinstall
<VoX> mmm
<rob> put /home onto its own partition
<VoX> rob: i kinda cant at the moment
<rob> oh
<VoX> all my drives are at atleast 90% capactity
<rob> yeah, thats why my xbox comes in handy
<rob> its got a 250Gb hd in it
<rob> my /home has survived several reinstalls, its quite handy to have it on its own partition
<VoX> i need to spend a few days burning a few spindles of dvds
<VoX> yeah 
<VoX> i should do that
<mvo> VoX: if you dist-upgrade, please remove firefox-dev first, it's known to not upgrade cleanly curretnly (it's being worked on currently)
<zyga> mvo: good morning
<VoX> mvo: i dont use ff, so it shouldnt be an issue :)
<mvo> hello zyga
<mvo> VoX: :)
<pitti> hey zyga, how's it going?
<pitti> Keybuk: l-wlan-ng with the rmdir uploaded
<mdz> doko: python-soappy and vim both have problems
<mdz> python-soappy has a file conflict, vim depends on a universe package
<zyga> pitti: fine, I need to finish that last patch and send it to you finally :-)
<pitti> yay
<mvo> zyga: anything new from the cmd-not-found stuff :) ?
<zyga> mvo: not yet, sorry :/
<mvo> zyga: no problem :) 
<zyga> mvo: I've opened up an old project of mine... gadu-gadu.suxx.pl :-)
<mvo> zyga: you should get a new domain ;)
<mvo> zyga: ah, I remember this one
<zyga> mvo: yes i know ... :/
<\sh> zyga: what's wrong with gadu-gadu, despite the fact, that it is a IM system local to poland or for polish people? 
<zyga> \sh: ah many many things
<Treenaks> \sh: it's not XMPP ;)
<zyga> \sh: to outline the key facts
<zyga> \sh: it's based on internet explorer to RUN :-)
<zyga> \sh: it has tons of problems, crashes, hangs, eats CPU
<\sh> zyga: hmmm...tell your friendly jabber server admin to install a gadu-gadu transport :)
<\sh> Treenaks: lol yes :) 
<zyga> \sh: there are lots of those but many people coming to ubuntu and linux in general want a 'gadu gadu client'
<zyga> I don't want to start with jabber all the time :)
<Treenaks> zyga: there's 'gaim' and 'ekg', according to apt-cache search :)
<Treenaks> oh and tleenx2
<zyga> \sh: oh and it also displays animated flash (with sound) ads on any dialog (including configuration and chat)
<\sh> zyga: well, it's the best way to force jabber into the heads of people :)
<Treenaks> zyga: wow, and I thought this country's MSN Messenger addiction was bad
<zyga> Treenaks: gaim has very poor gg support due to libgg being written in polish and having some incompatibilities (license?)
<zyga> Treenaks: tlen is another protocol
<zyga> Treenaks: ekg is command line and no longer developed, there is unpackaged ekg2 though
<zyga> Treenaks: also... all of those clients are OVERCOMPLICATED
<zyga> each aims at multiprotocol support
<zyga> jabber, irc and a bunch of others
<zyga> most C/C++ based clients just crash regularly 
<zyga> the only exception thus far is egk familiy 
<Treenaks> zyga: get people to migrate to jabber then ;)
<zyga> but they don't plan to support UTF-8 any time soon and are console based
<zyga> Treenaks: impossible
<zyga> Treenaks: everyone < 20 in this country has a gg account 
<zyga> Treenaks: I tried to convert my friends but jabber  was too complex for each one of them
<zyga> so ... as simple pygtk gg client that looks similar to the original and does not crash is a perfect solution
<zyga> today the core runs on os X, win xp (didn't try anything else) and obviously any linux 
<zyga> after the core I plan to add pygtk gui and release for my friends to test :)
<Treenaks> jabber complex?
<Treenaks> all you need is something that looks like an email address, and \sh ;)
<zyga> Treenaks: yes, the concept of multiple protocols, transports... really not for most of my non-tech friends :/
<Treenaks> zyga: you don't want to explain that ;)
<Treenaks> zyga: you just tell them 'use google talk'
<Treenaks> zyga: no multi-protocol mess
<zyga> Treenaks: note all of them are windows users or windows converts that are still very uneasy 
<zyga> Treenaks: no :-)
<zyga> Treenaks: the KEY feature is gg compatibility
<Treenaks> oh
<zyga> Treenaks: no-one wants anything but to talk with their gg friends
<Treenaks> then you'll probably need to hack gaim/libgg
<zyga> Treenaks: libgg is written in C and I hardly like the looks of that
<zyga> Treenaks: gaim is again complex (devel wise) and multiprotocol
<Treenaks> zyga: can't you extract protocol docs out of it?
<zyga> I was thinking about using gaijm as GUI base
<Treenaks> so people can implement it sanely to your spec?
<zyga> Treenaks: no need, the protocol is well documented and I've got that part already
<mdke> jbailey, around?
<zyga> Treenaks: python is so much easier to code than C
<Treenaks> zyga: I know
<zyga> Treenaks: I had most of the protocol after two days...
<zyga> now I need to clean up the mess and build a nice event loop that can be frozen api wise
<mdke> or anyone who knows sed and is willing to do me a quick favour?
<Treenaks> mdke: that depends on the favour ;)
<zyga> I've found two other projects that wanted a pygadu IM client, one in beta (only library) and other still planning with no code
<zyga> I might get those people to join forces :)
<Treenaks> zyga: :)
<zyga> mdke: how big favour?
<mdke> Treenaks, it's quick. I need a line in a script which uses sed to do something relatively simple
<Treenaks> what then?
<mdke> ok, check out https://docteam.ubuntu.com/repos/trunk/ubuntu/desktopguide/translate.sh
<mdke> check out, as in look at, sorry
<Treenaks> OK :)
<Treenaks> and then?
<zyga> sed has this feature of +w-r
<zyga> mdke: what was the intention of that sed line?
<mdke> zyga, to change the name of a file.
<mdke> I need another line
<mdke> which delves into the content of ${y}, and changes "C/" to "${y}/"
<mdke> argh
<mdke> the content of ${y}/mk, sorry
<zyga> mdke: huh 'C/' into what? to "${y}/mk" ?
<Kinnison> Umm, where is 'y' coming from?
<jbailey> mdke: Yes.
<mdke> Kinnison, from up the top
<mdke> jbailey, hi :)
<Treenaks> Kinnison: y=$(basename ${x} .po)
<zyga> mdke: sed -e "s/C\//$y\/mk/" ?
<mdke> jbailey, did you see the recent scrollback?
<zyga> mdke: btw, use sed -i ... :-)
<jbailey> mdke: I haven't.
<zyga> ah no ... sorry :-)
<zyga> not in this case
<jbailey> mdke: Been plotting to get infinity drunk.
<Kinnison> mdke: sed -i "s@C/@$y/@g" $y/mk
<Kinnison> mdke: ?
<Kinnison> erm -i -e even
<Kinnison> mdke: sed -i -e "s@C/@$y/@g" $y/mk
<mdke> Kinnison, I don't know, because I don't understand sed :/
<Kinnison> so make a copy of one of the mk files and try it
<mdke> Kinnison, ok great, I'll try that.
<Kinnison> don't be scared
<zyga> mdke: just rewrite that mess in python - at least you won't have to remeber why it works this awy
<zyga> really
<jbailey> Kinnison: @ as a delimiter hurts my brain.
<zyga> lol
<jsgotangco> that line hurt my brain even more just looking at it
<MrFaber> hi all
<mdke> i'm gonna go with jbailey, because he wrote it in the first place
<jbailey> I did?
<MrFaber> Is there a reason why kmymoney has noch HBCI-support like debian?
<mdke> yeah
<jsgotangco> lol
<Kinnison> jbailey: what do you tend to use instead?
<jbailey> Kinnison: #
<jbailey> Big and blocky, looks like a wall to me.
<Kinnison> heh, always makes me think of comments
* Kinnison sometimes uses ! or ,
<Kinnison> so s,thing/foo,thing/bar,g
<jbailey> i've seen ,
<jbailey> ! might suck for working in bash
<mdke> looks like Kinnison's line works nicely
<Kinnison> do I win a prize?
* mdke thinks
* Keybuk wonders whether you can use unicode characters
<jbailey> Keybuk: Like multibyte?
<jbailey> I think it's unlikely.
<mdke> thanks Kinnison 
<Kinnison> mdke: you are very welcome
* zyga wonders if the separator can be a multibyte sequence
<zyga> nope :)
<Keybuk> AS I WAS SAYING
<Keybuk> syndicate scott% echo "foo" | sed -e "sfoobar"
<Keybuk> sed: -e expression #1, char 15:unknown option to `s'
<Keybuk> :-(
<zyga> rest in pieces sed ;] 
<zyga> k
* zyga goes back to studying math
<zyga> have a nice weekend guys
<dholbach> Keybuk: looks like your "/" is broken
<Keybuk> dholbach: it's an Egyptian Ankh
<dholbach> Keybuk: hmmm, seem to be lacking the proper font package then
<JaneW> Keybuk: Ankh Morpork?
<Mithrandir> no, it's not that solid
<JaneW> heh
<pitti> infinity, fabbione: #$#$&#(&#(* ssl cert - the postmaster process does not run in auxiliary groups
<pitti> so it can't read the cert
<fabbione> meh
<fabbione> we can't put the key 644
<fabbione> sorry
<fabbione> did you also change the dir attrs?
<pitti> obviously :)
<pitti> of course
<fabbione> ok
<fabbione> just making sure
<pitti> I can read it in sudo -i postgres just fine
<pitti> erm, -u postgres -i of course
<pitti> ... but I should be able to fix that
* pitti curses at Perl for not having initgroups()
<Diziet> How annoying.
<Mithrandir> why is that annoying?
<pitti> Mithrandir: because it's tiresome to implement it in Perl on my own?
<StevenK> pitti: Search CPAN?
<pitti> StevenK: yes, sure, but I mean, Perl should just have it
* Keybuk reports pitti to the management
<StevenK> Heh
<StevenK> pitti: If initgroups() is POSIX, surely Perl's POSIX module should include it?
<Mithrandir> StevenK: it's not posix
<mjg59> pitti_: http://bugme.osdl.org/show_bug.cgi?id=5528 - /sys/power/state + mem isn't expected to work on PPC right now
<mjg59> So we'll need something to do the ioctl
<StevenK> Mithrandir: Awww.
<pitti> mjg59: boggle, I wonder how pbbuttonsd does it then - it just calls the shell scripts
<mjg59> pitti: ioctl (base->fd_pmu, PMU_IOC_SLEEP, 0);
<pitti> mjg59: ah, I see; thanks
<pitti> mjg59: well, that should be easy to replicate in perl
<mjg59> pitti: So we could just add something to do that in p-m-i
<Diziet> IIRC POSIX doesn't mandate support for the extended groups list.  And even SuSv3 doesn't offer setgroups.
<jono> hi all
<jono> is xgl planned for dapper?
<mjg59> pitti: If you could play with that at some point, that would be great - if that ioctl makes things pretty much work, then we can stuff it all under hal
<mjg59> jono: It'll probably be in there, but it certainly won't be the default
<jono> mjg59, right
<pitti> mjg59: yes, I will
<mjg59> jono: Unless you're using binary nvidia or ati drivers, its usefulness is currently limited (no Xv, no accelerated 3D)
<pitti> mjg59: so pmi would then just use dbus-send, I assume
<jono> I am just wondering if all the snazzy 3D stuff will be there, as Novell may eat out lunch
<mjg59> pitti: No, hal calls pmi
<pitti> mjg59: ah, right, I keep forgetting
<pitti> mjg59: yes, I'll do that with some perl -e magic then
<mjg59> jono: The glxcompmgr we have is pretty snazzy
<mjg59> Dave Airlie has been playing with it, and demoed it at LCA
<jono> mjg59, is that in dapper?
<mjg59> (On top of the free ATI drivers)
<mjg59> jono: Not as yet
<mjg59> jono: Not much point without Xgl :)
<jono> np
<jono> right off to have some breakfast
<jono> later al
<jono> all
<Keybuk> mmm.... Bacon
<Keybuk> http://www.refreshedmedia.com/tony-robbins/unleash-the-power-within/london-2005/tony-robbins-unleash-the-power-within-london-2005-tickets.shtml
<Keybuk> I guess it's that, a year on
<mjg59> "Tony Robbins really understands NLP (Neuro Linguistic Programming) "
<Keybuk> NLP is fun
<Keybuk> how to make a happy-go-lucky person break down and cry in just 10 seconds
<Keybuk> my teacher once said I was naturally gifted <g>
<dholbach> a talent to be proud of...
<Diziet> http://en.wikipedia.org/wiki/Neurolinguistic_programming, locked due to edit war (!)
<Keybuk> dholbach: first rule of being a therapist, you can charge more if people always cry when the visit
<Diziet> Seems to have some NPOV problems.
<StevenK> Keybuk: I think you're in the wrong industry.
<dholbach> Keybuk: seems you overtook them all.
* StevenK suggests "Therapist Consultant".
<Keybuk> StevenK: heh, I actually studied Psychology and stuff first; and even trained as a Curative Hypnotherapist and stuff
<Keybuk> "and stuff"
<Mithrandir> lots of stuffing, I see.
<StevenK> Heh.
* dholbach was just about to underline 'stuff'
<StevenK> Muahaha
<Keybuk> programming minds is kinda interesting to learn if you like programming computers ;)
<StevenK> Keybuk: I so don't want to know what an ICE causes.
<dholbach> "programming minds" - YUCK!
<Mithrandir> and you thought debugging GNOME was bad.
<StevenK> Heh
<Keybuk> GNOME doesn't break down and CRY when you get things wrong
<Keybuk> ...GNOME developers on the other hand... <g>
<HiddenWolf> hm
<StevenK> Keybuk: I was just thinking that. :-)
<Mithrandir> sure it does.  It's called segfaulting. :-)
* dholbach shakes head in disbelief... what a conversation
* StevenK patches zsh to print "I'm going to cry now!" and run 'for (;;)' when a child segfaults.
<StevenK> Hrm. Quod Libet can detect how long this song is, but not where it is up to.
<Keybuk> dholbach: oh, I dunno ... comes in handy at parties
<Keybuk> "make my girlfriend bark like a dog" is eternally popular
<StevenK> Isn't that more abuse than a party trick?
<dholbach> I just wondered how you could hate people so much.
<trulux> morning
<StevenK> dholbach: Duh! He has maintained dpkg!
<trulux> I'm checking the libwww stuff but seems to be broken
<Keybuk> dholbach: I don't hate people :)  I love pople
<Keybuk> uh, people
<trulux> HTInit and other components seem to be missing
<dholbach> Keybuk: aha
<Keybuk> especially the cute ones
<StevenK> Oh, nice one mplayer
<StevenK> "Unknown codec!" and then it plays fine.
<StevenK> ... who did the videoing at the Sprint?
<Keybuk> me
<StevenK> Keybuk: During your talk? :-)
<Keybuk> except, obviously, for the video with me in it
<Keybuk> fabbione did that one
* StevenK giggles.
<StevenK> Keybuk: May I suggest a tripod?
<StevenK> I'm getting seasick.
<Keybuk> StevenK: the other two shouldn't be too bouncy
<StevenK> You have steadier hands?
<Keybuk> that and I braced my arm against things mostly
<StevenK> Ah. Cheaper tripod.
<jbailey> That's our keybuk.  A perfect tripod.
<StevenK> Heh
<Keybuk> StevenK: easier to carry, I actually have a tripod at home, but couldn't be arsed to bring it
<StevenK> Heh
<StevenK> Keybuk: Evidently, its a DV camcorder?
<Keybuk> mpeg2 camcorder
<StevenK> Hrrm, nice
<Keybuk> had to convert from mpeg2/ac3 to DV so I could load it into Kino
<Keybuk> then edit in Kino to add the captions
<Keybuk> then save as DB
<Keybuk> uh, DV
<Keybuk> then recode into Theora
<StevenK> Nice, two recodes.
<Keybuk> but then it's at least downloadable
<StevenK> Awwww, it finished.
<Keybuk> the original file was 1.5GB at DVD quality
<StevenK> "The file exists. Please don't download it."
* StevenK smirks.
<Keybuk> the 31M ogg is slightly more "useful"
<trulux> undefined reference to `HTLibTerminate'
<StevenK> Keybuk: You did it all on the laptop, or threw it to a machine at home?
<Keybuk> StevenK: all on laptop
<StevenK> Ow.
<Keybuk> camera just appears as USB storage
<StevenK> Keybuk: I was more thinking brute CPU power for the recoding.
<Keybuk> infinity: http://10.66.66.154/~scott/sysvinit_2.86.ds1-6ubuntu9_i386.deb
<Keybuk> StevenK: bah, wasn't much
<Keybuk> not noticeable anyway
* StevenK glares at the mplayer build failure.
<infinity> Keybuk: sysv-rc.deb might be more helpful. :)
<Keybuk> woo
<Keybuk> is it not alongside? ;)
<infinity> Indeed it is.
<StevenK> infinity: Reading is a good skill. :-P
<infinity> (had to s/i386/all/, yay confusion)
<StevenK> Keybuk: Your talk seems to finish somewhat abruptly.
<Keybuk> StevenK: battery
<StevenK> Awww.
<Keybuk> . o O { and I had to copy it alongside ... but if I don't tell him that, he won't know :p }
<StevenK> Hah
* StevenK watches pbuilder install 133Mb of Build-Depends.
<StevenK> This machine needs a faster hard disk.
<Treenaks> StevenK: or internal memory > hard disk ;)
<StevenK> Actually, this machine was bought yesterday. The RAM and CPU are fast. The hard drive is a throw back.
<StevenK> snow.c:3680: warning: assignment from incompatible pointer type
* StevenK sighs at mplayer's developers.
<fabbione> StevenK: is that on amd64?
<StevenK> Sort of.
<StevenK> The machine is an amd64, it's being built in an i386 chroot.
* _mvo_ goes to lunch
<StevenK> Oh blah, so now it fails somewhere else entirely.
<siretart> StevenK: mplayer ftbfs? huh?
<StevenK> I'm building it locally.
<siretart> StevenK: I have prepared a new mplayer upload in the motumedia svn, for enabling libaa and libcaca support
<siretart> ah, okay
* siretart wonders if uploads are allowed again
<fabbione> not yet
<StevenK> So katie will be no more?
<fabbione> StevenK: she is dieing
<StevenK> fabbione: 'dying'
* StevenK mourns for the first taste of Python he had.
<fabbione> yeah whatever
<Diziet> Ceasing to be, not immersing things in chemicals to change their colour.
<StevenK> Diziet: Yes.
<StevenK> Damn mplayer. It can't link due to undefined references, but the library exists and is being linked in.
<Kamion_> StevenK: katie will still be processing security uploads to warty/hoary/breezy
<StevenK> Ah
* StevenK is still wondering if Warty is going to stay on archive.u.c when Dapper gets released.
<Diziet> Surely seeing `My First <insert programming language> Program' taken out of service can only give a sense of relief ?
<StevenK> Diziet: I certainly didn't write katie - it was just the first Python I seriously read.
<Diziet> Ahhh.
<fabbione> StevenK: i think it will move to something like old-releases.ubuntu.com or just to /dev/null
<StevenK> Ahh
<\sh> uh oh..the first dapper changes mail 
<jpatrick> :/
<StevenK> And it's poppler
<\sh> go pitti go ;)
<pitti> \o/
<MisterN> hi
<jpatrick> MisterN: hello
<siretart> StevenK: we have quite some patches in our mplayer fixes due to linking problems
<MisterN> somebody said he didn't see many interesting changes in dapper. i do: my printer works seemlessly and with usb now. :)
<infinity> Keybuk: Poke.
<Keybuk> infinity: use lube next time
<infinity> Keybuk: Can I get your current sysvinit sources to fiddle a bit more with?
<infinity> Or you could run over here and scare the shit out of me.
<infinity> And molest my chair.
<Keybuk> it seemed easier
<\sh> tschwall: "Tom Schwaller", former linux magazin guru and linux-community founder?
<tschwall> yes. That's right. No anonymous nick ;-)
<\sh> tschwall: long time no see...still at IBM?
<tschwall> yes. Planning a new project -> bluebuntu
<ogra> wow, a celebrity in our channel :)
<\sh> tschwall: lol...
<tschwall> lol myself ;-)
<\sh> tschwall: goobuntu...bluebuntu...how does it match with "IBM Red On Blue" (Former RedHat/IBM Campaigne in 2001)
<dsas> would anyone happen to know if ubuntu abides by the lsb filesystem hierarchy standard, or the debian one?
<\sh> ogra: linux-community was my first hands on zope :) when Tom released linux-community.de I just installed zope and wanted to help him to improve it :)
<dsas> or neither.
<Mithrandir> dsas: lsb doesn't include any file system layout, iirc.  It just refers to the FHS which both Debian and Ubuntu adhere to
<shadeofgrey> hi everybody
<shadeofgrey> ...i was just stopping by for my usual 15 minute rant....
<dsas> Mithrandir: oh, ok I've just glanced over the lsb FHS and it doesn't really specify anything except /etc and a couple of others anyway. 
<shadeofgrey> ...and i must say that, with dapper, you guys have really outdone yourselves
<Keybuk> dsas: if you have a specific question, we could probably answer it
<Keybuk> the FHS is quite detailed
<shadeofgrey> the gui is finally starting to look polished and professional
<shadeofgrey> and the updated versions of all the basic software were very welcome
<shadeofgrey> though i must confess that getting DVD playback to work has proven to be quite a bitch and ahalf
<shadeofgrey> i cant get dvd playback to work with totem, kaffeine, vlc, or xine
<Mithrandir> shadeofgrey: https://wiki.ubuntu.com/RestrictedFormats#head-cd84b8e23927ccdb4bb55ffd3074687abec0cf3b should explain it
<tschwall> What's up with the ppc64 port? I installed Debian Sarge and updatet it to Ubuntu on an OpenPower p720 as a starting point for Bluebuntu, i.e. Ubuntu running perfectly on POWER machines + specialized installer + some IBM packages, etc. Intention: proof of concept what is possible in addition to SLES and RHAS which are the only supported versions rigt now. A lot of devel work..
<dsas> Keybuk: I was just confirming that this isn't completly true "/media - mounted (loaded) removable media such as CDs, digital cameras, etc.." 
<Keybuk> dsas: "Purpose
<Keybuk> This directory contains subdirectories which are used as mount points for removeable media such as floppy disks, cdroms and zip disks."
<Keybuk> which is how we use it ... /media/$VOLUME_LABEL /media/cdrom /media/usbdisk etc.
<Mithrandir> tschwall: 64 bit userspace for ppc doesn't really make much sense in the general case.
<irvin> is the seven floppy directories under /media intentional?
<dsas> Keybuk: So is there a "official" location for mounting other hard drive partitions
<dsas> irvin: no there's a bug filed about there.
<Keybuk> dsas: wherever you want
<dsas> *that
<Mithrandir> irvin: bug in the installer somewhere, it's known about, yes.
<Keybuk> dsas: UNIXishness says you mount one drive as /usr one as /var one as / one as /home
<Keybuk> most machines I've seen use something like just /sdb1 /sdc1 and symlink into them
<Keybuk> but it's up to you
<tschwall> Mithrandir: that's right, but the kernel needs a lot of love nevertheless ;-)
<dsas> Keybuk: I think ubuntu mounted other hd partition in /media unless I specifically gave it a different mount point.
<shadeofgrey> mith:  i have libdvdread3 installed...  do i really need w32codecs?  if so where do i get iut because the link on the wiki leads to nowheresville
<Keybuk> dsas: we only mount removable drives automatically
<dsas> Keybuk: But I'm not sure whether that's something I did post install myself.
<Keybuk> dsas: so yes, that's particually true ... but also consistent with the FHS
<slomo> shadeofgrey: you need libdvdcss
<\sh> shadeofgrey: no question for ubuntu-devel here..please go to #ubuntu
<Keybuk> we don't automatically mount (e.g.) a new drive on your IDE or SCSI bus
<Mithrandir> shadeofgrey: w32codecs shouldn't be needed for dvd playback, no.
<Keybuk> but we do automatically mount one plugged in via USB, IEEE1394, PCMCIA, etc.
<dsas> Keybuk: Ahh, ok. Wasn't sure whether that was something I'd done and forgot about, or Ubuntu'd done (and in which case the docs needed updating)
<dsas> Keybuk: thanks.
<Mithrandir> tschwall: true dat.
<tschwall> Who's tweaking the ppc64 kernel here (i.e. Ubuntu)?
<Mithrandir> tschwall: BenC is our kernel guy
<tschwall> OK, the usual suspects ;-
<BenC> tschwall: what sort of kernel problems are you having?
<BenC> we don't really have a non-powermac ppc64 kernel right now
<BenC> but I'd be glad to have one if it gets tested
<tschwall> Right no I am using the Gonicus kernels which are fine but need to be updated. 
<BenC> If you can take our kernel package (linux-source-2.6.15) and add a config that works for your system, I'd be happy to include it
<tschwall> I asked Gaius P to help me here, since he's done that. Thanks! 
<BenC> you could probably start with the powermac64 one (cat debian/config/powerpc/config{,.powerpc64-smp} > .config) and go from there
<BenC> note, we are using the prefered ARCH=powerpc (as opposed to the old ARCH=ppc64)
<tschwall> ok
<ogra> mdz, ping
<mdz> ogra: PONG
<ogra> seems gnome-power-manager is accepted for official gnome inclusion ... so do i assume right that the same freeze exceptions as for gnome apply ? 
<seb128> it is, that's new
<seb128> where did you read that?
<ogra> seb128, the version switched to 2.13.5
<ogra> (from 0.3.4)
<seb128> that doesn't mean it's accepted
<ogra> didnt read an announcement yet 
<seb128> that just means upstream use the same versionning
<ogra> but its in preparation for inclusion afaik
<seb128> they would like to be shipped with the desktop
<ogra> i just want to know if the same exceptions will apply ..
<seb128> doesn't means that's going to be done that cycle
<HWolf> BenC: ping
<BenC> HWolf: pong
<HWolf> BenC: when can I expect a new kernel uploaded?
<BenC> hopefully soon, I had to backout a huge acpi update that caused really bad breakage
<tschwall> BenC: regarding ppc versus ppc64. What exactly is in e.g. http://mirror.cs.umn.edu/ubuntu/dists/dapper/main/installer-powerpc/current/images/powerpc64. I expect network bootable images there.
<HWolf> BenC: I'm hoping to see if my bttv sound will work again. That's why I ask.
<pitti> BenC: btw, will ppc sound be fixed in the next upload (I heard rumors that it will be)? or do you need some debugging for that?
<ogra> BenC, with working ppc sound ? 
<ogra> LOL
<HWolf> poor BenC :)
<tseng> hi ogra 
<ogra> (and with a better bcm43xx driver that doesnt hardlock my ibook ? )
<Keybuk> I can't see "bttv" without thinking "bitty"
<HWolf> Keybuk: heh. 
<HWolf> There are some good movies on tv next week. and my only "tv" is ubuntu. ;)
<fabbione> stop hammering benc or you will all phear my next X upload
<fabbione> MUHA MUHA MUHA
<ogra> pfft
<BenC> pitti: should be fixed
<tseng> fabbione: #ifdef PPC_BOMB?
<fabbione> tseng: nah... foreach(&annoying_lusers) { bomb(); }
<ogra> tseng, hey
* HWolf looks at fabbione with innocent puppyeyes
<HWolf> wow, nld video's look good.
<tseng> if you are into that Yet Another Wobbly Window Demo scene
<HWolf> tseng: well, yeah, there's that
<HWolf> but if they put it to market, that's new.
* Diziet makes firefox-1.5.dfsg+1.5.0.1.orig.tar.gz :-/.
* desrt fears
<desrt> why does 'dfsg' appear in the firefox package name?
<Diziet> If I'm not careful that version number is going to have bits break off.
<slomo> Diziet: why no firefox-1.5.0.1.dfsg?
<Keybuk> .dfsg.but.not.really
<Diziet> slomo: Unhelpful choice of numbering of earlier 1.5's.
<desrt> Keybuk; as in, problems with the trademark thing?
<Keybuk> .dfsg.but.not.really.no.we.really.mean.it.this.time
<hunger> What is the source package for this gnome-power-manager thing?
<hunger> Ah, just mistyped it;-)
<sebest_> hello anyone using dapper/network-manager/ipw2100 ?
<mjg59> sebest_: Yes
<MisterN> n8
* lamont wanders in
<Drac[Server] > Hiya. The Ubuntu Breezy installer doesn't see my ISA ethernet card. Is there anything I can do?
<sladen> Riddell: pointing https://wiki.kubuntu.org at wiki.ubuntu.com means there's a Certificate mismatch.  Can you get elmo to give you another IP instead...
<sladen> actually it's probably a generally bad idea as Google will penalise the duplicated content
<sladen> an inprovement might be to let them select the style/stylesheet by a cookie
<sladen> eg.  set a cookie when they visit www.kubuntu.org for  *.kubuntu.org  and have that serve the appropriate funkage
* Mez waves at sladen
<Mez> sladen: that wouldnt work though - as wiki.ubuntu.com wouldnt be able to read *.kubuntu.org cookies
<sladen> Mez: that is a very good point.  One that would be solved by inverting the problem ;-)
#ubuntu-devel 2006-02-10
<Mez> lol
<sladen> iBalo: wasabi 
<sladen> gah
<sladen> iBalo: sorry, completion
<sladen> iwj: you could make your firefox retection thing do a forced immediate  sudo mount -o remount,ro /  
<BenC> anyone know of a good decompiler?
<floam> did old bugzilla bugs get moved to malone?
<floam> http://bugzilla.ubuntu.com/show_bug.cgi?id=21515 won't let me comment on it, but I can't figure out if it's been moved somewhere or if I need to recreate it.
<Ubugtu> ubuntu bug 21515 in linux "sata_via: ATAPI not working" [Normal,Needinfo]  
<BenC> floam: top of the bugzilla page should have a link to the malone bug
<floam> oh, I'm blind, thanks
<floam> it's even in a big blue contrasting box
<floam> perhaps that just got added in the last few days. I know I tried to get there a week ago and was looking all over
<BenC> been there since the conversion :)
<floam> guh.
<floam> Guess I'm retarded :)
<floam> BenC: oh, that's the same bug you were helping me with. any idea if newer libata stuff could get backported back at this (late-ish) point?
<floam> I managed to get it working with a 2.6.16 rc
<BenC> 2.6.16 contains a lot of pata stuff that likely wont get backported
<BenC> but you can try taking sata_via.c and compiling it with our kernel...if it works, I might do it
<floam> I can try that. There were numerous other ATAPI fixes/changes that were outside sata_via, don't know where it was fixed there
<floam> s/where/if/
<mjg59> BenC: You reverted the ACPI stuff?
<BenC> mjg59: I couldn't even boot with it
<mjg59> BenC: Heh. I'll try taking a look.
<BenC> usb didn't even work
<mjg59> Sounds like interrupts had gone
<BenC> so I couldn't debug it at all
<BenC> yeah, pretty much
<mjg59> pci=noacpi would probably have got you booted
<BenC> ide worked, but net+usb+scsi was done
<BenC> I didn't even think to try, it was just scary :)
<humboldt> The nomenclatur of Release files seems to have changed in breezy. apt-show-versions does not seem to accommodate these changes nor does apt_preferences! This leeds to a wayor mess!
<sladen> Firefox just crashed ...when filing a bug on the Mozilla Bugzilla.  How annoyingly typical.
<OddAbe19> is there a bug with nvidia and glx, i can't get my glx to work no matter how many times i've reinstalled nvidia driver... i looked on bugzilla, couldn't find anything
<Chipzz> first of all, this is not the place for end-user questions
<OddAbe19> i know that
<OddAbe19> but you deal with bugs
<Chipzz> then why do you ask?
<Chipzz> anyway
<OddAbe19> i couldn't find a bug on bugzilla about it
<Chipzz> did you use the ubuntu packages?
<OddAbe19> so i thought i'd ask since it wasn't busy
<OddAbe19> no, the binary
<Chipzz> see
<OddAbe19> the package is broken right now
<Chipzz> that's where your problem is
<Chipzz> ok... so let me get this straight... you do not use the package and then come in here asking if there is a bug in the package? :)
<OddAbe19> actually, in all honesty, i've never had a problem with the binary, only the provided packages, so i stuck to the binary.  Modulization seemed to have broken it and i was just wondering if it was a common problem
<OddAbe19> i wasnt sure if it was an X problem or not
<OddAbe19> that's all i wanted to know
<Chipzz> afaik (but I'm not a developer, and my laptop running dapper with the nvidia card hasn't been updated in a week or something), everything works just fine
<OddAbe19> ok, then it's me
<OddAbe19> i'll dig deeper, thanks
<Chipzz> but you should be asking on #ubuntu, really
<Chipzz> and you should be using packages, *REALLY*
<Chipzz> and if those are not working for you like you claim, file a bug ;)
<zakame> hi devs :)
<phlaegel> Chipzz: still around?
<LeonWP> hi
<LeonWP> does anyone know why there is only a ppc version of this release?
<LeonWP> http://cdimage.ubuntu.com/daily-live/current/
<zyga> anyone who knows the initrd magic of ubuntu around?
<\sh> hmmm
<\sh> does anybody see a strange behaviour of his clock applet after latest libc6 update?
<\sh> in kde it shows UTC, but system time is localtime (in my case CET)
<\sh> I didn't check gnome..that's why I'm asking :)
<zyga> checking
<zyga> I've got correct local time
<\sh> strange...
<\sh> because I get this every time I restart kicker (kde panel) and/or restarting the clock applet:
<\sh> grep: /usr/share/lib/zoneinfo: No such file or directory
<\sh> grep: /src/*: No such file or directory
<\sh> /bin/bash: /bin/awk: No such file or directory
<\sh> and there is no reference of this in the source 
<zyga> maybe it's specific to kde?
<zyga> is that a glibc message?
<\sh> zyga: i'll check
<\sh> but there must be a system/exec call to grep somehow..
<\sh> and I don't think that glibc is executing grep :)
<lsuactiafner> wget http://za.archive.ubuntu.com/ubuntu/pool/main/l/ladspa-sdk/ladspa-sdk_1.1-2build1_i386.deb http://za.archive.ubuntu.com/ubuntu/pool/multiverse/e/em8300/em8300-headers_0.14.0-2_all.deb http://za.archive.ubuntu.com/ubuntu/pool/main/libx/libxmu/libxmu-headers_6.2.3-5_all.deb <-- those packages are *BROKEN*
<lsuactiafner> currupted or something. headers and md5 checksum doesnt work. i did wget and tried dpkg -i and still no luck
<lsuactiafner> right i got dpkg -i to work but apt-get doesnt like them. 
<sebest> mjg59, hello, any plan to support SD / MMC card reader in notebooks?
<sebest> i tested http://mmc.drzeus.cx/wiki/Linux/Drivers/wbsd and it works well and support many laptops
<mjg59> sebest: It's in the Dapper kernel
<sebest> already?
<mjg59> Yes
<mjg59> (Since it's in the upstream kernel)
<Treenaks> any idea when the new kernel build will hit dapper (with the fixed parts of that driver, and some other goodies) ?
<mjg59> Treenaks: You'd have to ask Ben
<HiddenWolf> mako: rofl, great blog entry 
<sebest> is ther any reason that "SHMConfig" is not set to True for synaptics drivers.
<Treenaks> sebest: security
<sebest> Treenaks, security? you mean on multi user systems?
<sebest> it seems that the synaptics configuration tools needs it to work (qsynaptics, synclient, etc)
<Treenaks> sebest: Sure, but the current method (shm) is insecure, and a better way should be found.
<sebest> with ksynaptics you can configure your touchpad to (for example) middle-click when you tap it with 2 fingers
<mdke> Mithrandir, *poke* *poke*
<Simira> mdke: he's on his way home :D
<mdke> Simira, ah thanks
<Simira> did someone break gnome terminal?
<Treenaks> Simira: I think so.
<Treenaks> Simira: I've heard keybuk complain about it, and my g-t crashed once already
<Simira> Treenaks: it doesn't crash, it just doesn't start :p
<Simira> so, it's xterm for now, then
* mdke recommends rxvt-unicode
<Simira> Treenaks: any other issues on the laptop-testing? Think all is fine on nc8230 now
<Treenaks> my ati still doesn't work
<Treenaks> And most of my other bugs still stand too (no working WEP in the installer, etc)
<Treenaks> The SD slot should be working after the next kernel update
<Treenaks> (not the smartcard though)
<Simira> hm, ok
* sladen wonders if there are any laptops in the house with an SD slot (I use a PCMCIA adaptor, but that's a nice simple IDE device!)
<mjg59> sladen: Is that a literal "in the house"?
<sladen> mjg59: yes.
<Simira> :-)
<Simira> sladen: in London, for a change?
<sladen> mjg59: I think there is a Toshiba Tablet---which would give me a chance to check the speffal keys
<sladen> Simira: home sweet home.  But far too warm :)
<Simira> sladen: oh, wanna switch? It's freezing and snowing here. Planning to have a weekend in Spain or something...
<mjg59> sladen: I've got a Toshiba tablet
<mjg59> There aren't any special keys
<mjg59> Oh, hang on, that's not even remotely true
<mjg59> There are, but I can't remember what I did with them
<Simira> hehe
<hunger> Where is this gnome-power-manager and the gnome-volume 
<hunger> -manager started, please?
<sivang> sladen: what are you up to on the sprint besides trying to catch the virus? :)
<sladen> sivang: sudo-hints, and then after that mvo pursuded me to spend the rest of the time focused on zsync hacking
<sladen> we need a D-Bus HUD backend and KDE/GNOME frontends to pop up pretty icons when Brightness/Volume/Wifi/Bluetooth/Wifi/Video status changes
<sladen> KDE already has kmilo
<sivang> sladen: HUD ?
<sladen> and Gnome sortof has gnome-settings-daemon  Head-Up-Display
<sivang> sladen: ah, sounds interesting. So you're helping push those specs, cool :)
<hunger> It seems both kde and gnome nowadays read /usr/share/autostart... Before only kde did IIRC. How can I configure which of the files there are started with gnome and which of them with kde?
<sivang> sladen: do you happen to know / able to explain the differences between reported size of files on the fs and the "real" sizes, as per https://wiki.ubuntu.com/HomeUserBackup , I need to calucalte sizes of home folder, to instruct a user how many CDs will he need to back them up.
<hunger> I found a mail on freedesktop.org claiming that /usr/share/autostart was supposed to be for common stuff with DE-specific start stuff being in /usr/share/gnome/autostart and /usr/share/kde/autostart (or similar). Neither of those exists in ubuntu.
<sivang> sladen: currently, I have a class that does that, but it differs from the sizes dh returns, I'll probably peopen it and use it instead.
<sladen> sivang: a 900 byte file actually takes up a whole inode (eg. 4kB)   Also spare files take up _less_ blocks than their length
<psusi> sivang, you can use du to find the real size
<psusi> sivang, though if you are backing up, you don't care about that... you just care about the apparent size
<psusi> since you will be concatenating the files into a tar right?  so the on disk blocks won't enter the picture
<psusi> sladen, also... I think you meant block, not inode
<sivang> psusi: hmm, actually, come to think of it, I am not going to tar stuff myself, going to use DAR. so this probably already takes care of that. I just want to know how I can tell how many CDs or how much actual space the user that does the backup needs.
* sivang will poke dar to see if has an option to report that
<psusi> sivang, assuming you are going to enable compression, you can't tell accuratly
<psusi> and yes... dar also concatentates the files into an archive, so the on disk blocks will have no bearing
<psusi> forget they even exist for this purpose
<sivang> so I need to calucalte this myself, e.g. disregarding disk blocks, or see if dar can give this info to me
<psusi> it can't assuming you will be enabling compression
<psusi> there is no way to know how well it will compress without compressing it
<Tm_T> http://paste.ubuntu-nl.org/8051
<psusi> btw... what makes dar a better choice than tar?
<sivang> psusi: lots :)
<sivang> psusi: check the upstream website, and play with it
<psusi> I'm looking at the web site now... I'm not seeing anything tar can't do as well... and it also seems to compress each file individually to allow faster cherry picking during restores, but that reduces your compression
<psusi> I'd prefer using fewer disks to backup than being able to cherry pick faster during restore ;)
<sivang> psusi: it also automatically supports multi volumes creation, less work for me :)
<psusi> I believe tar does as well
<sivang> it seems to take care of the core backup functionality, requireing almost no additional work. tar seems like ti would take me to handle also the meta data, which dar already accounts for.
<psusi> meta data?
<sivang> TOCIng out of 2 single first and last volumes, also support for executing user cmmands in betweeb slices etc
<sivang> I gues snot mostly meta dat a:)
<psusi> sounds like you want tar's -G option I think it was... spits out a TOC for incremental backups
* psusi shrugs.... whatever works I guess...
<sivang> psusi: won't then I need to parse this TOC? I can have dar do it for me, and just tell me which volume to insert
<sivang> psusi: what's the benefit of using tar ove dar?
<sivang> (I mean, why would you use it instead)
<psusi> none I suppose... other than it's possibly older, more mature, and better supported... but it looks like dar should work fine as well, so hey... go with whatever works
<psusi> the one difference that I would actually care about is the compression.... tar will get better compression
<sivang> I can have dar run in through bz2 though
<sivang> (the stream, that is)
<psusi> that would break the slices
<psusi> dar wants to compress the files individually, then split them up onto each disk
<sivang> ah, right they say it will only lower number of slices
<psusi> that will lead to worse compression than compressing the entire tar then splitting
<sivang> seems just as good, no?
<sivang> I see. and with tar you suggest comrpessing the whole stream,
<psusi> no... the larger your data set the better the compression.
<sivang> and then break it down to slices..
<psusi> that's how tar works... it tars all the files up then passes the output to the compressor
<psusi> aye
<sivang> that's rather important argument. thanks for bringing this up
<psusi> plus, you can use 7zip to compress the tar and get REALLY good compression ;)
<sivang> and then break up to slices?
<psusi> aye
<sivang> but then I would have ti implement the slices mechanism myself...
<sivang> or can tar do that for me AFTER it has sliced?
<psusi> I think you just pipe the output to the split utility
<sivang> okay, I will experiment with that then
* sivang notes not to forget about telling a user that he needs some room on drive to do all this compressions and archiving :)
<sladen> 7zip --fomg-optimised
<psusi> sqashfs works by concatentating the files, then compressing them in 64k blocks... I turned my 80 MB lkml Maildir into a .sqashfs the other day... it was 17 MB.... turned it into a .tar.7z and it was 8 MB
<psusi> now if your average file size is less than 64k, then it sounds like dar would get even worse compression than squashfs
<psusi> since it compresses each file, rather than fixed 64k blocks
<psusi> you shouldn't need any space on the disk
<sivang> how come? I Need a buffer to realibly store the archives before I burn them..
<psusi> you can pipe the stream to growisofs and burn it on the fly
<Amaranth> psusi: what did squashfs-lmza get you?
<psusi> Amaranth, have not tried it... I didn't have time to find and apply the patches
<sladen> Amaranth: I doubt LZMA will get you anything if you're restricting it by using 64kB blocks
<psusi> sladen, it gets you something it seems... but yea, the larger the block size, the better
<Amaranth> hmm, i think it was still as good as bz2 in that situation
<Amaranth> but decompressed faster than bz2
<psusi> ahhh
<sivang> psusi: does growisofs support CDR/CDRW as well? man page only mentions DVD
<psusi> sivang, yes
<sladen> somebody needs to separate the block-reordering from the compression so they can be stacked in a more useful fashion
<psusi> sivang, so you can write a program to manage a pipeline between tar | 7z and growisofs... when growisofs fills up the disc, prompt the user for another one and fire up another growisofs
<psusi> sladen, eh?
<sladen> psusi: bzip2 combines re-ordering and compression.  It would be useful to just have reording and then use gzip (or lzma) for compression
<psusi> and once I finish ironing out the udftools package, you will be able to directly tar to a cdrw disc mounted as a full read/write filesystem
<psusi> sladen, ahh, you mean only do the BWT, then apply lzma to that?
<sladen> psusi: yes.
<sivang> psusi: :)
<sivang> I'm actually quite keen to have archive premade on disk,
<psusi> I found some sample code once that was broken up into each step, so you could just BWT if you wanted
<psusi> sivang, why is that?
<sladen> psusi: since then you can do block reordering over the *whole* file, but still only have a 64kB block granularity for making things directly addressible
<sivang> and only then attempt write them. I belive this allows for greater recoverablility when burns are interrupted in that middle, and / or gone bad. then instead of re-comressions and doing all this work, I just retry burn the files on disk
<psusi> also... after BWT orders the data, I think ppmd would work very well on it.... and be faster than lzma
<psusi> sladen, can't do that... you have to un BWT the whole file before you can get back the original data
<psusi> sladen, I believe that's what 'rz' does... 
<psusi> sivang, true... but requires more space on disk all the time for better handling of an exceptional condition
<psusi> I'd rather have the backup go faster and not require lots of free disk space normally, and in the unlikely event of interruption or bad media or whatever, have to start over
<sladen> psusi: rzip was what I was looking for, but I couldn't find it googling
<psusi> sladen, I messed with it for a bit... it's slower and doesn't compress as well as lzma and it can't pipeline, it can only work with on disk files
<mako> Hirion: clag you liked it :)
<mako> Hirion: ok.. screwed that one up.. ignore
<sivang> psusi: from the very simpletone user POV, I think this exception can occur more then once :)
<sladen> psusi: ah, but for downloading debs, that's perfectly fine
<psusi> sladen, yea, I suppose it wouldn't be that big of a deal... if it actually got better compression and wasn't so slow ;)
<sladen> psusi: I'm interested in algorithms, not implementations
<psusi> I wonder about BWT | ppmd.... could be interesting...
* sivang is away, be back later
<MisterN> hi
<ManuelJ> a question why when i try to install the nvidia drivers with "nvidia-glx-config enable" i get this mistake. "Error: /etc/X11/xorg.conf or /var/lib/xfree86/xorg.conf.md5sum are missing from your system. Please be sure that your xserver package is installed correctly."
<mdke> Kamion, siretart is uploading another ubuntu-docs for breezy-updates, I've send you and mdz an email with explanation
<Kamion> mdke: acknowledged
<Kamion> haven't caught up on e-mail yet although I noticed yours
<mdke> Kamion, no problem, i only sent it 5 minutes ago
<Kamion> ManuelJ: sounds like a bug that should be filed; it's /var/lib/x11/xorg.conf.md5sum nowadays
<ManuelJ> ok thanks
<siretart> uploading right now, sorry for delay
<ManuelJ> do i fill the bug on malone?
<ManuelJ> or what can i do?
<Alinux> hello
<Alinux> some ttf package mantainer for Ubuntu or Debian on the channel?
<Alinux> mjg59, here brother?
<Alinux> I need your help
<Alinux> :(
<mjg59> Alinux: Hi
<Alinux> mjg59, hi
<Alinux> mjg59, do you remmeber me ?
<mjg59> Alinux: Yup
<Alinux> we have talked about georgian fonts in the main
<mjg59> Yup
<Alinux> ;) BPG is agree to make his fonts GPLed
<mjg59> Alinux: Cool!
<Alinux> for georgian localisation in Ubuntu and Debian...
<mjg59> Alinux: In that case, we'll certainly be able to package them
<Alinux> I'l give you link ok?
<mjg59> Alinux: Sure
<Alinux> http://bpg.sytes.net/BPG-InfoTech/sppro/bpg/publication_view.asp?iabspos=1&vjob=vdocid,146405
<Alinux> here
<Alinux> mjg59, this person is 50 years old..
<Alinux> and he was in a dark :) he don't knew about GPL 
<mjg59> Alinux: That looks great
<Alinux> and he was very enthusiast to pubblic them under GPL license
<Alinux> he is very proud , and we too :)
<Alinux> sd-tux, well done brother! :)
<sd-tux> :)
<sd-tux> will this font go in some kind "misc font collection" or will it get it's own deb package ?
<Alinux> mjg59, I can tell you a my personal installation procedure...
<mjg59> sd-tux: There's three of them, so probably a ttf-georgian-fonts package
<sd-tux> mjg59: ok .. if you want i can try to package them
<Alinux> I create /usr/share/fonts/truetype/ttf-geo-fonts directory and then run fc-cache
<Alinux> and restart X
<mjg59> sd-tux: I can upload them now, if you like
<Alinux> mjg59, 
<Alinux> who makes a .deb package ? :D
<Alinux> mjg59, you or sd-tux ?
<sd-tux> mjg59: it would be great.. i don't have experience in packagind ... dependencies etc..
<Alinux> :)
<siretart> gnarf, connection died
<Alinux> mjg59, georgian fonts must be linked with georgian packages
<Alinux> language-pack-gnome-ka - GNOME translation updates for language Georgian
<Alinux> language-pack-gnome-ka-base - GNOME translations for language Georgian
<Alinux> language-pack-ka - translation updates for language Georgian
<Alinux> language-pack-ka-base - translations for language Georgian
<Alinux> language-support-ka - metapackage for Georgian language support
<Alinux> I mean this packages :)
<mjg59> Alinux: I'll upload the fonts. I'm not sure what the situation is with language packs - you may need to file a bug on them
<Alinux> maybe I don't know... mjg59 you have more experiance
<Alinux> so you decide...
<mjg59> I'm afraid I don't work on them
<Alinux> mjg59, no pitti works on them
<Alinux> but if you add this font to main
<Alinux> like indian , armenian...etc
<Alinux> so there will be a native support for georgian fonts
<sd-tux> mjg59: are you maintaining debian too ?
<mjg59> sd-tux: Yeah
<Alinux> gucharmap in this moment dosen't provides georgian fonts map...
<Alinux> provides but there is no fonts :)
<sd-tux> mjg59: can you put this fonts in debian too please .. in SID
<mjg59> sd-tux: Sure
<Alinux> sd-tux, I'll tell you that mjg59 is very important for us :)
<sd-tux> Alinux: ;)
<Alinux> mjg59, Georgian Brother :)
<Alinux> mjg59, thank you a lot :)
<Alinux> and GPL rulez for ever...
<Alinux> mjg59, this fonts are first GPL fonts in a georgian 24 000 years history.
<Alinux> and you have a honor to package them for Debian and Ubuntu :)
<Alinux> I'm so happy ubuntu-devel!!!
<sd-tux> Alinux: 24 000 ? fonts.... ? :) 
<Alinux> no
<Alinux> 24 00 years :D
<Alinux> 24 sencturies :)
<sd-tux> Alinux: ok .. 
<sd-tux> :)
<mjg59> Alinux: sd-tux: I've just uploaded them to Ubuntu - they'll have to go through NEW, and will end up in universe first. If you talk to pitti, he can probably let you know how to get them into main.
<Alinux> mjg59, 
<Alinux> ;)
<Alinux> thank you a lot
<mjg59> sd-tux: And in Debian now
<Alinux> ok I know pitti very well
<mjg59> No problem
<Alinux> mjg59, so he must put them into main right?
<mjg59> Alinux: Yes
<Alinux> mjg59, oook :)
<Alinux> I'll talk with him :) 
<Alinux> mjg59, I'm using dapper
<Alinux> which is the packages name?
<mjg59> ttf-bpg-georgian-fonts
<mjg59> It won't appear for a while yet - it has to be manually checked
<Alinux> mjg59, I can test them if you want...
<Alinux> I remove my fonts manually and thest a package .
<Alinux> mjg59, give me url and I'll tet them for you..
<Alinux> :)
<mjg59> Alinux: http://www.srcf.ucam.org/~mjg59/ttf-bpg-georgian-fonts_0.1_all.deb
<Alinux> mjg59, thank you I'll test them right now..
<mdke> Kamion, still wrt that email, siretart is having some trouble uploading to breezy-updates so it may not appear until that is sorted out tomorrow with the soyuz guys
<mdke> just fyi
<siretart> any idea in what launchpad group you need to be in order to be able to upload to breezy-updates?
<khermans> How do i properly request a package to be upgraded to a new version for Dapper?
<mjg59> Gah
<mjg59> Why can't I reproduce any hibernation failures?
<sladen> mmm, mute synchage
<sladen> and now to rewrite it from Python to C
<Chipzz> is it known that network interface renaming is broken?
<sivang> anybody know how to hid out stdout output of a command in python and manipulate the output?
<sivang> I'm using subprocess.Popen, but it donesn't hid the ocommand's output
<sivang> ah, think I've found it
<zyga> sivang: yes
<zyga> sivang: :-)
<sivang> zyga: yes ? :)
<zyga> sivang: I was reading your message and responded before I read the last one
<sivang> zyga: ah :)
<sivang> zyga: do you knwo fi there's a way to see the output while the command process,
<sivang> zyga: so I can do a progres based on it
<zyga> sivang: via read and write on the pipes probably
<sivang> zyga: ah right, you mean seeking isntead of readline()
<zyga> sivang: no
<zyga> sivang: you cannot seek on pipes
<zyga> sivang: just read(n)
<zyga> sivang: or maybe poll and selecgt
<sivang> zyga: read seems to work
<zyga> sivang: read is fine as long as you can block
<sivang> I will block for the progress indication, so it will show progress onlyu when there's really any
<sivang> zyga: btw, why aren't you asleep? YOu'll have trouble getting uyp tomorow, just like I will :)
<sivang> zyga: also, how to you test for the EOF of stdout?
<sivang> zyga: .next() seem to work quite nicely, I can't find poll and selectgt though
<zyga> sivang: hmm 
<zyga> sivang: you should be able to poll/select after getting the descriptor with fileno()
<zyga> sivang: I'm getting sleepy fast :)
<sivang> zyga: how those two work? like select and poll in kernel syscall?
<zyga> sivang: yes
<zyga> sivang: exactly like those
<Simira> jdub: That pony-pic on the fridge is really, really bad!
<Treenaks> Simira: why? :)
<sivang> it's so sad
* sivang cries
<zyga> fridge is broken on my firefox
<sivang> he, zyga always with some constructional critisism :)
<zyga> the menu is at the bottom of the page
<sivang> oops, for me too
<sivang> yes!
<sivang> weird
<zyga> it seems to be position:absolute instead of position:fixed
<zyga> but I'm too busy to check
* sivang is also
<Simira> Treenaks: ponies are cute
<Simira> and now the dapper update broke my time-admin as well. Ush!
<sivang> going to bed, that is
<sivang> night all!
<Simira> night
#ubuntu-devel 2006-02-11
<MisterN> n8
<drfloob> anybody active in here?  I've got a question ranging somewhere between development and support
<mikecrowe> Folks, all my images in evolution-2.5.3 are red X's.  How should I fix?
<ManuelJ> where did gconf go in dapper? :(
<poningru> can someone with the latest ubuntu firefox Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060130 Ubuntu/1.5.dfsg-4ubuntu6 Firefox/1.5 check out digg and tell me whether or not you can feel the mem hog? 
<poningru> www.digg.com
<poningru> for almost all other sites the firefox seems fine
<poningru> just under digg
<poningru> I want to say its libpng
<calc> hal seems to be broken on amd64
<calc> it hangs on startup
<johanbr> calc: Works for me.
<calc> hmm i wonder if there is any way to debug it
<calc> its stuck in a select call
<calc> hmm i see several select and poll depending on which one i attach to
<calc> and one of them "hald-addon-acpi" is stuck in read()
<calc> and the acpi one seems to be the last one started
<calc> so probably is the one actually hanging
<calc> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351296
<calc> that looks like it might be the bug
<calc> but hal-device-manager can't attach to it
<calc> malone #30254 seems like the same thing i am seeing also
<Ubugtu> malone bug 30254 in hal "Hal freezes on startup..." [Normal,Unconfirmed]  http://launchpad.net/bugs/30254
* calc bbl
<glick> excuse me, when you delete a user, does it delete all traces of him/her?
<pitti> Hey everybody
<freeflying> pitti: hi
<sivang> morning all
* sivang hugs pitti_ 
<pitti> hi sivang 
* sivang wonders why CTRL+ click doesn't work as expected in multi selections web forms, and makes curosor turn into a plus icon for moving windows around :)
<freeflying> pitti how about MainInclusion of scim now 
<jdub> sivang: because you've chosen ctrl as the default metacity modifier in the 'windows' preference dialogue?
<hunger> Hi!
<hunger> Is it possible to make g-v-m and g-p-m start only for gnome sessions?
<sivang> jdub: I've never done a selection like did, maybe it's default shipped that way :)
<jdub> the default is alt
<Treenaks> jdub: did you get my mail earlier, about mailinglist moderator stuff?
<sivang> jdub: probably my gf, she likes to play with desktop settings, I just wish she had done it on her own laptop :) but thanks muchly.
<jdub> Treenaks: hrm, don't think so
<jdub> Treenaks: oh! yes
<jdub> Treenaks: doing now
<Treenaks> sivang: this is why people invented 'multiple accounts' and the 'user switch applet' :P
<jdub> Treenaks: i'm making dennis owner - do you still want to be moderator?
<sivang> Treenaks: yeah, I'll set her up one and change my password :)
<ajmitch_> Treenaks: but then people have to actually use it :)
<Treenaks> jdub: no, make him moderator as well please
<jdub> owners get to be moderators by default - mu ha ha etc.
<pitti_> hunger: erm, what do you mean?
<sivang> Treenaks: what are you going to moderate ?
<Treenaks> sivang: I used to be moderator of the ubuntu-nl mailing list
<sivang> eh
<Treenaks> sivang: but jdub is transferring that to Seveas now
<pitti> hunger: ah, you mean that with the new autostart desktop files they are started for other DEs, too?
<hunger> pitti: They are started for kde at least.
<hunger> pitti: ... and pop up nautilus windows there and stuff.
<pitti> hunger: OnlyShowIn=GNOME; *shrug*
<pitti> hunger: iz KDE bug
<hunger> pitti: For some reason gnome seems to ignore the kde ones.
<hunger> pitti: I was afraid you'd say that:-)
<pitti> hunger: I'm not familiar about the coordination of DEs in these new autostart desktop files
<pitti> hunger: but *if* a DE supports them, it should probably adhere to the spec completely
<jdub> i don't think any of the autostart stuff is specced
<pitti> hunger: let's ask Riddell :)
<hunger> pitti: I am asking here because I read on freedesktop.org that /usr/share/autostart is for DE independent desktop files while /usr/share/ENVIRONMENT/autostart is meant for DE specific ones. But that was a mail only, no spec, so I am not sure about this.
<pitti> ah, I see
<pitti> well, I have no problem with moving it to another place
<pitti> somebody just needs to tell me the right thing to do
<hunger> pitti: Asking Riddell is a good idea:-)
<pitti> jdub: that sounds scary
<hunger> pitti: It is the impression I got as well.
<hunger> pitti: The desktop file spec contains only stuff relevant to the menu system as I understood it.
<pitti> yeah, I guess they were never meant to be used for this purpose
* Kinnison goes for breakfast
<Mithrand1r> mdke: poked
<jbailey> Do Kubuntu systems install ubuntu-minimal and ubuntu-standard?
<Mithrandir> yes
<jbailey> Tx.
<jbailey> Riddell: Ping?
<jbailey> Riddell: It seems that 30546 is assigned to kubuntu-devel@l.u.c, which is rejecting my reply to the message.
<jbailey> (And kindly notifying me of it)
<jsgotangco> wow you're still awake at this time
<jbailey> jsgotangco: I'm in the UK atm. =)
<jsgotangco> ahh
<jbailey> Otherwise 04h30 would be a little on the late side for me.
<Treenaks> jbailey: that explains a lot ;)
<jbailey> (Although it wasn't on Sat night... *g*)
<Mithrandir> bounce, bounce. :-P
<jbailey> Treenaks: The funny accent?  Yeah, I'll replace it with my other funny accent when I get home.
<jbailey> I think some of the Montral speak is starting to crawl into my day-to-day speech - I've had a couple people guess that I was from Montral on this trip.
<mdke> I thought you were from yorkshire
<Kinnison> jbailey: the day you say "bienvenue" in response to me thanking you, or you say "magasiner" when I ask where you're going, I will be forced to tickle you mercilessly until you repent
<mdke> Mithrandir, the poke was because we've had to do another ubuntu-docs package to fix a rather irritating bug (bug 30563), but no worries, siretart is handling it
<Mithrandir> mdke: 'k, coolie
* mdke stares at Ubugtu 
<jbailey> Kinnison: Like most anglos in Montral, I do refer to the convenience stores as "deps"
<jbailey> Kinnison: when I came here a few weeks ago, I had to think hard to remember what they were called.
<Mithrandir> oh, totally unrelated to the changes I did.
<Kinnison> hehe
<mdke> yes
<jbailey> mdke: Eh, really?
<mdke> jbailey, no
<jbailey> Oh good. =)
<jbailey> I'd hate to be mistaken for some pudding.
<seb128> "Paramtrage de debconf (1.4.70ubuntu1) ...
<seb128> Can't exec "locale": Aucun fichier ou rpertoire de ce type at /usr/share/perl5/Debconf/Encoding.pm line 16.
<seb128> Use of uninitialized value in scalar chomp at /usr/share/perl5/Debconf/Encoding.pm line 17.
<seb128> Use of uninitialized value in subroutine entry at /usr/share/perl5/Debconf/Encoding.pm line 65."
<seb128> I get that on dist-upgrade
<seb128> pitti, jbailey: do you know about that?
<jbailey> seb128: What version of 'locales' do you have installed?
<seb128> ii  locales        2.3.7-6        common files for locale support
<jbailey> seb128: You need a newer version that will pull in belocs-locales-bin
<seb128> jbailey: that's what dist-upgrade from this morning gives on my box
<seb128> hum
<seb128>      2.3.9 0
<seb128>         500 http://archive.ubuntu.com dapper/main Packages
<seb128>  *** 2.3.7-6 0
<seb128>         100 /var/lib/dpkg/status
<seb128> I blame update-manager
<jbailey> I haven't a clue what you just pasted.
<seb128> 2.3.9 is available
<jbailey> Right.  I should figure out why 2.3.10 isn't.
<seb128> but update-manager didn't upgrade it for me
<seb128> I got a timezone question from libc on upgrade too
<jbailey> Eh, really?
<mjg59> jbailey: Have you changed the default mkinitramfs conf at all?
<jbailey> mjg59: Adam did.  I don't maintain that anymore.
<seb128> "Running 'tzconfig' to set this system's timezone.
<seb128> Your current time zone is set to Europe/Paris
<seb128> Do you want to change that? [n] :
<seb128> "
<mjg59> jbailey: Ah. Because it stomps over RESUME=
<seb128> jbailey: that's the question I got on libc update
<mjg59> I'll bitch at Adam once he's back
<pitti> mjg59: btw, I changed pmi.pbb to use ioctls, works fine :)
<pitti> mjg59: not yet uploaded, though, since I need to do the script shuffling/handling
<Mithrandir> mjg59: I think it's potentially touched by the installer, which it shouldn't.
<mjg59> Mithrandir: It has to be touched by the installer, because there's no sane default
<jbailey> mjg59: We talked a bit about this 2 days ago - he's going to slip it into /etc/default/resume or something like that so that by default noone has to diddle the conffile at all.
<mjg59> jbailey: Cool
<jbailey> Dunno if there's a bug filed on it or not, though.  I'll look in a sec.
<jbailey> (Filing another bug atm.  *g*)
<HiddenWolf> why is it that during shutdown I see bittorrentd and rsyncd coming down on my dapper-desktop?
<mjg59> pitti: We may need newer hal for full pmu support (or, alternatively, bits need backporting)
<Lathiat> rsyncd is part of the rsync package
<HiddenWolf> Lathiat: but should it run by default?
<jbailey> Whee, I hadn't actually uploaded locales 2.3.10, done.
<jbailey> that'll fix some other bugs.
<jbailey> seb128: I think the timezone question is probably glibc getting confused because of the new locales not being there.  Would you mind filing a bug with that info in it, and the comment that the timezone settings should probably move to the locales package, rather than being handled in libc6?
<Lathiat> HiddenWolf: it doesnt unless you tell it to in /etc/default/rsync
<seb128> jbailey: ok, will do that now
<HiddenWolf> Lathiat: hm, it's off then, but I still get a shutdown message about it, which confused me. 
<Treenaks> BenC: Any idea when the new kernel packages will be out? I'd like to test the sdhci and acpi-sbs stuff :)
<jbailey> seb128: I'm headed out shortly.  Any other timezone ugliness that I need to deal with before I go?
<seb128> jbailey: nop, that's just an upgrade question, no hurry :)
<jbailey> Yeah.  I already replied to the bug as well.  I'll aim for Wednesday to fix it.
<seb128> (the GNOME clock is showing one hour shifting now though)
<jbailey> I'm really quite curious why your upgrade manager didn't opt to include that in your upgrades, though.
<jbailey> Is that a good one hour shifting or a bad one? =)
<seb128> it's saying there is still one hour before lunch where I feel it's lunch time :p
<seb128> (ie: it's UTC instead of UTC+1 which is local time)
<jbailey> Hmm.
<jbailey> I'll have a better feel for hacking this when my clock isn't set to UTC. =)
<seb128> I think it just displays the UTC time
<jbailey> I don't want to change my timezone right now, since I'm trying to make sure I leave on time. =)
<seb128> he he
<seb128> no hurry anyway, we can sort that later :)
* StevenK wonders where his windwlab upload went.
<StevenK> I got the accepted mail, but I haven't seen it hit the buildds or the archive.
<seb128> buildds are catching up now afaik
<StevenK> Then the pending list on Launchpad is wrong. :-)
<jbailey> StevenK: From how long ago?
<seb128> jbailey: my clock is fixed after upgrading locales to 2.3.9
<jbailey> Even better.
<jbailey> There will still be some breakage until you get 2.3.10 in.
<seb128> ok
<jbailey> I had forgotten to upload it, so it'll appear sometime soonish. =)
<StevenK> jbailey: It was upload last night local time, so roughly 23-24 hours ago.
<StevenK> Er, uploaded
<jbailey> ah weird.
<jbailey> No idea, then.  the stuff I uploaded on saturday afternoon has been processed and is in there.
<StevenK> Yeah, I saw that during my digging.
<seb128> I've uploaded rhythmbox on saturday and it was just building this morning
<seb128> ** (time-admin:21179): WARNING **: Could not open */usr/share/zoneinfo/zone.tab*
<seb128> ** ERROR **: Unable to load system timezone database.
<seb128> aborting...
<seb128> hum
<jbailey> seb128: Yeah, that's what 2.3.10 fixes. =)
<seb128> jbailey: ah, nice :)
<pitti> mvo: question for first prize: what's wrong in http://changelogs.ubuntu.com/changelogs/pool/main/w/wget/wget_1.10.2-1/ ? :)
<StevenK> Interestingly, wget_1.9.1-10ubuntu2.2 only have a copyright, and 1.10.2-1 has nothing.
<StevenK> Er, 1.9.1-10ubuntu2.2 and onwards
<mvo> pitti: checking
<mvo> pitti: I'm re-generating the changelogs now, I don't know what went wrong, because it seems to have happend a long time ago and the logs no longer have it :/
<pitti> mvo: ok, thank you
<Tm_T> jbailey: ping
<jbailey> Tm_T: Pong, but I'm leaves in about 5 minutes.
<Tm_T> jbailey: about https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/30546
<Ubugtu> malone bug 30546 in kdebase "kickers clock applet is screwed" [Normal,Confirmed]  
<Tm_T> jbailey: that screenie mentioned there, mine, I do have locales/unknown uptodate 2.3.9
<Tm_T> jbailey: just thought you might be interested about that small detail
<jbailey> Tm_T: I am, can you please put it in the bug itself?
<jbailey> I will certainly have forgotten it by tomorrow when I look at this again.
<Tm_T> jbailey: hum, ok, have to register or find my password and username =)
<jbailey> Tm_T: Basically what we'll need to do is look at your /etc/localtime, figure out what it's pointing to and why that's not good enough for KDE.
<jbailey> Any bits of that that you can do and note in the bug will be much appreciated.
<jbailey> I don't know KDE well at all, and don't have a convenient install of it.
<Tm_T> jbailey: ok, it's only kicker clock applet looking wrong time and no timezones
<jbailey> Right.  But fall back to using the date command at the terminal if you could, please.
<Tm_T> jbailey: kontact (calendar etc) does follow correct timezone and time
<Tm_T> yes sir
<Tm_T> thanks
<jbailey> Tm_T: In this case, it also might be worth rebooting to see whether or not kicker clock applet got the wrong time from bootup, and you upgraded after.
<jbailey> The gnome applications are tweaked to cope with things changing underneath them, but I don't know if the KDE ones are.
<Riddell> Tm_T: I think the KDE timezone applet does the wrong thing when changing timezones
<Riddell> I'm still to investigate it properly
<mvo> pitti: your changelogs are back, thanks for telling me
<Tm_T> Riddell: ok, same problem is in your provided and self compiled kicker
<Tm_T> jbailey: nope, restart of kicker didn't change anything
<Riddell> yes, there's no changes in kubunt
<Tm_T> Riddell: if I can help, just ask
<Riddell> (yet)
<Tm_T> Riddell: my selfcompiled has small modifications ;)
<Tm_T> mostly in clock applet
<jbailey> Riddell: If you could look into it as well, that would be lovely.  Basically, if date is working, then I think glibc / locales are setup correctly.  If I'm wrong (and I'm guessing I am), I need to know what you're looking for that's not set correctly.
<Riddell> jbailey: it's on my todo list
<jbailey> Riddell: thanks.
<jbailey> 'bye all!
<jdub> how do i find a list of packages that build-dep on something? kamion's seed pages?
<jdub> (yes)
<Tm_T> oh, so I am registered to launchpad, when?! ...I do need regular sleep =)
<mvo> pitti: I'm doing a big cleaning run on changlogs now, I hope that this fix any outstanding problems
<Chipzz> jdub: grep-dctrl? :)
<zakame> evening devs :)
<mikecrowe> Anybody available for a dapper question?  I tried yesterday but got no response
<hunger> mikecrowe: This is not a support channel. But we try to help with development questions if we can.
* Chipzz points out the topic to mikecrowe ;)
<mikecrowe> hunger: Understood.  The icons within Evolution 2.5.4 out of dapper are not being installed/initialized.  I wanted understand how to report/fix
<Chipzz> if you think it's a bug though, that's something else :)
<mikecrowe> does that qualify?  :-)
<hunger> Chipzz: Then he should file a bugreport:-)
<zakame> just ask away, sombody will answer soon, as long as its on-/topic :)
<hunger> mikecrowe: Well, the trick is to ask. If you get yelled at, then it was offtopic;-)
<mikecrowe> The icons within Evolution 2.5.4 out of dapper are not being installed/initialized.  I will report as bug.  Anybody online familiar with how it was built?   I'd like to fix
<seb128> mikecrowe: there is no such bug
<seb128> mikecrowe: icons are installed
<torkel> mikecrowe: 2.5.4 sounds old. A as first step try to upgrade and see if it still is in the latest version
<mikecrowe> seb128: I did the upgrade, and 90% of button icons/message status icons (attachments, etc) are red X's.
<mikecrowe> seb128: Why say this is not a bug?
<zakame> lol
<seb128> mikecrowe: because I'm sure the package does install the icons so you have an another issue
<seb128> mikecrowe: or everybody would have the bug
<seb128> start by upgrading to a recent version
<seb128> what icon theme do you use?
<Kinnison> I've altered the accept mail format a bit
<mikecrowe> The default, but I can try changing it. 
<Kinnison> does the format used in openscenegraph's accept mail look okay?
<jdub> seb128: can we upload to universe atm?
<seb128> jdub: no reason it shouldn't work afaik
<Kinnison> universe is fine
<fabbione> jdub: uploads are open
<radone> greetings. I am just trying to find source for  "libwxgtk2.6-dev". Could anyone help me?
<radone> using: deb http://cz.archive.ubuntu.com/ubuntu breezy universe main
<sistpoty> radone: find what source-package it is or to download the sourcepackage?
<fabbione> radone: add a line like that one to your sources.list and change deb in deb-src
<fabbione> apt-get update && apt-get source libwxgtk2.6-dev
<fabbione> that will do the right thing in an easy way
<radone> fabbione: Thanks, thats the point. I was using apt-get install and was wondered that it cannot find.
<fabbione> radone: it's all documented in the manpage for apt
* mikecrowe dreads asking seb128 this question
<seb128> mikecrowe: which one?
<mikecrowe> seb128: Is there any chance that evolution-data is not included in the latest dapper repositories?  I can't find anywhere to change icons themes
<mikecrowe> I've installed all the latest from the repository
<seb128> there is such package
<seb128> there is no such package
<seb128> it has no -data
<seb128> but what icon theme do you use?
<jdub> fabbione: with your elite (old?) debian/apache hat on, could you please take a quick look at some packages I've made? low priority.
<fabbione> jdub: sure...
<seb128> mikecrowe: gconftool-2 -g /desktop/gnome/interface/gtk_key_theme
<seb128> mikecrowe: gconftool-2 -g /desktop/gnome/interface/gtk_theme rather
<mikecrowe> The icons within Evolution 2.5.4 out of dapper are not being installed/initialized.  
<fabbione> jdub: send them now before i start doing something more heavy
<jdub> fabbione: deb http://people.ubuntu.com/~jdub/dapper/ ./ (libapache2-mod-annodex)
<mikecrowe> Ah, not in evolution
<seb128> mikecrowe: start using an updated package
<fabbione> jdub: ok
<seb128> mikecrowe: 2.5.90
<mikecrowe> seb128: I am, or I think I am.  Let me check
<seb128> mikecrowe: anyway your issue seems to be with your icon theme not evolution
<jdub> fabbione: is it conventional to *not* make mods-enabled symlinks by default?
<fabbione> jdub: yes that is correct
<fabbione> you install the module, you make it available
<fabbione> you let the admin decide when to enable it
<mikecrowe> seb128: I am using .90ubuntu2.  Sorry for bad earlier info.  Let me use gconftool and see if I can fix that way
<seb128> mikecrowe: you can get the theme from the theme capplet too
<jdub> fabbione: cool
<mjg59> Riddell: When using kpowersave, what's the name of the daemon it launches?
<fabbione> jdub: looks good to me
<jdub> fabbione: ok, i'll upload! ;-)
<zakame> radone: wxgtk2.6 probably
<radone> zakame: If I need compiling from source - is it enought? or do I need  wxgtk2.6-dev ?
<Riddell> mjg59: powersaved
<zakame> radone: compiling using wxgtk2.6? yes, I think you'll probably need the -dev
<mjg59> Riddell: Ta
<jdub> can i do this in a wnpp email?
<jdub> X-Debbugs-CC: debian-devel@lists.debian.org
<jdub> X-Debbugs-CC: utnubu-discuss@lists.alioth.debian.org
<jdub> 
<jdub> ?
<jdub> or should i have a single header with comma delimited addresses?
<Diziet> (b)
<jdub> thanks
<mikecrowe> seb128: I've checked the GTK theme, and even switched it, and here's what I'm seeing:  http://www.mikeandkellycrowe.com/evoshot.jpg
<mikecrowe> seb128: Notice how the print/trash icons are there
* jdub is submitting an RFH wnpp bug for a NEW package in Ubuntu :-)
<seb128> mikecrowe: what icon theme do you use?
<mikecrowe> seb128: That's just it:  I can't find the theme capplet in the default installation.  
<seb128> system, preference, theme
<seb128> or alt-F2, gnome-theme-manager
<mikecrowe> seb128: Am I just having a n00b moment?   ug, I may be.  I'm running icewm right now.
<mikecrowe> dbus problem with nautilus (caused by me)
<seb128> why not starting by that?
<seb128> if you use icewm gnome-settings-daemon is not running and the icon theme is not set correctly
<mikecrowe> seb128: wow, brought my whole system down.  next post to all describes
<mikecrowe> Folks, I'm getting repeated crashes in /lib/tls/i686/cmov/libthread_db.so.1
<mikecrowe> Can't even run bug-buddy to report.  
<mikecrowe> Any ideas?
<seb128> backtrace?
<seb128> for your icon issue, that's because you don't use GNOME or gnome-settings-daemon and don't set your icon theme correctly
<mikecrowe> seb128: BB won't stay up long enough for me to get backtrace
<seb128> use gdb
<mikecrowe> It may have something to do with a dbus issue
<fabbione> elmo: when/if you have time, could you be so kind to sync apr and apr-util from Debian? they will land in our universe and replace apr1.0 and apr-util1.0
<seb128> your icon issue is trigerred by the move of some icons from hicolor to gnome
<fabbione> the latter 2 pkgs -> /dev/null
<seb128> I've opened http://bugzilla.gnome.org/show_bug.cgi?id=330061 upstream about that
<seb128> feel free to comment on it
<Ubugtu> gnome2 bug 330061 in general "some applications are broken by the icons move from hicolor to gnome" [Normal,Unconfirmed]  
<mikecrowe> seb128: Since the crash is *always* in libthread_db.so.1, is there a chance I have a corrupted/old version of it?
<seb128> dunno about that
<mikecrowe> Any thoughts about what package it lies within?
<seb128> get a backtrace
<mikecrowe> I meant about which .deb contains libthread_db.so.1.  I'll google for it
<fabbione> dpkg -S libthread_db.so.1
<fabbione> will tell you
<fabbione> that is libc6
<sebest_> anyone could explain me how to rebuild a package with the debug symbol?
<azeem> sebest_: export DEB_BUILD_OPTIONS=nostrip
<sebest_> azeem: thanx a lot
<desrt> azeem; does that also give -g?
<azeem> building with -g is standard I thought
<Chipzz> azeem: but that's only if the debian/rules file supports it, right?
<Chipzz> nowhere near a standard way to build with debugging info iirc...
<azeem> "By default, when a package is being built, any binaries created should include debugging information"
<azeem> policy 10.1
<sebest_> azeem it worked well for network-manager
<Chipzz> azeem: I was referring to the 'export DEB_BUILD_OPTIONS=nostrip' thing
<Chipzz> azeem: google for DEB_BUILD_OPTIONS, you'll find a whole lot of debian/rules excerpts
<azeem> Chipzz: man dh_strip
<azeem> if the package is not using debhelper, then yes, you need to handle it in rules explicitely, but this is rather uncommon these days
<Chipzz> azeem:  ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
<Chipzz> and stuff like that
<seb128> Chipzz: it is standard
<seb128> Chipzz: dh-make has the adapted CFLAGS by default for debian/rules when you create a package
<seb128> and CDBS does the same
<azeem> Chipzz: noopt is a different matter indeed
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | Ubuntu/on/Soyuz rolled out 20060204
* Kinnison updates the topic to be correct
<mikecrowe> fabbione: seb128:  (sheepish).  Somehow, my libc6 was old.  I must have botched the upgrade.  Installing now.
<mikecrowe> seb128: Is there a quick symlink fix for the icons hicolor issue until resolved?
<seb128> mikecrowe: nop, set your icon theme correctly would be a better fix
<mikecrowe> general question:  after libc6 upgrade, is that a reboot upgrade?
<Chipzz> mikecrowe: not strictly necessary... but a lot of shit will actually still be using the old libc6 until you reboot or restart the stuff in question, yes
<sebest_> there is no way to mark a bug as a duplicate in malone?
<seb128> top right frame
<seb128> "Mark as Duplicate"
<sebest_> ah ok i was looking in the status
<sebest_> seb128: should we close the bugs that are dups? (after having mark it as a duplicate)
<seb128> just marking it as duplicate should be enough
<sebest_> seb128: they will be automatically close when the main bug get closed?
<seb128> I don't know, ask on #launchpad probably
<seb128> I consider a dup as a something rejected or whatever else like that
<seb128> but I might be wrong
<sebest_> yes but they stay in status "unconfirmed"
<sebest_> i'll ask on launchpad
<mvo> pitti: around? should the cupsys-driver-gutenprint postinst fail if cupsys force-reload fails on a upgrade?
<Kinnison> hooker has been reenabled after maintenance
<Kinnison> ia64 is back to two buildds
<ogra> hmm, which god do i pray to for give back stuff as long as infinity is travelling ? 
<Seveas> <Kinnison> hooker has been reenabled after maintenance <-- that sounds so bad when taken out of context...
<Tm_T> ok, this is interesting, fellow user tried to use launchpad, got interesting mail: http://www.kolumbus.fi/lliehu/sekalaista-tavaraa/kuva1.png
<Kinnison> dagnabbit rm -rf is slow
<Kinnison> but not as slow as backing up 12G more than I need to
<Kinnison> :-)
<Diziet> What Malone status should I give a bug when I want to get it off our todo list because I think the issue should be handled upstream ?
<Diziet> Bugzilla had NOTFORUS or whatever it was called.
<Kinnison> Diziet: best to ask that on #launchpad if you haven't already
<jdub> fabbione, pitti: how does this new snakeoil cert stuff work?
<AlinuxOS> hello all
<AlinuxOS> mjg59, hello bro, I've got one question..
<mjg59> Sure
<fabbione> jdub: farly simple.. ssl-cert creates a snaekoil cert in a standard location. all daemon configs are changing to use them by default.
<jdub> fabbione: aha
<AlinuxOS> yesterday, I've installed .deb made by you...
<AlinuxOS> but whole interface uses Courier BPG ttf font...
<AlinuxOS> and GUI become very ugly...
<mjg59> AlinuxOS: Can you reconfigure that in the Gnome settings?
<AlinuxOS> how can we change priority to BPG_Glaho.ttf
<fabbione> jdub: so if you want to replace the cert with a valid one, you can do it in one shot for all services
<jdub> fabbione: i will switch flumotion to that :)
<jdub> fabbione: it should use /etc/ssl/certs/ssl-cert-snakeoil.pem directly?
<fabbione> jdub: Depends: ssl-cert (lastversion)
<AlinuxOS> mjg59, no I've deleted other 2 fonts... to get working Glaho.ttf
<fabbione> jdub:  /etc/ssl/certs/ssl-cert-snakeoil.pem <- cert and  /etc/ssl/private/ssl-cert-snakeoil.key
<mjg59> AlinuxOS: You mean the fonts preferences didn't work?
<fabbione> (check the latter path please)
<AlinuxOS> mjg59, no
<AlinuxOS> I would like to ask you...
<AlinuxOS> if there is the way to say to GNOME to use Glaho.ttf
<AlinuxOS> like default font for a gui.
<fabbione> jdub: take into account that the key is readable only by root for now. If flumotion needs to run as user, please wait for the next ssl-cert upload.
<mjg59> AlinuxOS: Yes. In the fonts preferences.
<mjg59> AlinuxOS: However, that doesn't help why it's picking it by default
<jdub> fabbione: ok! thanks :)
<mjg59> AlinuxOS: I'll look into that
<AlinuxOS> mjg59, If you could change something, and make BPG_Glaho.ttf by default....It would be great.
<Diziet> apt-get upgrade just asked me a question about my timezone.  Is this a known problem or shall I report it ?
<fabbione> jdub: basically we are going to create a ssl-cert group and daemons that run as user can belong to that group to read the key.
<fabbione> jdub: and the admin will have option to allow/disallow usage of it
<AlinuxOS> I saw that ttf-bpg-georgian-fonts.hints
<AlinuxOS> has Priority line inside
<AlinuxOS> BPG_Chveulebrivi.ttf  BPG_Courier.ttf and  BPG_Glaho.ttf  have  "Priority = 20"
<AlinuxOS> by default system recorgnises BPG_Chveulebrivi.ttf for a general GUI.
<AlinuxOS> but the main font is BPG_Glaho.ttf
<AlinuxOS> maybe you can change priority inside a conf file, or change names and give first plase to BPG_Glaho.ttf?
<AlinuxOS> maybe 01_BPG_Glaho.ttf :)
<AlinuxOS> yesterday I was thinking about this problem :)
<Tm_T> hum, there's any way to remove launchpad account, ro can you hint me correct place to ask this?
<mjg59> AlinuxOS: To the best of my knowledge, defoma (which is what reads the hint file) doesn't interact with freetype. But I'll look into it.
<AlinuxOS> mjg59, unic thing that you can improve is to set BPG_Glaho.ttf by default, or important then other 2s.
<AlinuxOS> or I have another idea...maybe put BPG_Glaho.ttf alone in directory and make different directory to other 2 fonts..
<AlinuxOS> I don't know :)
<mjg59> AlinuxOS: Once I've worked out how to do that, I will do
<mjg59> AlinuxOS: Currently I have no idea how to
<AlinuxOS> pitti, hello :) have you changed something with gnome-menus... ??
<AlinuxOS> now it's work :)
<pitti> he AlinuxOS 
<pitti> AlinuxOS: good to hear
<AlinuxOS> pitti, great news
<AlinuxOS> now we have Georgian GPLed fonts too :)
<mjg59> pitti: Mind if I upload a new hal with a couple of small patches (better support for sending keyboard hotkeys, should be in upstream soon)
<AlinuxOS> mjg59, has done great job :)
<pitti> mjg59: not at all, fire away :)
<AlinuxOS> so you could link http://www.srcf.ucam.org/~mjg59/ttf-bpg-georgian-fonts_0.1_all.deb fonts to a georgian-locales 
<ogra> lamont, are you still the person to nag for give back stuff ? 
<AlinuxOS> or include them into main maybe.
<lamont> ogra: not this week.  maybe next.
<ogra> ok
<ogra> do you happen to know who it is this week ? 
<AlinuxOS> pitti, is it possible to get them into main ?
<pitti> AlinuxOS: get what into main?
<AlinuxOS> georgian ttf fonts.
<pitti> sorry, reading backscroll now
<AlinuxOS> because in this moment there is no georgian fonts for GNOME
<AlinuxOS> gucharmap dosen't shows georgian charachters...but some squares :)
<pitti> mvo: actually not
<mvo> pitti: do you mind if I change it so that it not fails (appending a || true) ?
<pitti> mvo: no, that seems fine
<pitti> mvo: but a failing reload of cupsys seems to be the actual problem
<pitti> mvo: I thought I had this fixed in the latest version
<mvo> pitti: I had the problem in my chroot when it complained that the adress is already in use (that was correct :) but the postinst failed then
<pitti> mvo: ok, that seems like a reasonable failure then ;)
<pitti> mvo: yes, ||true seems right then
<mvo> pitti: thanks :)
<jdub> BenC: does the dapper kernel support the promise fasttrak tx4300 (PDC40719 chip) sata board?
<jdub> BenC: seems openbsd supports it
<jdub> BenC: and it's not wildly different from existing supported bits
<ogra> no bcm43xx update ?  :(
* ogra was hoping to get rid of the system hardlocking with his wireless card
<Diziet> mvo: Was it you who was complaining about firefox-dev.pc ?
<mvo> Diziet: yes
<Diziet> err, firefox-gtkmozembed.pc 
<mvo> Diziet: yes
<Diziet> So the problem is that it can't find some nspr headers, not that it can't find the gtkmozembed itself ?
<Diziet> What package fails to build ?
<mvo> Diziet: the c program in the pymozembed testprogram, but I can open a seperate bug for it if you want
<Diziet> No, no.
<Diziet> Oh, yes, it's all coming back to me now.
<mvo> Diziet: let me know if you need more details etc
<Diziet> The problem you saw was a runtime linking failure ?  That's what I see.
<AlinuxOS> mjg59, bro, whan you have a solution for our font prefencies problem, just ping me :) thank you for all...
<mvo> Diziet: while talking about ff, do you have a new opinion about # 19636 ?
<mvo> Diziet: just reproduced the problem, yes it's the pymoz.c link failures that are the problem
<mvo> and the fact that I had to add -lxpcom_core by hand and set a rpath to /usr/lib/firefox
<Diziet> link failures> at runtime, not compile-time.
<Diziet> I'm going to move the libraries.  I don't like the idea of having a .pc file add an rpath.  rpaths are pretty lame really.
<Diziet> gcc  `pkg-config --cflags --libs firefox-gtkmozembed gtk+-2.0 `  pymoz.c  -o lala
<Mez> jbailey: ping
<Diziet> works now for me, making a working binary.
<Mez> he's not here
<Mez> damn
<Diziet> (Well, one that segfaults due to the other bug ...)
<Diziet> 19636> Well hupped.
<mvo> http://pastebin.com/541838
<mvo> the failures when I just use pkg-config
<mvo> Diziet: "hupped" ?
<Diziet> Err, maybe that's Cambridge jargon.  Um, chased, put back onto the top of the attention-stack, etc.
<mvo> Diziet: :) 
<mvo> Diziet: the problem with the link failure is that pkg-config .pc file should take care of it. I wonder why epiphany build 
<mvo> seb128: does epiphany use firefox-gtkmozembed.pc file?
<mvo> Diziet: I didn't wanted to suggest to include the rpath, heaven knows that :) 
<Diziet> Moving the libraries makes it work without changing the .pc so I'm going to do that.
<mvo> Diziet: I'm testing if I get the link failure on a different system as well, or if it only happens on my laptop now
<pitti> mdz: mysql-dfsg-4.1 is ready to go into universe; do you know how to do this in soyuz? :)
<Diziet> 19636> Something more sophisticated seems to be upstream now.  Can you confirm it fixed in our 4ubuntu6 ?
<Diziet> mvo: I reproduced at least some of your problems with the libs in the normal place.
<Diziet> Err, in fact I think I can reproduce all of them.  And they're fixed in my tests.
<mvo> Diziet: I get linking errors on a different system as well
<Diziet> Right.  That's fine.  It's going to be fixed.  What about 19636 ?
<mvo> Diziet: checking now, give me a moment
<mdke> siretart, any luck with that upload?
<Diziet> mvo: Sure.
<Diziet> That extra stuff that it has now about G_SIGNAL_TYPE_STATIC_SCOPE suggests to me that the original diff was wrong in some subtle way to do with memory management.  So I guess I was right to reject it :-).
<mvo> Diziet: a small problem is that I can't really test if it works (I'll look at the code now), because to test it I would need working pymozembed :P
<Diziet> ROTFL.
<Diziet> If we're really lucky the pymozembed will be fixed in 1.5.0.1.
<mvo> Diziet: did you got some feedback from upstream already?
<Diziet> No.  They uppped the priority of my report though.
<Diziet> Oh, they did ask `had I tried valgrind' :-).
<Diziet> https://bugzilla.mozilla.org/show_bug.cgi?id=325884
<sivang> Diziet: I read on some statu report that AutomatedTesting is released, are there any packages already using the control stanzas?
<Diziet> No, none in any archive.  Soon there will be one :-).
* Kinnison gets on with backing up his laptop
<mvo> Diziet: the patch in the current ff looks good (19636), I *think* the static_scope thing is only a optimization to avoid unneeded ref/unref, but I'm not critising you for not accepting my patch (it was rather late in the cycle when I send it to you)
<Diziet> mvo: Excellent.  I like it when there's nothing to do.
<Amaranth> 1.5.0.1 is out, isn't it?
<Diziet> Yes, well, it's out upstream.
<Diziet> I'm about to start my test build (phew).
<Amaranth> good luck
<Amaranth> (the trick is, you get someone else to make a small change then start calling them the maintainer) ;)
<Diziet> Thank you.  I _think_ I won't need it this time so I shall save it up for when I have a magical disappearing crasher bug.
<pitti> doko: ping
<mdz> pitti: no, I don't.  Kinnison?
<Kinnison> mdz: pardon?
<mjg59> Gah. Yes, fontconfig really does seem to be picking a monospaced font in preference to a sensible one.
* mjg59 hits fontconfig
<mdz> Kinnison: <pitti> mdz: mysql-dfsg-4.1 is ready to go into universe; do you know how to do this in soyuz? :)
<Kinnison> universe?
<Kinnison> is this a security update?
<pitti> Kinnison: no, just for dapper
<pitti> Kinnison: we rebuilt everything against 5.0 client libs
<Kinnison> Oh, then just upload it
<Kinnison> dapper is plain and simple
<pitti> Kinnison: erm, I don't have anything to upload for 4.1
<ogra> Kinnison, do you do give-back stuff this week ? 
<Kinnison> pitti: oh you mean a demote
<pitti> Kinnison: I just want it in universe
<Kinnison> ogra: yes
<pitti> Kinnison: right
<Kinnison> pitti: right, elmo is the one to do this right now (I don't know how to drive his tools)
<ogra> Kinnison, could you please give back inputattach then ? 
<mdz> ogra: can't you do that through the web UI?
<Kinnison> mdz: not yet, only admins can. this is on the RSN todo list
<Kinnison> ogra: that's four failed-to-builds
<Kinnison> ogra: you want them sent back to try again?
<Kinnison> I.E. all four archs?
<ogra> Kinnison, a header file was missing in linux-kernel-headers, jbailey added it in the last upload
<ogra> Kinnison, yup, all four
<Mez> ogra, yes - but he also broke libc6
<Mez> in the upload before that
<Kinnison> ogra: I've reset those build records
<ogra> Kinnison, thanks :)
<Kinnison> Hopefully we'll have the UI tweaks to let adam and lamont do this RSN
* lamont points out to Kinnison that he'll need training. 
<ogra> Kinnison, btw, would it be possible to show all the statuses upside down (i.e. newest logs, builds on top) it will get really annoying to have to click the next button n times to get to the recent log/build
<Kinnison> lamont: It's all fairly easy
<Kinnison> lamont: in the short term, getting used to finding things in the UI will help
<lamont> Kinnison: like most things....
<Kinnison> ogra: UI stuff, file bugs
<ogra> oki
<lamont> Kinnison: yes.. must have that brain-ectomy
<BenC> jdub: it should be supported
<lamont> Kinnison: is daily-di (1) in launchpad, and (2) happening?
<BenC> jdub: I have an sata_promise card on my system (with fastrack) and it is working fine
<ogra> BenC, is there a bcm43xx update planned in one of your next uploads ? my ibook hardlocks fairly ofte ,,,
<ogra> *often
<BenC> next upload
<Amaranth> yay!
<BenC> odd, mine never locks up
<ogra> cool ! :)
<BenC> I never take it out of AP range much though
<BenC> it sits on my desk :)
<Amaranth> stupid broadcom chip is the reason i don't run ubuntu right now
<Kinnison> lamont: (1) no (2) no
<BenC> Amaranth: we already have bcm43xx in dapper
<Kinnison> lamont: mdz et al. need to decide how they want to do it
<Amaranth> BenC: I know
<ogra> it happens during dhcp negotiation (which only works after the 10th try or so)
<Kinnison> lamont: I was under the impression they were pondering regular automated sourceful uploads
<Amaranth> BenC: flight 2 (i think) worked once for 2 minutes, flight 3 didn't even get as far as flight 2
<ogra> BenC, if it runs once, its stable 
<Amaranth> ogra: it more than likely fails to associate with the AP
<lamont> Kinnison: ah, yes.... it is true that those are the only binNMU's in the post-warty world
<ogra> Amaranth, i see the ap in iwconfig ...
<Amaranth> iwconfig tells me it's using an ap while softmac is still trying to associate
<ogra> hmm
<Amaranth> but that'd be why dhcp isn't working the first time
<ogra> first place i only care about the hardlocks ...
<Amaranth> i haven't seen those
<ogra> dhcp is the next issue to look after 
<Amaranth> probably because i can't even make the stupid thng work
* Amaranth kicks broadcom chipsets
<Amaranth> stupid apple, using crap hardware
<ogra> it works fine for me, but i need several reboots and have the system hanging on first start ... after this i see no issues at all 
<ogra> s/hangin/locking up/
<BenC> Amaranth: you may need to kick it down to 11M
<Amaranth> did that too
<BenC> 54M seems to be broken for some people (me included)
<Amaranth> with flight 3 i couldn't make it work at all
<BenC> I've been using bcm43xx on my powerbook for over a month now, and it hasn't given me any issues
<Amaranth> with flight 2 i spent about 30 minutes resetting the essid and checking dmesg over and over
<Amaranth> and then it died 2 minutes later :(
<BenC> using it right now, as a matter of fact
<mdz> lamont: if Kinnison is comfortable with all the binNMUs, we can switch on the old system I suppose
* ogra as well
<mdz> lamont: I'm partial to just doing daily sourceful uploads of d-i and not special-casing it anymore
<BenC>         pre-up iwconfig eth0 rate 11M
<BenC>         pre-up ifconfig eth0 up
<BenC>         pre-up sleep 2
<BenC>         pre-up iwconfig eth0 rate 11M
<BenC>         wireless-rate 11M
<Amaranth> either of you using a mini? perhaps it's a different revision
<BenC> Amaranth: put that at the top of your /etc/network/interfaces eth stanza
<Amaranth> err, i have no idea what that does
<Amaranth> i don't even have an ubuntu install anymore, i wiped it to make an hfs+ case-sensitive fs :P
<lamont> mdz: it's nice having it not wrap too horribly - maybe do the verison on the auto-uploads as an NMU, so that us humans can tell easily that it's a no-change
<Amaranth> btw, setting it to 11M doesn't help
<Amaranth> i mean, i had it set to 11M the one time it worked
<lamont> mdz: but I know that soyuz really doesn't like binNMU's...
<Amaranth> otherwise i don't notice a difference
<Amaranth> anyway, lunch time
<Kinnison> If you want it to turn up in daily-installer-* you have to ensure the string '.0.' is in the version
<Kinnison> because that's what colin's code triggers on
<lamont> well, we could do them as sourceful uploads of a binNMU version number... that's easy... :-)
<Kinnison> Other than that, my preference is seriously for sourceful uploads
<lamont> Kinnison: on other topics... https://launchpad.net/distros/ubuntu/+builds current state causes me to ask a question or two...
<lamont> like, what's the default ordering?
<Kinnison> lamont: the gina imported builds will go away in the update tomorrow morning
<Kinnison> the ordering is on datecreated by default
<Kinnison> sorry, datebuilt
<Kinnison> but gina made NULL datebuilds
<lamont> ok
<lamont> hehe
<Kinnison> and NULL *always* sorts first
<Kinnison> because SQL is good like that
<lamont> woot
<lamont> Kinnison: so what finally happened with that binNMU from warty?
<Kinnison> lamont: it got imported
<lamont> sorry
<Kinnison> lamont: the db can represent binnmus
<lamont> ok.  but they're _WRONG_.  understood
<Kinnison> indeed
<lamont> is there a way to limit the +builds output to a single architecture?
<Kinnison> only within a distrorelease
<Kinnison> Go to /distros/ubuntu/dapper/i386/+builds
<Kinnison> that should work
<lamont> and what does Needs-Build translate to?
<Kinnison> translate to?
<Kinnison> "pending build" I guess
<lamont> ok
<ogra> wow, fun ... i wonder how often i have to click "next" there to get to the latest build ...
<Kinnison> ogra: a bajillion
<ogra> heh
<Kinnison> ogra: it'll actually be faster to wait until tomorrow's production rollout
<ogra> lol
<lamont> Kinnison: and could we have an option to have it sort most-recent first? 
<lamont> say, by default?
<lamont> ogra: just edit the batch_start=NNN in the URL.
<ogra> lamont, sure, thats what i'm doing ...
<ogra> lamont, but having a previous/next item there is pretty pointless :)
<lamont> Kinnison: and should you care, I just pushed over the last of the DAK buildLogs from hppa/sparc to p.u.c/~lamont
<Kinnison> lamont: it *does* sort most-recent first
<lamont> but NULL.. doh
<Kinnison> indeed
<Kinnison> tomorrow's rollout hides the NULLs
<Kinnison> launchpad rollouts are quite complex so we can't do them without actually being careful
<Kinnison> So we schedule them and put up with the UI being crufty for a few days every now and again
<Kinnison> Sorry
<Kinnison> mjg59: would you mind advocating me for ubuntu-membership?
* mvo is away to play hockey
<mjg59> Kinnison: Sure
<mjg59> Kinnison: What do I need to do?
<Kinnison> mjg59: I think you have to be prepared to tell the CC that I'm worth having as a member
<Kinnison> mjg59: Keybuk wants me to go through the full process for ubuntu-core-dev, so I need to become a member and a member of ubuntu-dev
<ogra> Kinnison, the CC knows that :)
<mjg59> Kinnison: Ok
<Kinnison> mjg59: will you be around tomorrow for the CC meeting, or do you want to tack something onto my wiki page?
<mjg59> Kinnison: May not be about tomorrow, so if you could attach something that would be great
<Kinnison> mjg59: you'd best edit my wiki page so that it shows the text as coming from you
<mjg59> Kinnison: I think people are likely to believe you :)
* Kinnison grins
<slomo_> Kamion: ping? can you take a look at xine-extracodecs? the source package and the libxine-extracodecs package are in multiverse but the libxine1c2 package built from it is in universe for some reason. there are no rdepends (and rbuild-depends) in universe left... will it move to multiverse automatically later?
<pitti> slomo_: the plague stroke Kamion again, he's offline today
<slomo_> pitti: oh... that's bad :/ well, my question isn't too urgent anyway...
<ogra> mdz, my call for serial mouse testing gave lame results yet (3 answers, one with usable data) :(
<stratus> ogra, i think the problem is with the test scenario
<ogra> stratus, ?? 
<stratus> ogra, i've some serial mouse users from that cdd, but they just don't have how to test that (yet)
<ogra> stratus, it just copy/paste of the command while the mouse is plugged in ...
<ogra> s/it/it's/
<stratus> ogra, where's the hack? in mdetect?
<ogra> there is no hack
<ogra> i only want to see if we can use mdetect for serial mouse detection ...
<ogra> but i suspect that the majority of mice doesnt give output at all 
<stratus> any mdetect could retrieve that data?
<ogra> it does
<ogra> but only for PNP capable serial mice
<stratus> oh, great
<LaserJock> elmo: I would like to make a request that ruby-gnuplot be removed from Universe. It has been packaged in Debian as libgnuplot-ruby
<stratus> ogra, have you mailed -user ?
<ogra> since i dont know the percentage of PNP cvapable ones, i wanted to have some feedback
<ogra> stratus, i wanted to keep that as a fallback 
<ogra> will mail edubuntu-devel and ubuntu-users soon ... but i was hoping to get more out of -devel
<stratus> ogra, i just read your message again, i think that isn't clear that i can contribute if i'm using my cool new mouse anyway.
<stratus> ogra, see there are some -devel subscribed ppl that just looked your message and ignored that, thinking 'i don't care about serial mouses and i'm not running dapper'
<ogra> indeed, mdetect would detect anything... but the pipe through grep should restrict to ttyS*
<BenC> is there anyway to see the status of a source package in the lp buildd queue?
<BenC> like if it even knows about it
<stratus> ogra, it was my feel because you mailed -devel. I though that you just hacked mdetect.
<stratus> ogra, i see.
<ogra> nope, we're smarter :)
<Kinnison> feckit, here goes blatting laptop with dapper
<ogra> the inputattacht tool is already a huge step forward 
* Kinnison hopes he doesn't get horribly broken
<stratus> ogra, but not everybody subscribed to -devel is smart like you. :-)
<sivang> Kinnison: it's been working fine on my gf's , she didn't even complain :)
<stratus> ogra, sure it's
<sivang> (inspiron 8200 , bad acpi by design)
<Kinnison> heh
<Kinnison> the most fun will be making mail work again
<sivang> and using ONE channel for both HD and CDROM
<Kinnison> so far so good
<Treenaks> sivang: lots of laptops have that
<Treenaks> sivang: even my HP NW8240 l33ttop
<sivang> Treenaks: IBM's dont. </I think>
<Treenaks> sivang: my old Asus had this setup as well, my new Acer doesn't I think
<mjg59> pitti: Seen #30198 ?
<pitti> bug 30198
<Ubugtu> malone bug 30198 in hal "HAL crashes from QueryCapability DBUS method." [Major,Confirmed]  http://launchpad.net/bugs/30198
<pitti> mjg59: not yet
<pitti> mjg59: ouch
<pitti> mjg59: I basically ignored my bugs inbox during the sprint, will catch up this week
<stratus> ogra, wee, weird desktop crash smells like badram.
<HiddenWolf> BenC: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15 should show the status of the build, right?
<BenC> HiddenWolf: I see the source is listed I just uploaded, just wondering if it's building or just queued
<ogra> stratus, memetest is yur friend ;)
<Kinnison> BenC:  you can see what the buildds are doing on https://launchpad.net/+builds
<Kinnison> BenC: we ought to make it clear if a build is currently in progress or not
<Kinnison> BenC: but we don't currently
<BenC> sweet, i386 and ia64 are building
<Kinnison> BenC: the others have finished
<Kinnison> BenC: they were building earlier
<BenC> powerpc and amd64 done
<stratus> ogra, memtest86+ is even more friendly, but i'll wait the ram start writing funny stuff to the hard disk. I need to keep this going for more three hours.
<BenC> Kinnison: thanks
<Kinnison> BenC: the other two builds succeeded
<HiddenWolf> BenC: now that this upload it out, do you know if it will fix 29789, or is there something I can test/do to help fix it?
<ogra> Kinnison, the number of total builds on https://launchpad.net/distros/ubuntu/+builds just doubled ....
<ogra> oh, no, it raised by *20 
<Kinnison> pardon?!
* Kinnison tests ogra's temperature
<ogra> there were 6800 builds shown when i looked 1/2h ago 
<ogra> now i see 112648 builds
<Kinnison> this is because your filter has changed
<ogra> it was set to "all" both times ...
<Kinnison> In that case the 6800 was spurious and wrong
<ogra> hmm
<Kinnison> things will be much clearer tomorrow
<Kinnison> Hmm, almost 50% of the way through the second install phase
<slomo> BenC: hi, will you sync the bcm43xx driver and softmac for the next linux-source upload?
<ogra> slomo, yes he will
<mdz> ogra: if people don't care enough to respond, then it must be an issue for a minority
<ogra> mdz, i agree
<Treenaks> ogra: about the mouse thing?
<mdz> it goes to show that sometimes a lot of noise doesn't mean a big problem
<ogra> Treenaks, yup
<Seveas> Urgh, when creating a dapper pbuilder I get: vim: Depends: vim-runtime (= 1:6.4-006+2ubuntu1) but it is not installed
<Treenaks> ogra: I was meaning to ask you something about that :)
<ogra> Treenaks, shoot
<Seveas> isis this a bug in my pbuilder setup, or is vim broken?
<Treenaks> ogra: I have a really ancient mouse, and when I run the command you sent to the list, I get _both_ serial ports back
<Treenaks> ogra: no matter which port I plug it into
<Treenaks> (ttyS0 and ttyS1)
<ogra> Treenaks, the serial ports dont matter ... i'm intrested in something like:
<ogra> Read 5 chars from /dev/ttyS0: \012\020\000\024\001 (50%)
<Treenaks> ogra: that only happens when I click/move
<ogra> if you only get the ports back, it means your mouse isnt detectable 
<Treenaks> ok, so it's too ancient :)
<ogra> yup
<Treenaks> oh well :)
<ogra> i suspect the maoprity is ...
<ogra> *majority
<ogra> but i wanted some proof for that theory
<Treenaks> I have a relatively recent Logitech mouse, at my parents' place
<Treenaks> I could try that (I need to go & see them anyway :))
<ogra> most of the newer ones might work ... 
<Treenaks> ogra: still, you wanted a report ;)
<ogra> yup, thanks :)
<ankan> hello
<ankan> excuse me whats the diff between sevcpn and openvpn daemon?
<Seveas> ankan, try #ubuntu for support - this is a development discussion channel
<ankan> yeah no one there knows, thought someone in here might know
<ogra> mdz, any idea why ltsp-utils is still stuck in main ? rdepends wrongly reports ltsp-client even if that one has a conflicts/replaces ...
<Kamion> Seveas: vim-runtime needs to be promoted to main, but I have no idea how to do that in the Soyuz world; hoping to get basic training on that soon
<Seveas> Kamion, get an angry russion to ignite the rocket? :)
<Treenaks> Kamion: I also read about pitivi packages - which aren't in launchpad yet
<mdz> ogra: rdepends shows all dependency relationships
<Kamion> /home/james/launchpad/scripts/change-override.py looks pretty plausible but I'm not running a random script without getting instructions from somebody
<Kamion> Treenaks: er I have absolutely no idea what you're talking about and am too ill to care right now
<ogra> mdz, oh ...
<mdz> ogra: assuming you mean apt-cache rdepends
<ogra> yup
<mdz> ogra: if you want to know why it is in main, you need to look at germinate rdepends
* ogra tries
<Treenaks> Kamion: hm.. get well then
<Treenaks> Kamion: (Jane's last 'sprint' report mentioned a pitivi package, but I can't find that package on launchpad or in Ubuntu)
<seb128> Treenaks: new packages go to NEW and need to be accepted
<seb128> they are not available by apt before beeing accepted/built
<Treenaks> seb128: ah.. so I only need to wait for Kamion to get well :)
<seb128> I don't know if Kamion does new universe stuff
<seb128> it waits for a ftpmaster to have time for that
<Treenaks> seb128: still, it wouldn't hurt if he got well :)
<ogra> meh
<seb128> and they are probably busy enough with the migration to soyuz
* ogra changes the seeds
<Kamion> I also have no idea how to process NEW in soyuz *shrug*
<Kamion> and as seb128 says I indeed don't generally do universe NEW anyway
<Kinnison> Hmm, okay, dapper working mostly
* ogra applauds Kinnison 
<Kinnison> And only about twelvety issues so far :-)
<ogra> heh
<pitti> elmo: please sync libmail-audit-perl 2.1-5sarge2 and pioneers
<pitti> mdz: Debian recently dropped the old libpng source and renamed libpng3 to libpng; I'd like to do the same for Ubuntu to avoid confusion, is that fine for you? (it would just look like a new upstream version of libpng, but it isn't actually)
<seb128> mdz, Kamion: any objection to update enchant from 1.2.0 to 1.2.2 (that's the lib used by abiword and libsexy (which is used by xchat-gnome) for spellchecking)? They don't have a proper changelog to point but xchat-gnome upstream has pointed some issues with the list of languages available fixed with the new version and they would like to get it updated
<mdz> pitti: OK for me
<mdz> pitti: (libpng)
<pitti> 'k, then I'll merge and ask to drop the old libpng3 sources afterwards
<mdz> seb128: your call, a lack of changelog is sketchy
<elmo> pitti: there's a bug about that btw
<pitti> elmo: right, bug 28709, I'll assign it to me for now
<Ubugtu> malone bug 28709 in libpng "please merge changes from libpng3 or request sync" [Major,Confirmed]  http://launchpad.net/bugs/28709
<seb128> mdz: yeah, I know, but since there is almost nothing using it, that's a minor version change and some upstream is asking for it. I'll make sure that the new version works fine with abiword/xchat-gnome and update if you have no objection so
<zyga> hello
<pitti> hi zyga, how are you?
<zyga> pitti: hi, quite tired
<zyga> I just came from work :/
<zyga> I wish I was working for ubuntu ...
* Kinnison makes seeeeeeeeeeb noises as gnome-terminal crashes
<mdz> seb128: and please ask upstream to start writing a changelog :-)
<ogra> zyga, its a wrong assumption to think you are more awake working for ubuntu :)
<seb128> mdz: yeah, I'll do that too :)
<zyga> ogra: I was not implying that
<seb128> Kinnison: I've a debug backtrace of that crash, I'll work on fixing it tomorrow
<Kinnison> seb128: cool, thanks
<zyga> ogra: I was implying that my work is so not FOSS related that I sometimes want to do something differetn but I know I cannot really
<dolson> is this the right room to try and get help building a package? specifically, I am trying to build ardour. I tried rebuilding ardour on Dapper, and I tried building Dapper's ardour in Breezy, in an attempt to backport it, and I am running into issues
<zyga> dolson: try #ubuntu-motu
<slomo> elmo: ping?
* Kinnison hugs firefox
<Kinnison> I managed to say logged into launchpad across an OS reinstall
<Mez> hmm - I can request syncs from debian as long as it's not a new upstream version -yes? or do they have to go through UVF?
<Mez> Kinnison, keeping the /home dir?
<pitti> generally not, but checking the changelog for sane changes is a good idea
<slomo> Mez: yes... just ask for syncs as long as it's no new upstream version
<Kinnison> Mez: tarred it up, untarrings bits as I feel the lack of familiarity hurt
* Kinnison is just extracting his .emacs
<Kinnison> the world was just a little too unfamiliar
<Kinnison> otoh, dapper isn't *too* crashy
<Kinnison> which is nice
<Mez> pitti: theres not much difference - I just want to request a sync - as It's my package and I'm now maintaining it in debian.
<pitti> Mez: should be fine then
<Mez> so - I'd rather the stuff just be auto-synced in future instead of making me have to wade through MOM reports
<pitti> yes, that's absolutely preferable
<Mez> pitti: who am i asking now we're on soyuz - elmo still?
<pitti> yes
<Mez> elmo: please sync katapult from debian
<Mez> ok to override ubuntu changes
* Mez writes an email too
<sivang> Kinnison: gnome-terminal crashes occasinally. haven't had enough time to try and track this down.
* Kinnison giggles as he realises he'd kinda better install build-essential before wondering why he can't compile anything
<sivang> Kinnison: hehe
<MisterN> hi
<Mez> jdub: ping
<zyga> someone has created a slovak spellcheck packages (for openoffice, myspell and ispell) and whishes them to be included in ubuntu, what does he need to do?
<sivang> f
* lamont wonders if anything major is b0rked in dapper these days
<pitti> lamont: shouldn't any more, at least on arch != powerpc
<lamont> ok
<Kinnison> mjg59: I think I've found the bug in gnome-power-preferences
<zyga> hmm
<zyga> my X.org is eating 100% doing nothing for the past few days
<floam> probably update-notifier?
<floam> it was eating up 100% cpu for me occasionally
<zyga> yes
<zyga> killed it and the issue went away
<zyga> mvo: do you know about this?
<MisterN> n8
<mvo> floam: yes, it's unclear what causes it unfortunately
<mvo> but it's a known bug
<mvo> ^--- zyga
<mvo> update-notifier going mad :/U
<mvo> happened since I switched from libgamin to gnome-vfs
<floam> I figured out how to fix it
<floam> rm /usr/bin/update-notifier
<floam> :)
<crimsun> interesting, I know it pegged my cpu when I lacked a valid Internet connection, thereby wiping out my packages cache
<zyga> mvo: I'll attach gdb the next time
<mvo> zyga: it will probably spin on a closed socket
<zyga> mvo: spin? 
<zyga> it waits on unix socket?
<mvo> zyga: trying to read from it, but getting a EAGAIN IIRC
<zyga> mvo: did you try to just abort() in that case?
<mvo> zyga: the loop code is not in my code, but somewhere else in gtk/gnome-vfs
<zyga> mvo: ah, right :/
<mvo> zyga: I'll probably use inotify directly and see if that helps
<zyga> mvo: what directory do you monitor?
<mvo> zyga: /var/lib/apt/lists, /var/cache/apt/archives, this kind of stuff
<zyga> mvo: notification of disk changes sucks :/
<mvo> zyga: yes, it would be nice if apt would just send dbus events
<zyga> mvo: ay
<floam> debian might consider a change like that
<floam> in 2012
<zyga> floam: oh, good
<floam> maybe 2016
<zyga> dbus will have the kitchen sink by then
<hunger> floam: That might still be in time for etch;-)
<floam> heh
<floam> has anyone seen .debs for gnome's libcm?
* floam is trying to build metacity with the new compositor turned on
#ubuntu-devel 2006-02-12
<nictuku> mvo, hi. In the NetworkWideUpdates spec you mentioned sources.d. That isn't implemented yet, is it?
<mvo> nictuku: it is available in dappers apt
<nictuku> hmm.
<mvo> nictuku: it has to end with .list though
<mvo> nictuku: the files you drop in there
<nictuku> good
<nictuku> I'm working in a new prototype in python for nwu
<nictuku> using most of that specs idea, but with SSL'ed SOAP 
<mvo> nictuku: nice! the initial implementation was pretty hacky :/ (the one that was never released)
<nictuku> and a simple asymmetric cryptographic keys structure for authenticating.
<mdz> jdub: who manages the fridge calendar feed?
<jdub> Mez: pong
<jdub> mdz: fridge-devel (jorge, robitaille, me)
<mdz> jdub: can you add the stuff on DapperReleaseSchedule?
<mdz> at least feature freeze, beta, rc and final
<mdz> the rest are probably not of general interest
<jdub> hrm, i thought all of those were already there...!
<Mez> jdub: can you re-add me to planet please?
<mjg59> Kinnison: Which one?
<glick> excuse mem what version of cvs do you all use?
<Burgwork> glick, http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=cvs&searchon=names&subword=1&version=all&release=all
<Mez> anyone seen jbailey lately?
<jdub> Mez: he's on UK time atm
<Mez> jdub: darn he's broken libc6
<azeem> Mez: bug number?
<glick> for some reason my friend cant checkout sources without getting a read lock error
<Burgwork> glick, please file a bug
<Kamion> please don't file a bug about that, check with the server administrator first
<Kamion> it's not uncommon for read locks to end up left lying around by accident
<glick> Kamion, i am the server admin
<Kamion> so check yourself :)
<Kamion> either that or your friend doesn't have write permission to the repository
<Mez> azeem: one sec
<glick> can i do this...LockDir=${CVSROOT}/CVSROOT/Lockfiles
<glick> in the cvs config file?
<Kamion> no idea, sorry
<Mez> azeem: https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/30546
<Ubugtu> malone bug 30546 in kdebase "kickers clock applet is screwed" [Normal,Fix released]  
<Kamion> ask a CVS support channel or mailing list
<floam> is dapper going to get gimp 2.4?
<azeem> Mez: jbailey commented on that bug
<Mez> azeem: yeah i didnt notice
<azeem> and it seems this is fixed?
<Mez> I dunno am testing
<azeem> well, "Jeff broke libc" made it sound a bit more theatrical than it was
<calc> mjg59: any idea as to when hal is going to be fixed to start up properly?
<mjg59> calc: Mm?
<calc> saw a new upload happened today and it didn't fix the issue
<calc> it hangs on start up
<mjg59> calc: Not here, it doesn;t
<calc> if needed i can try to track down when it started happening, if i can find old debs
<mjg59> Have you filed a bug? (I'm afraid I only uploaded to add some support I needed for laptop hotkeys, I didn't touch anything else)
<calc> there is a bug open about it on malone and in debian bts
<calc> i didn't file it though
<calc> ah ok
<calc> 23:51 < calc> and one of them "hald-addon-acpi" is stuck in read()
<calc> 23:52 < calc> and the acpi one seems to be the last one started
<calc> 23:53 < calc> so probably is the one actually hanging
<calc> 23:55 < calc> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351296
<calc> 23:55 < calc> that looks like it might be the bug
<calc> 23:55 < calc> but hal-device-manager can't attach to it
<calc> 00:04 < calc> malone #30254 seems like the same thing i am seeing also
<Ubugtu> malone bug 30254 in hal "Hal freezes on startup..." [Normal,Unconfirmed]  http://launchpad.net/bugs/30254
<calc> thats what i noticed when looking at it last night
<glick> do i have to delte lock files?
<calc> now after todays update i see two instances of hald-addon-keyboard running as well
<calc> i'm running on amd64, not sure if that makes a difference
<calc> oh damn it finally completed
<calc> it took like 5min to start
<mjg59> Heh. Probably not my bug, then
<mjg59> I modified hald-addon-acpi, but not in any way that would affect that (and my patch isn't in Debian)
<calc> however hald doesn't show to be running anymore either
<calc> hal-device-manager doesn't run anymore either, but thats probably due to it seeing hald isn't running
<mjg59> hal-device-manager hasn't worked since dbus 0.60
<calc> oh ok
<calc> the debian bug report sounds like it is exactly like mine, including the part where it sits there for a long time and then dies
* calc bbl, work
<sistpoty> hi folks
<jdub> hrm
<jdub> so
<jdub> the new build logs are... not brilliantly helpful
<jdub> are the old build logs still updated?
<crimsun> doesn't look like it
<jdub> :(
<crimsun> (judging from http://people.ubuntu.com/~lamont/buildLogs/g/gnome-panel/ )
<jsgotangco> yo!
<mjg59> jdub: File a bug!
<mjg59> (ahem)
<jdub> :-)
<irvin> just checking... the latest kernel in dapper is 2.6.15-14 or 2.6.15-15?
<mjg59> -15
<irvin> hmm... i didn't get the update
<mjg59> May not have built yet
<irvin> i'll probably fetch it later... thanks mjg59
<infinity> mjg59: BTW, I left the laptops at the office, since I had no other convenient way to get them back to you.
<mjg59> infinity: Ok - I'll grab them at some stage
<mjg59> Not urgent
<mjg59> infinity: Hope they were useful (and you've broken initramfs-tools)
<infinity> mjg59: By "broken", are you referring to the typo in the new feature?
<infinity> mjg59: And yes, they were both quite useful.
<infinity> mjg59: Though the tiny one is a serious pain in the butt to work with.
<mjg59> infinity: I'm referring to it wanting to rewrite the conffile and destroy RESUME=
<mjg59> infinity: Excellent. Do express my apologies to Zofia for failing to actually meet her (I do try to see all my fangirls at some stage)
<infinity> Oh, that was going to happen anyway if the conffile ever got updated.  But I'm going to fix it.
<tulga> hi all. I cannot install GIF library in dapper 2. howto install it?
<tulga> I installed libungif4, libungif4-dev. but not found lungif
<infinity> tulga: Tried -lgif?
* infinity goes to the store to get one of everything that it appears he no longer has...
<psusi> Mithrandir, ping
<lsd25> hi, i know this might be the wrong place, but i was directed here by the folk in #ubuntu .. the administrative programs like network-admin and shares-admin seems to stop and hang on the following: connect(13, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16
<lsd25>  .. any idea why?
<fabbione> morning
<desrt> lsd25; i'd guess it's because your loopback interface hasn't been brought up properly
<desrt> lsd25; there was a problem with this a while back in dapper due to the network interfaces state file not being properly erased on reboot
<lsd25> desrt, aha! that might be it, the thing is ubuntu refuses to start my networking on boot, even tho i enabled it in network -admin
<lsd25> thanks alot that as it, no i only need to figure out why networking aint getting started
<desrt> lsd25; i'll be less help to you for that.  bed time for me.
<desrt> good luck
<lsd25> thanks alot man :)
<Mithrandir> psusi: pong?
<psusi> Mithrandir, hey... was just wondering if anything has moved with the e2fsprogs header issue...
<Mithrandir> psusi: I haven't gotten any more response from upstream
<Mithrandir> psusi: I'll prod him and see what comes out of it.
<psusi> cool
<psusi> now if only I could open this password protected mount rainier specifiction pdf
<Chipzz> lsd25: check if your interfaces are still named correctly
<Chipzz> I have my eth0 and eth1 swapped since a couple of days
<Chipzz> hmm wait no that would be unrelated ;)
<lsd25> Chipzz, desrt already poin ted me to check lo .. which was it.. and then i found out why it didnt start on boot ..the interfaces file was fucked up
<freeflying> Mithrandir: I've configured the /etc/environment to use zh_CN , but after remaster the live cd , it still use en_US as default language
<Mithrandir> freeflying: you need to change the bootloader, since it's passed in from there
<pitti> Good morning, Ladies, Gentlemen, Aliens, Artificial Intelligences, etc. pp.!
* sivang hugs pitti 
* sivang hugs Mithrandir 
* pitti hugs sivang 
* Mithrandir ruffles sivang 
<poningru> so would it be possible to have #dapper created so that bugs can be discussed in there?
<seb128> there is a #ubuntu-bugs which should be fine for that
<seb128> any need to create a new chan?
<poningru> there is like no one there when I want to discuss something in #ubuntu-bugs
<poningru> #dapper just seems more attractive
<poningru> as in more people would want to hang out in #dapper than in #ubuntu-bugs
<siretart> poningru: developers are more likley to be in #ubuntu-bugs
<seb128> the name of the chan doesn't matter
<seb128> people are not likely to hang to a new chan because it's named #dapper
<poningru> would it be ok if I came in here to discuss those bugs if no one in #ubuntu-bugs answers?
<seb128> no
<poningru> :(
<seb128> discuss bugs on #ubuntu or by bug tracker
<seb128> read the topic
<poningru> seriously? #ubuntu?
<poningru> fine
<poningru> thanks for the info
<seb128> this chan is just not a bug tracker one
<Kamion> "build it and they will come" does not work for IRC channels
<seb128> hey Kamion, do you feel better today?
<Kamion> at least not if you want "they" to include knowledgeable people rather than just more people with problems
<Kamion> yeah, somewhat, thanks
<Kamion> will attempt to work at least some of the day
<seb128> cool
<poningru> well I guess I will just file it all at malone, I just wanted a place to make sure my bug isnt showing up only for myself
<seb128> even if the bug is showing only for yourself that may still be a bug and should be fixed
<seb128> if you have desktop issues you can mention them on #ubuntu-desktop
<pitti> elmo: please sync libpng (Ubuntu override ok) and remove libpng3 from the archive
<pitti> Mithrandir: any idea why we only have ppc live images in daily-current? (yesterday, too)
<Mithrandir> pitti: I'm not sure what the status of the new world order with soyuz is concerning live images, so no, not really.
<ogra> Kinnison, ping ... do you also process the NEW queue until Kamion had a training for it ? the new linux-image-2.6.15-15 packages seem stuck there ...
<pitti> ogra: ... and we finally want sound back on ppc :-P
<ogra> exactly :)
<ogra> and i'm to lazy to compile the source myself :P
<Kinnison> ogra: I have the ability but not the social responsiblity
* Kinnison points out that until the CC meeting today, I'm not even an ubuntu member
<Kinnison> and I may not qualify then
<ogra> processing them would give you a huge amount of social bonus for that i think *G*
<Mithrandir> Kinnison: do you happen to know if we're building live cds inside soyuz yet, or if the old procedure still holds?
<Kinnison> Mithrandir: CD building is untouched
<Kinnison> Mithrandir: whether or not the buildds are doing it, I don't know
<Kinnison> Mithrandir: best to ask adam or lamont
<Kinnison> ogra: Umm, maybe, but I'd also get a huge "see your job? not any more you don't" unbonus for fucking with the archive without the authority to do so
<ogra> so who has this authority then ? 
<jdub> ogra: darth vader.
<ogra> haha
<Kinnison> ogra: elmo, mdz or kamion
<ogra> hey jdub 
<jdub> and he wouldn't piss about with 'job unbonus' crapola either!
<ogra> heh
<Treenaks> jdub: 'I find your lack of faith.. disturbing' 
<Kinnison> jdub: the force is strong in you, young waugh
<jdub> one flick of the wrist, with a little bit of force sauce, and *blammo*, instant powerpc sound action
<sivang> morning Kinnison !
<Mithrandir> Kinnison: 'k
<Treenaks> Now all I need is -restricted-modules for 15-15
<Kinnison> Mithrandir: but elmo is awake, so you can ask him
<Kamion> Kinnison: alternatively, feel free to instruct me on how to process NEW :-)
<Mithrandir> elmo: can you tell me what the current state of how live (and I presume, regular install) cds are built?
<Mithrandir> possibly s/elmo/Kamion/ too?
<Kamion> Mithrandir: AFAIK all that needs to happen for live CDs is that they get s/jackass/drescher/ somewhere, or similar
<Kinnison> Kamion: I'm currently trying to work a couple of other things out, then I'd be glad to
<Kamion> Mithrandir: install CD building is unchanged; it was just disabled over the weekend, but I've re-enabled it now
<Mithrandir> Kamion: which means infinity or lamont, I presume.  Given that I just have trigger access and can't fiddle with stuff on the buildd.
<Kamion> Mithrandir: right
<jdub> Kinnison: i imagine you've already had questions about build logs - would it be possible to spit them out into a directory like the old ones for a while?
<Kinnison> no
<Kinnison> Well, not easily
<jdub> will similar browsing and searching exist on launchpad (soon)?
<Kinnison> I expect so
<jdub> cool
<carlos> mvo: hi, around?
<mvo> carlos: yes
<Kinnison> the right thing to do is to file bugs on /products/soyuz for any view you're missing
<mvo> carlos: long time not seen, how are you?
* jdub knows it's a rough migration, doesn't push too many buttons :)
<carlos> mvo: Fine, thanks. And you?
<mvo> carlos: fine, I survided london and the dead-flu, now I'm good again :)
<carlos> :-D
<Treenaks> mvo: The New & Improved mvo?
<Kinnison> jdub: honestly the most useful thing you can do is file bugs for whatever functionality you'd like.
<jdub> ok
<Kinnison> jdub: that way we have a target to work toward
<carlos> mvo: Do you remember that problem I told you about update-notifier?
<carlos> mvo: I'm having it again now
<carlos> mvo: https://chinstrap.ubuntu.com/~dsilvers/paste/fileSugA3G.html
<carlos> that's the last lines of the strace output
<jdub> BenC: ping
<jdub> oh man, this "to execute a command as root" thing is so backwards
<pitti> jdub: we'll fix the description to be more readable and add a manpage
<jdub> pitti: can't we do it with su?
<pitti> jdub: we don't want to
<jdub> but this is entirely backwards
<pitti> backwards?
<jdub> as a random terminal user, i really don't care about root
<pitti> jdub: but it's only displayed for admins
<jdub> and putting up banner ads about running stuff as root is pretty crazy
<jdub> thing is, it's advertising something that flat out doesn't matter *until* you want to do it
<jdub> in which case one of two things happens:
<jdub> a) you know enough to try su, which should fail and explain what to do
<jdub> b) you have no idea what to do, so you read the documentation that says to use sudo
<jdub> c) you have no idea what to do, but some random website or book says to use su, go directly to (a)
<Mithrandir> jdub: a) 1) people think about using su, but realise they haven't provided a root password and wonder how to proceed
<pitti> for a) the message helps to point these folks to sudo
<jdub> Mithrandir: then they either try it or go to (b)
<pitti> and the message and manpage directly helps (b)
<Mithrandir> jdub: yes, they do, and then they whine about it too.
<jdub> Mithrandir: with a useful message from su, that would be reduced, but ultimately, we're not going to reduce the number of whiners by putting banner ads in our software :)
<jdub> this is like all those stupid startup configuration wizards
<jdub> EXCUSE ME WHILE WE INTERRUPT THIS PROGRAM FOR A MESSAGE FROM OUR SPONSORS
<jdub> "try sudo to run shit as root!"
<jdub> "thanks mum!"
<Mithrandir> jdub: yes, I agree with you that it's a silly thing to have, which is why I argued against it.
<jdub> WE NOW RETURN TO OUR REGULARLY SCHEDULED PROGRAM
<jdub> $ _
<jdub> so we're doing crazy stuff like this in dapper, which we have to live with for 5 years? eek.
<jsgotangco> eek
<jsgotangco> poor grandma
<jdub> BenC: http://pastebin.com/542984
* mdke points jdub at his email about yelp customisation, begs for reply, goes back to work
<ogra> jdub, afaik the sudo message was a sbdfl request ... convince him ;)
<Treenaks> ogra: 'baby jesus might cry'
<jdub> the other thing is, i'm being told on every terminal invocation
<Treenaks> jdub: until you sudo once
<jdub> i thought it was supposed to stop after the first sudo
* Treenaks just removed it from /etc/bash.bashrc
<jdub> i get it every time
<jdub> and i have mad sudo skillz
<jdub> i can even recover from typing 'sudp'
<jdub> which i do quite regularly
<Treenaks> jdub: alias sudp=sudo ;)
* jdub waves kung-fu slicey hands around
<hunger> Hmmm... which deb do I need to write a bugreport against when I have user-processes hang around after the user logged out?
<Treenaks> hunger: the hanging process
<seb128> depending
<Treenaks> 'the one & is in'
<hunger> Treenaks: What if there are several different ones?
<Mithrandir> Kamion: do we have anything like dapper_probs with the new world order?
<Kinnison> britney is not currently in the cronjob
<freeflying> Mithrandir: after remaster kubuntu's dapper livecd , kdm need be restarted manually, and then it can log into kdm 
<Mithrandir> Kinnison: could it be?  Not having it is making my work a fair bit harder.
<Kinnison> Mithrandir: I think elmo said kamion would need to get it ready
<Kinnison> Mithrandir: but kamion was ill yesterday
<Kamion> Kinnison: can I run it on drescher, or should it be elsewhere?
<Kinnison> Kamion: that I'm not sure about
<Kinnison> Kamion: if it can run elsewhere then I guess it should
<Kinnison> Kamion: if it needs to run on drescher you'll need to check with elmo
<Kamion> there is no other host with a mirror that's updated anywhere near as regularly
<Kamion> rookery is IIRC every six hours
<Kamion> elmo: can I run britney on drescher please?
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | LP Upgrade 1030UTC today. est 1h downtime. Uploads queued
* Kinnison thought screen had corrupted then
<ogra> meh
<ogra> inputattach is also stuck in NEW ... i cant work with a non installable ltsp-client package ... :(
<doko> who does care about package removals from universe?
<ogra> doko, elmo ... mail him the request
<ogra> (and avoiding the word morgue in the mail helps a lot ;) )
<Kamion> ogra: inputattach will be processed right after this publisher run and LP downtime
<Kamion> I would have done it already but the publisher run kicked in
<Kinnison> this LP upgrade includes a librarian disk array firmware upgrade so it's going to be longer than usual
<Kinnison> hence the 1h window
<Kinnison> it's just unfortunate it happened today
<ogra> Kamion, thanks a lot 
<freeflying> Mithrandir: may you give any advice on that 
<seb128> is "lo" usually considered as a requirement on a well configured system?
<Mithrandir> seb128: yes
<ogra> i wonder if we shouldnt postpone feature freeze a week until the LP dust has settled 
<Mithrandir> freeflying: uh, unsure.  Ask Riddell?
<seb128> ie: what would you do with bugs like "app doesn't work when lo is not configured"?
<seb128> close them as notabug? :)
<Mithrandir> seb128: why does he not have lo configured?
<seb128> dunno, ask sladen, he did open a bug on totem about that
<Kinnison> Kamion: I did an install off the dapper 2006-02-03 CD last night
<Kinnison> Kamion: I had a couple of comments but I'm not sure if you'll have fixed them yet
<Mithrandir> seb128: I'd just close it with something along the lines of "please up your lo interface, then"
<Kinnison> Kamion: do you want them here, in a mail to you, or filed as bugs?
<seb128> k, let's close the bug, we have enough real ones without bothering for people who don't want to configure a lo
<hunger> No lo was common a while back with all those networking changes going on... I thought that was fixed?
<Kamion> Kinnison: quick summary?
<seb128> Mithrandir: right, will do that, thank you :)
<hunger> seb128: When was that bug filed?
<Mithrandir> hunger: sure, but then the bug is "lo is not configured" rather than "$foo doesn't work when lo is not configured"
<Kinnison> Kamion: downloading file XXX of YYY (TTT remaining)
<Kinnison> Kamion: TTT never left 0s
<Mithrandir> Kinnison: aptitude bug
<Kinnison> Kamion: when installing the packages, it still used the CD
<seb128> hunger: the lo one? today
<hunger> Mithrandir: Well, you know how people report bugs:-)
<Kamion> ogra: I don't think that would fit into the rest of the schedule without delaying dapper, sorry
<Kamion> Kinnison: downloading should be retrieving, known bug
<hunger> seb128: Oh, then I'd go for notabug;-)
<Kinnison> Kamion: and "font installation is unutterably slow, can we stub fc-cache like we did for scrollkeeper?"
<Kamion> Kinnison: oh, yeah, just need to test that one
<Kamion> ok, don't need bugs for any of those
<Kinnison> Kamion: and "When loading the kernel, green text appeared at the top of my screen"
<Kamion> that one I know about but don't currently know how to fix; it's reasonably frequently reported
<ogra> Kaloz, yes, sadly ... but its delaying work quite a bit ... would have been nice to have that planned in the beginning ...
<Kinnison> Kamion: the rest are after the first reboot
<Kinnison> Kamion: so I'll file bugs for 'em
<Kamion> ogra: I don't think it's a significant enough delay to justify shifting freezes around.
<Mithrandir> Kamion: can you promote python2.4-soappy?  It appears it's needed by python-soappy which in turn is needed by u-d.
<Mithrandir> Kamion: (python-soappy is already in main and from the same source package, so no inclusion report should be needed)
<Kamion> Mithrandir: will do after the LP downtime, when Kinnison's promised to teach me how to change overrides :)
<Mithrandir> Kamion: great, thanks.
<Kamion> Kinnison: the green text requires grotty x86 assembly hacking in syslinux
<Kinnison> Kamion: yum
<Kinnison> build sequencer suspended, incoming queue process suspended, cron.daily suspended
<Kinnison> uploads should be queued
<Kinnison> we'll make this as quick as we can guys
* ogra gets coffe
<ogra> e
<ogra> pitti, did we have any securityhttps://lists.ubuntu.com/archives/ubuntu-users/2006-February/066622.html update which could cause this ? 
<ogra> grepf
<ogra> https://lists.ubuntu.com/archives/ubuntu-users/2006-February/066622.html
<pitti> ogra: not really, sounds like iz gamin bug
<pitti> ogra: killall gam-server ?
<pitti> hey Keybuk 
<ogra> pitti, thats breezy 
<pitti> I know
<Keybuk> heyhey
<ogra> pitti, i have no idea why this should appear there
<pitti> but the last security updates didn't touch gnome
<ogra> pitti, thats what i thought
<ogra> Keybuk, i recently had to look at bootmisc.sh, it has a line like:
<ogra> rm -f /tmp/.clean /var/run/.clean /var/lock/.clean
<ogra> isnt that obsolete ? 
<Kinnison> Keybuk: my shiny new dapper install hangs at "detecting and activating hardware"
<Kinnison> Keybuk: on warm boots
<Keybuk> Kinnison: boot without quiet and splash and see what the last dmesg line is
<Kinnison> Keybuk: Will do
<Keybuk> ogra: yeah, but I didn't worry about that one because it's harmless
<pitti> the rescue mode should also do some verboseness
<Kinnison> Keybuk: also, when shutting down, it sits for ages and ages at sending TERM signal
<Keybuk> ogra: the actual /var/run and /var/lock cleaning code is gone though
<ogra> Keybuk, just noticed it 
<Kinnison> Keybuk: I was too tired to debug last night
<Kinnison> Keybuk: I fixed a bug in gnome-power-preferences and went to bed
<radone> Pleas could anyone help me with sourcelist configuration?
<radone> I have dependency problem : libgtkmm2.0-dev: Depends: libgtk2.0-dev but it is not going to be installed
<radone> my source list is here: http://cpp.sourceforge.net/?show=12312
<ogra> radone, please ask in #ubuntu, this is not a support channel
<ogra> (see topic)
<radone> ogra: ok, thanks
<ogra> Kinnison, which bug in gnome-power-preferences did you fix ? i have no bug reports ...
<ogra> (yet)
<ogra> :)
<Kinnison> ogra: bug 30718 :-)
* Keybuk kicks Ubugtu
<Kinnison> Keybuk: erm, it can't talk to the db
<Kinnison> production rollout in progress
<Keybuk> oh
<ogra> heh
<Kinnison> poor ubugtu
* Kinnison ruffles it
<Kinnison> Unfortunately the database update is taking longer than we'd hoped, we may not hit our 1h estimate, sorry about this
<Robot101> to the pub! :)
<Kinnison> Robot101: I wish
<Kinnison> Bringing up the ftpmaster functions, please wait
<Keybuk> SPIN UP PONIES FIVE THROUGH TWELVE!
* Treenaks takes Keybuks drugs away
* Robot101 takes Keybuk's drugs
<Keybuk> Hah!  Take that "hardware detection takes ages on my machine" people!
<Keybuk> muahahahaha
<Keybuk> never again will we get a complaint that Ubuntu takes too long to "detect hardware"
<Robot101> Keybuk: you removed hardware support?! :)
<Treenaks> Robot101: he changed the message ;)
<Kinnison> incoming queue processor enabled
<Robot101> "Rotating badgers"
<Keybuk> if only usplash could do animation
<Keybuk> imagine what the breezy april fools joke could've been
<jpatrick> lol
<Kinnison> Ubuntu days reenabled for XX:00
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | LP Upgrade was today, please report bugs if you see 'em
<sivang> jdub: is this your work? :) http://people.ubuntu.com/~jdub/random/3ubuntu.jpg
<jbailey> Keybuk: Usplash could do animation.  I'll flicker because of lack of double buffering, but it's no worse than I had on my TRS-80 ;)
<Kinnison> trash80!
<jbailey> Kinnison: Yeah.  I phear what my father must've paid for that collection of machinery when I was little. =)
* Kinnison grins
<Kamion> pitti: could you please review inputattach for main inclusion? thanks
<pitti> yep
<Keybuk> didn't we go through that bit already? :p
<Keybuk> I remember bribing you and shortcutting it in <g>
<Kamion> I noticed that joystick was in universe, so I don't get to use the "basically already in main" exception
<Keybuk> I need to find a package I can use Tom Lehrer quotes and lyrics in the changelog of
* Keybuk looks at emacs
<Keybuk> :p
<Treenaks> Keybuk: Send the marines.
<Keybuk>  We'll all go together, when we go
<Kinnison>  Three billion hunks of well done steak
<Kinnison>  I got it from Alice...
<Kinnison> Keybuk: or, to follow on from your last maths related one...  But you can't take seven from three...
<mjr>  You can get anything you want, at Alice's restaurant (excepting Alice)
<Kinnison> BTW, the +builds UI should be fixed a bit now
<Kinnison> Keybuk: in fact, the new math song is full of usable lines
<Kinnison> "'cos addition is commutative, right?'"
<Treenaks> 'The textbook that I got this problem out of wants you do do it in base 8'
<lamont-away> Mithrandir: what needs love on the livecd front?
<Keybuk> https://launchpad.net/distros/ubuntu/dapper/+source/udev
<Keybuk> Kinnison: ^ still displays the wrong versions
<Mithrandir> lamont-away: s/jackass/drescher/ in livecd.sh, AIUI
<Kinnison> Keybuk: yeah, s'a non-shallow bug afaict
<Kinnison> Keybuk: bug cprov
<jdub> sivang: found object
<lamont-away> Mithrandir: ah, ok.  I'll fix that once I'm awake
<Kamion> lamont-away: (s/jackass/drescher/ is kind of a spiritual rendering of the substitution, I'm sure a few other things need changed ... worst case make it use archive.u.c)
<Mithrandir> lamont-away: thanks.  And what Kamion says
<Keybuk> http://news.bbc.co.uk/1/hi/entertainment/4688670.stm
<Keybuk> ^ fantastic
<jpatrick> wow, that's odd..
<Diziet> Woohoo, Debian ff maintainer seems to be accepting most of my patches.
<slomo> mjg59: ping? i have two patches for the dbus-mono bindings... do you want to take a look at it or can i upload it?
<mjg59> slomo: I'm so not the right person :)
<mjg59> Check with pitti and then upload?
<sladen> Keybuk: it could do animation
<sladen> Keybuk: what did you have in mind?
<slomo> mjg59: well, you was the last one who touched dbus :) but ok, i'll ask pitti
<Keybuk> sladen: dancing badgers, naturally
<slomo> pitti: ping? ;)
<ogra> mjg59, did you chnage something else in your last g-p-m upload ? i have a missing icon in the preferences recently
<pitti> listening...
<mjg59> ogra: Hrm. Don't think so.
<ogra> mjg59, (apart from the changelog entries i mean indeed)
<ogra> ok, i'll have a deeper look then
<seb128> icons broken are probably gnome-icon-theme bog
<slomo> pitti: this is the debdiff: http://slomosnail.de/~slomo/temp/dbus_0.60-2ubuntu11.debdiff
<seb128> there changed half of the world
<slomo> pitti: it fixes two rather big bugs in the bindings... and doesn't touch anything else
<seb128> s/there/they
<pitti> slomo: ok, I'll upload that
<slomo> pitti: thanks :) (well, i could upload it too but when you want to do it...)
<pitti> slomo: oh, then go ahead
<ogra> seb128, hmm, i just noted it with all different themes ...
<pitti> slomo: I thought you were searching for a main uploader
<seb128> ogra: they probably all inherit from the gnome theme and don't ship any variant for that icon
<ogra> yup
<slomo> pitti: no... only for a "go ahead" :) i don't want to touch something as important as dbus without asking before
<ogra> guess so
<Keybuk> ogra: this isn't the first missing icon you've had though
<Keybuk> you had missing nm icons last week, no?
<ogra> yup
<seb128> that was due to a cache issue
<ogra> but that was fixed by deleting a cache file 
<seb128> something/somebody did generate a GTK icon cache on his box
<Treenaks> seb128: gnome doesn't remember that I want nm-applet to start, is that a result of the new logout/switchuser stuff?
<seb128> how would it be supposed to remember? save it to your session
<seb128> ie: run gnome-session-save
<Treenaks> seb128: why doesn't it do that for me?
<seb128> it never did
<seb128> because it doesn't assume you want to register all the stuff which are open to your session
<seb128> you have to store your session when you want to do so
<Treenaks> seb128: That's OK, but stuff like network-manager and gnome-power-manager are quite essential imho
<seb128> that's why they put a desktop to /usr/share/autostart
<Treenaks> seb128: then why don't they start?
<seb128> which will be started automatically by gnome-session for every user when I've figured why it doesn't work atm
<ogra> g-p-m doesnt yet .... iirc
<Treenaks> ah
<seb128> because you didn't send a patch and I'm too busy to fix the universe in a day?
<ogra> (put a .desktop in place)
<seb128> it does actually
<Treenaks> seb128: I'm just asking.. sorry.. how was I supposed to know about gnome-session-save?
<hunger> gnome-power-manager does not run when gdm is on as I understand it.
<ogra> hunger, ??
<ogra> you mean if youre not logged in ... ?
<hunger> ogra: Right.
<ogra> thats true
<hunger> ogra: It should do aggressive power saving then in my oppinion.
<seb128> Treenaks: no problem. Right there is an usuability issue with session saving atm, that's already been pointed but nobody went with a constructive suggestion
<hunger> ogra: It won't be bothering anyone then;-)
<seb128> Treenaks: if you have suggestions on how to change that you are welcome
<seb128> Treenaks: note I don't want to fix the universe, but the session autostart is on my list, I just did come to it yet :)
<Treenaks> seb128: sure, if I get a brilliant idea I'll send it to you :)
<ogra> hunger, its fine as it is currently ... at least its the best we have ... future versions or apps we might use might also work when nobody is logged in...
* hunger shrugs. I am not using gdm anyway.
<ogra> hunger, i know desrt is aiming to prepare something alternative ...
<seb128> Treenaks: note too that my initial comment is that session never remembered stuff for you if you didn't say it to do so
<seb128> Treenaks: it just used to have a box to the session dialog for that
<Treenaks> seb128: yeah
<Keybuk> ooh, emblems are now recursive!
<Keybuk> look ma, I was good today in the scouts! :p
<ogra> lol
<StevenK> Heh
* Keybuk wonders what the little horsey means
<Treenaks> Keybuk: No pony for you.
<StevenK> Heh. I don't remember asking to be a member of motureviewers, but here I am being one.
<Keybuk> StevenK: probably because you're a member of a team that are all members
<jdub> Keybuk: you now have a little planet, too :-)
<Treenaks> Planet Keybuk?
<Keybuk> I saw that
<jbailey> seb128: Around?
<seb128> jbailey: yep
* Diziet gets confused and resorts to drawing a railway diagram.
<jbailey> seb128: How's life on the timezone front?
<jbailey> seb128: Are all the issues you had sorted out with the 2.3.10 locales?
<seb128> jbailey: great now, everything works fine now
<jbailey> Riddell: Actually, for you too, are you still having TZ issues?
<seb128> yep
<Riddell> jbailey: I never did (having not run a dist-upgrade or anything)
<Riddell> jbailey: but everyone who complained has now had it fixed by updating to latest locales
<jbailey> Riddell: Lovely, thanks.
<jbailey> Sorry about forgetting to upload that last fix. =)
<jbailey> I have a launchpad bug open that counts on me not uploading glibc, so I'll look at moving all the timezone love to locales properly tomorrow.
<Diziet> Oh, FFS, this strange spew from the ff build system is due to the make multiline incompatibility.
<Diziet> AARGH.  How do I get this shit-for-brains new make to pass a multi-line string to a command without any spurious \'s in it ?
<elmo> Diziet: there was a thread about it on d-d@l.d.o that might help
<Treenaks> \l\i\k\e\ \t\h\i\s\ \o\f\ \c\o\u\r\s\e\!
<Diziet> elmo: Do you happen to have a ref or shall I google ?
<elmo> http://lists.debian.org/debian-devel/2005/12/msg00988.html
<Diziet> Ta.
<mjg59> elmo: Can you sync hotkey-setup from Debian? (Do syncs still work the same way?)
<Diziet> Eeeeeech.
<elmo> mjg59: yes, and in a bit
<mjg59> elmo: Thanks
* Diziet resorts to:    set -e; s=' script \    as \   previously   ';   n="$$(printf "%s" "$$s" | sed -e 's/\\$$//')"; \    perl -e "$$n"
<Diziet> At least that way we won't get a rejected patch every time they change the middle of the script.
* ogra hugs Kamion for the NEW stuff
<Keybuk> I'm going to write an MTA
<Keybuk> it's Unique Selling Point will be that it never delivers anything
<ogra> huh ? 
<Keybuk> and I shall call it DHL
<ogra> lol
<zakame> haha
<desrt> Keybuk; have it deliver a mail back to the sender stating merely "everything is ok."
<ogra> but break the contens before :)
<ogra> *contents
<desrt> right.  you can't include the original contents in this reply
<Keybuk> "we put it on the van this morning" ... that's nice, NOW WHERE THE FUCK IS THE VAN?  "oh, the driver finished for the day, it's gone back to the depot"
<desrt> otherwise you might be able to trick DHL into delivering for you
* ogra reboots to (hopefully) have working sound again
<Kamion> elmo: so how do I change overrides in soyuz (e.g. move a package to a different component)? Kinnison pointed me at change-override.py, but it tries to talk to dogfood and Kinnison said it looked unfinished ...
<slomo> Kamion: while you're at it... can you move libxine1c2 to multiverse? it's source package and the other binary package created by this one is already in multiverse
<Kamion> slomo: no, I can't
<Kamion> slomo: not without knowing how to change overrides :P
<slomo> Kamion: oh sure... sorry... but can you do it when someone told you how? :)
<desrt> grr
<desrt> slomo; 
<desrt> Keybuk; 
<desrt> "its", not "it's"
<Keybuk> desrt: doesn't matter where you put punctuation, as long as it's there ;)
<stratus> heh
<desrt> "it's" is appropriate in this case.
<StevenK> Damn, why didn't Keybuk mark my English papers when I was in high school. :-P
<Keybuk> it's was appropriate there too, "it has"
<desrt> 08:12 <Keybuk> it's Unique Selling Point will be that it never delivers anything
<Keybuk> oh, bah
<stratus> it's expired
<desrt> i let it slide.... i'm usually good for one... but once slomo did it too i snapped :)
* Keybuk forces desrt to the floor and tickles him to death
* desrt does not negotiate with terrorists
<stratus> desrt: you should review intltoolized strings.
<stratus> heh
<StevenK> What's to negotiate? Keybuk didn't talk to you about it, he just forced you to the floor, and then to your death.
<desrt> stratus; far more productive to make the authors of said strings acutely aware of their poor spelling :)
<Keybuk> desrt: spelling things right would involve thinking before I type
<desrt> isn't it noon there?
<stratus> desrt: sure, but i was just pointing out that you would be helpful in that camp too.
<desrt> stratus; i can't pay attention to anything like that for more than about 12 seconds :(
<stratus> desrt: but i'm sure that you still have the raw power to blame upstream about their poor strings, go ahead. :-)
<desrt> stratus; i often do do that :)
<stratus> desrt: for more than 12 seconds? sounds great.
<desrt> stratus; while using my computer, if i see something that needs fixing
<stratus> desrt: good anyway.
<desrt> we need a grammar police :)
<stratus> i think english itself lacks one, so...
* Keybuk eyes the "UNIX time" and "Internet Time" features of the gnome panel clock
<Keybuk> WHY ARE THOSE STILL THERE?
<HrdwrBoB> desrt: you rand?
<desrt> rang?
<HrdwrBoB> er rang
<HrdwrBoB> yes
<desrt> Keybuk; ya.  seriously.  wtf.
<desrt> Keybuk; they didn't even ask me to add "desrt time"
<desrt> Keybuk; (00:00 to FF:FF GMT)
<Treenaks> Keybuk: 'Internet Time' is the @200 stuff right?
<stratus> desrt time or desert time?
<Keybuk> Treenaks: right
<Treenaks> Keybuk: I know people who actively use that
<HrdwrBoB> Treenaks: that nobody ever used or understood
<Keybuk> stratus: or dessert time?
<HrdwrBoB> Treenaks: all five of them will have to move on
<Treenaks> HrdwrBoB: and UNIX time is useful sometimes
<Keybuk> Treenaks: not on the panel, it isn't!
<desrt> desrt time, definitely.
<HrdwrBoB> Treenaks: anyone who needs unix time knows how to get it
<stratus> Keybuk: yes, btw who cares about UNIX time? It's over.
<Treenaks> Keybuk: I don't want to be forced to run the KDE clock applet...
<stratus> :-)
<Keybuk> Treenaks: "date"
<desrt> hahahah
<Treenaks> Keybuk: that requires an extra terminal
<desrt> unix time is what i thought it was
<desrt> what a useless option
<HrdwrBoB> Treenaks: oh nos, if you need unix time
<HrdwrBoB> you have plenty of terminals alreadt
<Keybuk> if we have either of those, I want to be able to see the date in Discordian!
<desrt> Keybuk; please don't say anything to upstream about those two options
<desrt> Keybuk; i want to do something fun :)
<stratus> desrt: bcc me and share the fun stuff.
<desrt> stratus; send me an email with your gnome bugzilla email address
* desrt gotta run
<stratus> desrt: heh
<ogra> pitti, ping
<pitti> ogra: pong
<ogra> pitti, do you have sound now ? 
<ogra> cant get it working here
<pitti> oh, new kernel in the archive now?
<ogra> yup
* pitti tries
<ogra> /dev/sndstat looks fine, the devices in /dev/snd as well
<freeflying> ogra: pitti : hi, I've noticed that you've talked about scim in #ubuntu-meeting, so how about that maininclusion 
<pitti> freeflying: yes, good idea; can you quickly drive me through the first steps with scim? I don't know anything about input methods
<pitti> (in /msg)
<ogra> freeflying, its on the anastacia list for main inclusion... but that was before the switch to launchpad, no idea if or when it will enter main 
<ogra> freeflying, i'm not having any clue about scim myself, i just see the enormous demad and occasinally get questions from users about it
* pitti aptitude install skim
<freeflying> ogra: pitti : will you read something here www.scim-im.org
<pitti> scim even
<freeflying> pitti: I'm remastering livecd, and make skim work with it defaultly, so if you'd like , you may have a try about skim
<pitti> I installed scim now (above was just a typo)
<pitti> do I need skim as well?
<freeflying> pitti: in gnome you need not
<freeflying> pitti: skim is just a kde fronted for scim
<pitti> ok
<pitti> so I installed scim, and in gedit I now have the scim input method
<freeflying> pitti: and also you'd install some IMEngine like scim-tables-zh or others
<pitti> but I continue to type latin characters
<pitti> whoops
<pitti> I pressed ctrl+spave
<pitti> and now I can type chinese :)
<freeflying> export XMODIFIERS=@im=SCIM
<freeflying> export GTK_IM_MODULE=scim
<freeflying> export QT_IM_MODULE=scim
<freeflying> #export QT_IM_SWITCHER=scim
<freeflying> #scim -d
<freeflying> #export XMODIFIERS=@im=fcitx
<freeflying> #export GTK_IM_MODULE=fcitx
<freeflying> #export QT_IM_MODULE=fcitx
<freeflying> #fcitx-cairo
<pitti> 
<pitti> well, maybe not chinese, but something like that :)
<jpatrick> hehe
<jpatrick> :)
<freeflying> pitti: great ,thses are some Japnese at all ,:)
<pitti> ah, my keyboard selector turned into something different
<pitti> with a huuuge choice of alphabets, nice
<freeflying> pitti: y, and there many other IMEngines in scim-tables
<spacey> too bad there is no k8 kernel on 32bit
<pitti> whoops, gedit crashed
<pitti> freeflying: is scim known to cause many crashes?
<freeflying> pitti: it used be , but now quite few
<seb128> pitti: backtrace?
<pitti> !
<seb128> pitti: oh, scim one?
<pitti> (I hope that's not a curse of any kind :) )
<freeflying> pitti: these are chinese 
<seb128> how does scim work? I tried installing it some time ago but ctrl-space was not doing anything
<pitti> yes, I know
<pitti> seb128: right-click, select input method scim
<seb128> ah, k
<pitti> and then ctrl+space changes
* seb128 tries again
<mdke> siretart, any luck with the ubuntu-docs upload?
<pitti> and I can select the mapping in the keyboard applet
<freeflying> pitti: if you use qt/kde program , install scim-qtimm, and it will works too
<pitti> freeflying: ok, nice, so it seems that scim works out of the box
<pitti> and it's not terribly big either
<freeflying> pitti: y
<pitti> ogra, BenC: still no ppc sound with 15 kernel
<pitti> it can open the device now, though
<ogra> pitti, yes, same here 
<ogra> pitti, i also noted that the alsa initscript is gone ... it used to make it work for me if i ran it with force-resume 
<freeflying> pitti: still no sound on ppc with 15 kernel?
<pitti> freeflying: ok, I'll review the packages now
<pitti> freeflying: exactly
<freeflying> pitti: I prepare to show kubuntu on ppc to Mark at 2/15
<seb128> pitti: I've no scim method on a GtkTextView widget menu
* freeflying hope that will be fixed 
<seb128> (ie: gedit text area)
<pitti_> bah, go my ISP
<freeflying> seb128: you'd add these export XMODIFIERS=@im=SCIM,export GTK_IM_MODULE=scim
<pitti> freeflying: why and where do you need all those scary exports?
<freeflying> pitti: I put these in /etc/X11/Xsession.d/
<freeflying> pitti: you may configure these with im-switch
<seb128> freeflying: doesn't work neither
<pitti> freeflying: why do we need im-switch?
<seb128> pitti: do you need to run "scim" somewhere to get the context menu method?
<pitti> seb128: yes, I selected 'Scim input method'
<freeflying> pitti: im-swithc ican configure these for each language such as Ja, Ko and others
<seb128> pitti: I've no such menu item ... do you use the current dapper package?
<freeflying> seb128: you'd run scim -d first
<seb128> as previous time I tried, no way to get the scim method listed or the control panel
<seb128> scim is running
<pitti> seb128: yes
<seb128> without the -d
<seb128> I use -d now but no change
<pitti> seb128: I just did aptitude install scim, and then it was just there
<freeflying> seb128: if you'd like , u may use my livecd for test skim/scim   http://ubuntu-zh.3322.org/ISO/kubuntu-zh-live-i386.iso
<pitti> seb128: oh, btw, I only seem to get it in newly started apps
<pitti> seb128: i. e. I started gedit, and it's there
<jsgotangco> downloading...
<pitti> seb128: it's not automatically updated to existing apps like my terminals
<jsgotangco> ugghhh 10kb/sec
<freeflying> jsgotangco: it's just a 4M VDSL,
<pitti> freeflying: hm, no; I get it in gedit, but not in gnome-terminal
<pitti> even after restarting
<seb128> pitti: I restart gedit several times
<seb128> I'll strace it to see
<pitti> freeflying: DCC doesn't work well here, please pastebin or email
<freeflying> pitti: put the file I sending in /etc/X11/Xsession.d and make it can be excute
<seb128> pitti: "grep -i scim /etc/gtk-2.0/gtk.immodules" ?
<pitti> "/usr/lib/gtk-2.0/2.4.0/immodules/im-scim.so"
<pitti> "scim" "SCIM Input Method" "scim" "/usr/share/locale" ""
<seb128> k
<seb128> I've no such entry
<seb128> scim package is bugged somewhere
* seb128 runs /usr/bin/gtk-query-immodules-2.0
<seb128> lsd25: /usr/lib/gtk-2.0/2.4.0/immodules/im-scim.so: No such file or directory
<seb128> s/lsd25/ls (xchat...)
<seb128> pitti: dlocate /usr/lib/gtk-2.0/2.4.0/immodules/im-scim.so ?
<freeflying> pitti: http://paste.ubuntu-nl.org/8174
<jbailey> doko: Seen the emails with Sujet: 	Request for clarification on the 128bit long double requirments  ?
<Treenaks> 'Sujet'? :)
<jbailey> Treenaks: "subject" in fr_CA
<pitti> seb128: scim-gtk2-immodule
<Treenaks> jbailey: ah :) 'shady figure' in Dutch :)
<pitti> freeflying: that script sets scim as default input method?
<seb128> ahhhh
<jbailey> Treenaks: But I tend to assume that all of the distro team is passingly fluent in just about every western european language, and a smattering of eastern european ones for common prompts. =)
<seb128> that's what I was missing the previous time too
<seb128> pitti: thank you
<freeflying> pitti: y 
<pitti> seb128: you didn't install recommends: or something?
<jbailey> pitti: ping re: timezone stuff when you have a moment.
<pitti> jbailey: moderately busy, but just fire away
<Riddell> jbailey: fr_CA is not a western european language
<seb128> pitti: no, I use apt and don't install Recommends since I don't want those usually
<jbailey> Riddell: I've been advocating that Canada join the EU for some time.
<jbailey> Riddell: I want a european passport, DAMMIT.
<jbailey> =)
<jbailey> pitti: It looks like the sensible thing for me to do is migrate all of the timezone questions in glibc to locales.  I think that will solve the last of the questions I have about it.  Any objection?
<doko> jbailey: yes, ABI breakage discovered for all versions after 3.3
<jbailey> doko: It looks like glibc will support the old and new ABIs/.
<pitti> jbailey: in principle not, but what do we need questions for? i. e. which particular question do you mean?
<jbailey> pitti: Establishing the default timezone.
<pitti> jbailey: ah, just a normal prio debconf question?
<jbailey> Kamion: This is probably interesting to you as well, since I think the installer might set this.
<freeflying> pitti: or you can install im-switch and " im-switch -s scim " , it will establish a simbolic link in ~/.input.d
<jbailey> pitti: Well, the nice part is that I think this means it can actually become a debconf question.
<freeflying> pitti: then scim will start with X
<jbailey> Right now it's a shell script.
<pitti> jbailey: ah, right, I recently got that question in a terminal
<jbailey> pitti: Yeah, that happened because it detected that you had chosen a timezone that didn't exist.
<jbailey> (since the timezones were no longer in the libc6 package)
<pitti> erm, had I?
<pitti> ah, I see
<jbailey> So I think the Right Thing is to put the question in the package that actually contains the timezones.
<pitti> I agree
<jbailey> Since it's not an essential package, I think it means that I can debconfify it and everything.
<jbailey> locales, that is.
<doko> jbailey: right, dapper's as well?
<Kamion> jbailey: as long as it continues to support the non-debconf interfaces to setting the timezone (/etc/timezone and /etc/localtime), that's fine
<jbailey> doko: Dapper won't grow the new ABI.  It's all glibc 2.4
<jbailey> unless I've seriously misunderstoof.
<jbailey> Kamion: Sure.  Debconf Is Not a Registry. =)
<Kamion> somebody remind me, what do I have to do to make Rosetta pick up a new .pot file in my package?
<Treenaks> Kamion: draw a circle on the ground, put some candles on it, wave a dead chicken
<Riddell> Kamion: it should do it automatically (or rather the rosetta people will notice it and assign it somewhere sensible)
<Riddell> but dapper isn't being imported into rosetta yet
<Kamion> Riddell: automatically if the .pot file appears somewhere in the source package, or if it appears somewhere in the binary package?
<Kamion> this is a weird case and does not correspond neatly to stuff in /usr/share/locale?
<Kamion> s,\?,/,
<freeflying> pitti ,seb128 : how about scim now ?
<Riddell> Kamion: if it appears in the compiled sources
<Kamion> Riddell: YM the binary package, or the built source tree?
<seb128> freeflying: after installing the input method it seemed to work, what was the discussion about?
<Riddell> Kamion: built source tree
<Kamion> hm, ok, scary magic
<Riddell> I think, pitti will know the details
<freeflying> seb128: We want this can be installed defaultly , at least for our CJK users
<Riddell> seb128: I think freeflying is asking if it's passed main inclusion review yet
<seb128> ah, that's a question for pitti
<seb128> I was just interested to get it working because we get bugs about it sometime and I didn't manage to reproduce them before
<hunger> pitti: Just assigned #30730 over to you... It would be nice if you could use that for fetchmail's init script (it is just a couple of lines shuffled around to make /etc/default/fetchmail more useful).
<hunger> pitti: Thanks:-)
<siretart> mdke: not yet, cprov wanted to contact me about some kind of additional required workflow. I didn't really get it
<pitti> freeflying: yes, I'm reviewing it now, don't panic :)
<pitti> Kamion: the pot file needs to be somewhere in the built source tree, not in the debs
<freeflying> pitti: just waiting   :)
<pitti> Kamion: preferably in the same directory where the po files are, but as long as there is only one po/ directory and pot file, it does't really matter
<pitti> Kamion: pkgstriptranslations just does sth like find -name *.pot -o *.po | tar up
<Kamion> pitti: ok, perfect - thanks
<pitti> hunger: yes, I agree
<jbailey> seb128: Are you handling evo-exchange bugs now, or should those go to Adam?
<seb128> jbailey: I don't have any exchange setup, so my "handling" on them is limited to forward what looks like a bug upstream
<pitti> freeflying: what's scim-dev for? it's an empty package
<pitti> freeflying: ah, nevermind
<freeflying> pitti:  meta package to provide development libraries and documentations for SCIM platform.
<pitti> freeflying: https://wiki.ubuntu.com/MainInclusionReportScimimswitch doesn't exist
<freeflying> pitti: https://wiki.ubuntu.com/MainInclusionReportim-switch?highlight=%28switch%29
<pitti> freeflying: ah, 'mind the dash' :)
<pitti> freeflying: thanks, I'll correct it on the MainInclusionQueue page
<pitti> freeflying: so what we should do is to make e. g. scim-anthy a dependency of language-support-ja, right?
<pitti> freeflying: and maybe put scim itself in desktop
<pitti> freeflying: so that we can avoid installing all input methods on all computers
<freeflying> pitti: make IMEgine a dependency of language-support
<Keybuk> got to pop into town to get vga/dvi converter, then will be building this pc
<pitti> freeflying: hm, we don't even need to put scim in desktop, since e. g. scim-anthy depends on it already
<freeflying> pitti: y
<freeflying> pitti: just use dependency
<jono_> hi all
<jono_> is beagle planned for dapper?
<pitti> freeflying: where and how do we bring in im-switch?
<Treenaks> jono_: I think it's still too crackful for that :(
<jono_> Treenaks, thats what I thought
<freeflying> pitti: actually scim shall have a dependency on im-switch
<jono_> but inotify is in right, so I just need to install the beagle package?
<Keybuk> inotify is in, enabled and used
<freeflying> pitti: another problem: how can skim be installed 
<jono_> Keybuk, good stuff :)
<pitti> freeflying: I don't have im-switch installed, and it works nevertheless
<pitti> freeflying: hm, good question, we don't have separate gnome/kde support packages
<freeflying> pitti: the others use im-switch to configure scim 
<freeflying> pitti: im-switch make the configure more easily
<pitti> freeflying: ok, I don't object against adding a dependency to scim
<pitti> skim has it already
<freeflying> pitti: I've added it to skim , but minghua will not add it to scim
<pitti> why not?
<freeflying> pitti: in fact there are request for add it to scim about 1 year ago
<freeflying> pitti: I don't know 
<pitti> freeflying: debian bug 314744 ?
<pitti> silly Ubugtu, speak after me: D-E-B-I-A-N
<freeflying> pitti: and in kubuntu, user needn't install scim , just libscim8 for skim
<pitti> freeflying: hm, so shouldn't e. g. scim-anthy depend on scim | skim, instead of just scim?
<freeflying> pitti: it's hard to solve all these 
* pitti waves to jdthood 
<pitti> freeflying: why? just changing dependencies is trivial? or does scim-anthy need more work to work with skim?
<freeflying> pitti: scim-anthy is just a IMengine of scim, but skim can wok\rk just need libscim8
<freeflying> actually, I just install libscim8 scim-anthy and skim, they will work 
<freeflying> and dependency of anthy on scim is meaningless
* jdthood semaphores back to pitti
<pitti> freeflying: ok, whatever, but something needs to be fixed
<freeflying> s/libscim8/libscim8c2a
<pitti> freeflying: anyway, we shold probably just put scim into ubuntu-desktop, and skim into kubuntu-desktop and depend on the language specific input method packages in langauge-support-lang
<pitti> freeflying: that libscim dependency is generated automatically
<jdub> http://en.opensuse.org/Xgl
<pitti> jdub: I saw the videos yesterday, craaack :)
<freeflying> pitti: best choice  now 
<jono_> we need that kind of high quality, fresh, brazilian crack in Dapper
<ogra> pitti, another boring wobbly windows demo ?
<pitti> ogra: yes, with a performance requirement our open source drivers will never ever provide
<ogra> heh
<pitti> freeflying: ok, chewing's dependencies are fine, could you please quickfix anthy?
<HiddenWolf> pitti: isn't novell planning to ship it in NDL?
<pitti> dunno
<Yagisan> pitti, so my beloved radeon 7200 can't run it nooo!!! ;)
<jono_> ogra, they are shipping it in NLD
<ogra> HiddenWolf, in 3 years if its basically usable probably 
<Kamion> Riddell: kubuntu-dapper seeds seem to have been locked for some time?
<ogra> jono_, thats crazy
<Kamion> bzr: WARNING: Unable to update the working tree of: sftp://chinstrap//home/warthogs/archives/seeds.ubuntu.com/kubuntu/seeds/dapper/
<HiddenWolf> ogra: damn. :/
<Kamion> bzr: ERROR: bzrlib.errors.LockError: File '.bzr/branch-lock' already locked
<jono_> ogra, it is a touch
<ogra> HiddenWolf, no i have no clue to be honest ... but i wouldnt consider it ready for common usage
<Riddell> -rw-rw-r--  1 pitti warthogs 0 Feb  7 15:33 .bzr/branch-lock
<freeflying> pitti: you mean the maininclusion of scim-anthy?
<Riddell> Kamion: pitti was the last to touch kubuntu seeds
<pitti> freeflying: well, first that, and to make sense in general :)
<Kamion> -rw-rw-r--    1 jriddell warthogs      0 Dec  8 03:35 branch-lock.write-lock
<Kamion> dunno if that's significant
<Kamion> pitti: ?
<HiddenWolf> ogra: I'd be nice to look into to at least test it. People like candy, and graphically dapper isn't too different from warty. :/
<pitti> yes, the write-lock is what matters
<pitti> Kamion: but it's group writable, so that shouldn't stop you?
<ogra> HiddenWolf, i like stability ... 
<Kamion> I've certainly committed to kubuntu/seeds/dapper since Dec 8
<Riddell> me too
<Kamion> pitti: I could probably break the lock by hand but I dislike doing that
<HiddenWolf> ogra: *chuckle* There is that.
<pitti> Kamion: I had this several times so far, I just rm'ed the .write-lock to make it work again
<ogra> HiddenWolf, and compatibility ...
<pitti> Kamion: that's what they told me in #bzr at least
<Kamion> ok, if neither of you are committing to it then I'll do that
<Kamion> s/committing/pushing/
<Riddell> I'm not, go ahead
<pitti> me neither
<freeflying> pitti: shall change the dependency in scim-anthy package and upload it now
<Kamion> ok, thanks
<pitti> Kamion: hmm, Feb is still surprising, though; the last time I merged the seeds was last friday or so
<pitti> (Feb 7 even)
<ogra> HiddenWolf, i.e. since i care for ltsp i rather care about S3 Virge than about Nvidia 25000XS turboboost afterburner cards ;)
<pitti> Kamion: so I assume that timestamp was from your attempt
<Kamion> pitti: perhaps my bzr touched the branch-lock in the process of discovering that there was a held write lock
<lfittl> lamont-away: ping
<HiddenWolf> ogra: Hm, yeah, I agree.
<Yagisan> ogra: I miss the fact that my s3 virge has been unaccelerated since Xfree86 3..x
<mdke> siretart, ok good luck with that. Let me know when it is sorted out!
<pitti> freeflying: thanks
<jono_> is there a central hardware database for ubuntu ?
<pitti> freeflying: maybe you want to add the im-switch dependency to scim?
<pitti> freeflying: I don't know whether this makes sense, so I just defer that to your judgement :)
<freeflying> pitti: but the maintainer won't like to do so 
<pitti> freeflying: in Debian you mean? I don't see a particular ubuntu maintainer
<Riddell> jono_: no but ogra keeps an eye on what everyone is using at http://hwdb.ubuntu.com/
<lamont-away> lfittl: si?
<jono_> Riddell, ahhh cool
<lfittl> lamont-away: svnmailer successfully built 12 hours ago, but it is still not in the archive
<lamont-away> neato.
<ogra> jono_, you have a short mind :P
<lamont-away> Kinnison: ^^
<jono_> ogra, I remember we discussed this in the past :)
<pitti> freeflying: oh, wait
<ogra> jono_, we talked about it a year ago ;)
<freeflying> pitti: what ?
<jono_> ogra, I didnt realise this site was up and running
<pitti> freeflying: no need to deviate from debian just for that dependency
<jono_> ogra, last time we talked you were working on the client :)
<jono_> ogra, good work :)
<pitti> freeflying: we'll just add im-switch to ubuntu-desktop
<ogra> jono_, it is but still lacking basic functionallity ...
<jono_> ogra, so can a user use the site to search for hardware support?
<ogra> nope, not yet
<pitti> freeflying: so, merely fixing anthy is enouhg
<ogra> but a developer can use the hwdb ID and download the dataset to get the info out of it ...
<freeflying> pitti: ok ,I'll upload to REVU
<ogra> searchability is still the biggest lack
<jono_> ogra, is the plan to make it searchable by users?
<pitti> freeflying: will it be uploaded to ubuntu after that soon?
<pitti> freeflying: if not, just pastebin me the debdiff, I'll upload it
<ogra> jono_, yup
<ogra> jono_, but that requires some time on my side i didnt have yet ...
<freeflying> pitti: It'll need some reviews 
<jono_> ogra, ahhh ok
<pitti> freeflying: I'm happy to review it :)
<ogra> jono_, currently edubuntu and ltsp draw all my attention
<freeflying> pitti: just some minutes
<pitti> yes, no hurry :)
<Kamion> lfittl: it's in NEW
<Kamion> lfittl: all new packages require manual attention before entering the archive
<lfittl> Kamion: Binary NEW isn't processed automatically?
<Kamion> lfittl: hell no
<lfittl> Kamion: oh, k, thanks
<lfittl> Kamion: Who processes the binary NEW queue?
<Kamion> lfittl: elmo, mdz, and I
<pitti> freeflying: same issue with scim-tables, it depends on scim
<Diziet> Can anyone tell me what a StartupWMClass is ?
<Diziet> (In a .desktop file.)
<Robot101> Diziet: it's startup notification stuff
<Robot101> Diziet: https://listman.redhat.com/archives/xdg-list/2003-July/msg00024.html
<Kamion> BenC: are you dealing with l-r-m and linux-meta?
<Kamion> (I NEW-processed linux-source-2.6.15 earlier today)
* jdub wonders where some of his uploads went... libcmml, liboggz, libannodex...
<ogra> jdub, NEW stuff ? 
<jdub> nup
<jdub> libapache2-mod-annodex was NEW
<ogra> yes, i saw the mail to utnubu
<Kamion> jdub: versions?
<jdub> Source: libcmml
<jdub> Version: 0.9.1-0ubuntu1
<jdub> Source: liboggz
<jdub> Version: 0.9.3-0ubuntu1
<jdub> Source: libannodex
<jdub> Version: 0.7.3-0ubuntu1
<ogra> i dont see any upload from you on -changes
<jdub> nor i
<ogra> when did you uplaod them ? 
<jdub> i got a NEW mail back for mod_annodex
<jdub> earlier today
<ogra> hmm, likely Kinnison can answer this ...
<ogra> or #launchpad
<Kamion> 02:50:05 WARNING Exception during processing made it out of the main loop.
<Kamion>  -> http://librarian.launchpad.net/1558945/vwS18nhX3kEkOC0oP39LLZBVffo.txt ('libcmml_0.9.1.orig.tar.gz')
<Kamion> sodomy non sapiens
<Kamion> I suspect you forgot to use -sa
<jdub> hrm
<Kamion> if that's true and soyuz didn't mail you to tell you, file a bug
<pitti> Kamion: inputattach looks fine, btw
<pitti> Kamion: I just wonder why it's not built...
<jdub> Kamion: hrm, on launchpad?
<ogra> hmm, LP bug ? it should reject it properly
<Kamion> jdub: launchpad-upload-and-queue
<Kamion> pitti: has built, I new-processed it earlier today
<pitti> ah, I see
<Kamion> and rookery has it
<jdub> Kamion: https://launchpad.net/products/launchpad-upload-and-queue/+bug/30741
<Ubugtu> malone bug 30741 in launchpad-upload-and-queue "No error mail about missing .orig uploads" [Normal,Unconfirmed]  
<Kamion> jdub: oh, where did that attachment come from?
<jdub> sorry, which?
<Kamion> http://librarian.launchpad.net/1558945/vwS18nhX3kEkOC0oP39LLZBVffo.txt, mentioned in that bug
<jdub> you pasted it above
<Kamion> so I did :-)
<ogra> heh
<Kamion> hadn't noticed there was a traceback in there
<ogra> jdub, looks like you can poke cprov directly in #launchpad :)
<Diziet> Robot101: Ah, thanks.
<pitti> mjg59: arrgh - I started g-p-m and it shut down my system
* Kinnison returns from the bank, sorry for the delay
<Kinnison> lamont-away: ?
<ogra> hmm, yes, something is wrong ... i just updated it and the preferences crash 
<Kinnison> ogra: ?
<pitti> and now it immediately shuts down again while loading the gnome desktop
<mjg59> pitti: Suggests that it failed to read your battery status and thought it was 0
<mjg59> Presumably hal boog
<pitti> mjg59: I just took out the battery, yes
<mjg59> Ah
<mjg59> In that case it's g-p-m being stupid
<mdz> jdub: please unsubscribe khirano@gmail.com from ubuntu-bugs
<mdz> jdub: it's bouncing, and the uncaught bounces are forwarded by mailman to me
<ogra> Kinnison, see jdub ...
<pitti> mjg59: it even displayed me the power chord icon, so it knew that I was on power adapter
<mjg59> pitti: Ha. Right, easy enough to fix then
<jdub> mdz: ok
<pitti> mjg59: I'm going to continue to work on the new pmi now; I want to add script calling support
<mjg59> pitti: Sure
<mjg59> pitti: Ideally most of the scripts in acpi-support would move into pmi
<jdub> mdz: done
<mdz> jdub: thanks
<mjg59> pitti: At least, the prepare and resume ones
<ogra> mjg59, while your at it.... see bug 30718
<pitti> mjg59: So I presume we'll need to move the /etc/power/ scripts from pbbuttonsd to pmi
<Ubugtu> malone bug 30718 in gnome-power-manager "gnome-power-preferences crashes on toshiba a100" [Normal,Unconfirmed]  http://launchpad.net/bugs/30718
<pitti> mjg59: but that will become a transition hell :-/
<mjg59> pitti: Well, better to merge them with the ones from acpi-support
<mjg59> Yes
<ogra> not sure if thats the issue i see as well here
<mjg59> ogra: kinnison was looking into that
<ogra> mjg59, he already fixed it
<ogra> mjg59, but has no upload rights :)
<Kinnison> jdub: ?
<mjg59> ogra: Ok
<lamont-away> Kinnison: any idea on the status of svnmailer?  apparently "built several hours ago"
<Kinnison> lamont-away: svnmailer?
* Kinnison can look, one sec
<lfittl> lamont-away: Kamion said that it was in binary NEW, everything is ok then
<lamont-away> ah
<lamont-away> Kinnison: is there any way that I can check yet? or is that still pending...
<Kinnison> lamont-away: still pending
<Kinnison> lamont-away: need web-ui visualisation of the distrorelease queues
<lamont-away> ok
<jdub> Kinnison: hrm?
<Kinnison> jdub: ogra said you wanted me#
<ogra> jdub, Kinnison is our point of contact for launcpad weirdness with uploads/buildds
<jdub> Kinnison: i fixed my shit and filed a tangentially related bug.
<Kinnison> jdub: okay
<Kinnison> :-)
* Kinnison was at the bank
<Kinnison> the joys of mortgages
<ogra> BenC, hmm, my bcm43xx got worse with -15 lots of DUP's in pings to my AP and a pretty unstable behavior ...
<pitti> mjg59: hmm, reading the scrips, we don't actually need to move them from pbbuttonsd - the ones that are active by default don't do anythign for suspend/resume
<pitti> mjg59: and keeping the other ones in sync with upstream is a bit painful
<mjg59> pitti: Ok
<ogra> i dont have any probs if i just disable pbbuttonsd over here ...
<pitti> mjg59: so I'll just add /etc/apm script calling for now, does that sound sane to you?
<pitti> ogra: no, pmi with some perlish ioctl's works just fine
<mjg59> pitti: Ok
<ogra> pitti, yup :)
<pitti> mjg59: maybe g-p-m should conflict to pbbuttonsd in the future then?
<ogra> pitti, dont tell that to Keybuk 
<pitti> ?
<Kinnison> BenC: I was having fun last night with a yealink usb handset. know much about them?
<pitti> to Kamion you mean?
<mjg59> pitti: Sure
<ogra> pitti, Conflicts may only be used for file conflicts in packages ...
<pitti> ogra: huh? since when?
<ogra> pitti, thats what i was told  ...
<ogra> pitti, ask Keybuk 
<mjg59> Debian policy doesn't say that
<ogra> i had this discussion during the last xscreensaver-> gnome-screensaver switch
<pitti> that sounds pretty weird, how else should two alternative packages that do the same thing declare a conflict to each tother?
<pitti> Keybuk: ???
<sistpoty> pitti: see malone #22335
<Ubugtu> malone bug 22335 in ubuntu-meta ubuntu-desktop "gnome-screensaver conflicts with ubuntu-desktop" [Normal,Fix released]  http://launchpad.net/bugs/22335
<pitti> ah
<pitti> well, that's something entirely different
<sistpoty> pitti: there is a lengthy comment in there ;)
<ogra> pitti, see Keybuks comment at the end
<seb128> pitti: the discussion was about screensaver, and having both installed is not an issue, you may want to use one with KDE and the other with GNOME on the same box
<ogra> sistpoty, thanks, i didnt remember the bug#
<sistpoty> ogra: me neither, but goole is my friend ;)
<seb128> pitti: so they should not conflict for nothing
<Amaranth> Replaces is supposed to Do The Right Thing now, isn't it?
<pitti> seb128: but here they will
<seb128> Replaces is when you replace a file from an another package
<pitti> seb128: installing g-p-m and pbbuttonsd at the same time will break the same way as installing pmud and pbbuttonsd
<pitti> which is why pbbuttonsd Conflicts: pmud
<pitti> and that makes much sense
<ogra> Amaranth, all these fields are only referring to files inside the packages ... according to Keybuk 
<seb128> pitti: yeah, I was not speaking about current case :)
<pitti> of course introducing a virtual package and C/F/P: to it would be cleaner
<Amaranth> ogra: Until we have something better to do what we need, I guess we'll have to keep abusing them then, eh? :)
<ogra> Amaranth, sure, you dont meet Keybuk in person to feel the baseball bat :)
<Amaranth> ogra: we're on different continents ;)
<seb128> Amaranth: abusing Replaces for what?
<ogra> us others who do, might consider themselves ;)
<Amaranth> seb128: abusing Replaces/Conflicts to do transitions
<ogra> seb128, for package foo replaces package bar ...
<seb128> if you want to transition you have to use Provides too
<ogra> Amaranth, honestly, i tend to trust Keybuks knowledge
<Amaranth> seb128: well, yeah
<Amaranth> but those are all supposed to do different things, we're using them wrong
<mjg59> Ok, fixed g-p-m
<Amaranth> oh well :D
<seb128> speak for you
<Simira> who is in charge of time-admin?
<ogra> mjg59, thanks :D
<seb128> Simira: upstream? :)
<ogra> Simira, dholbach 
<ogra> *g*
<seb128> Simira: dholbach/mvo/me
<Simira> seb128: preferrably. I'm stuck in a wrong timezone
<seb128> Simira: dholbach|mvo|me rather :)
<ogra> Simira, thats locales/glibc ... was fixed by jbailey iirc
<seb128> Simira: how "stuck"? what version of the locales package do you have?
<ogra> try an upgrade 
<Simira> ogra: there are none
<ogra> hmm
<Simira> seb128: time-admin doesn't work, and the last update changed my time zone, for some reason
<Simira> to utc
<pitti> mjg59: ok, so after Scott's lengthy rant^Wexplanation, it seems to me that g-p-m Conflicts:/Replaces: pbbuttonsd shoudl actually be fine?
<mjg59> Sure
<seb128> Simira: what version of the locales package do you have?
<pitti> so I don't understand the excitement 
<pitti> introducing virtual packages for all pairs of semantically conflicting packages is certainly not what we want
<ogra> pitti, i understand that its not fine, unless you have two conflicting files ..
<pitti> (s/pairs/sets/)
<mjg59> ogra: This isn't true
<seb128> pitti: the discussion was that xscreensaver/gnome-screensaver which don't require any sort of Conflicts technically
<Simira> seb128: 2.3.10
<pitti> ogra: according to scott, using Conflicts: *alone* is a problem, and I perfectly understand that
<seb128> Simira: hum, that should work fine with that one :/
<ogra> mjg59, this is what he told me in /query as well as the aforementioned bug
<mjg59> xscreensaver/gnome-screensaver shouldn't conflict because there is no conflict of function
<mjg59> g-p-m/pbbuttons probably should, because there is a conflict of function
<seb128> ogra: that was not quite the same situation
<seb128> your conflict had no reason to be
<Simira> seb128: it worked when Tollef watched, for some reason
<pitti> right now pbbuttonsd and g-p-m fight with each other, and I get really strange effects
<Simira> seb128: but I didn't have locales installed, though
<Simira> until now
<seb128> pitti: I think everybody out of ogra agree you should use C/R for it :)
<seb128> Simira: that was your issue so
<ogra> seb128, i tend to agree, but still there are no conflicting files in the packages and i dont know about functional conflicts
<Simira> seb128: probably. Thanks anyway
<pitti> ogra: I do :)
<seb128> Simira: complain to jbailey when he's around than an upgrade let you without locales installed :)
<pitti> ogra: in fact, it function-conflicts with gnome-settings-daemon, too, but we didn't make that explicit so far since we needed the other bits of pbbuttonsd
<pitti> mjg59: it seems that in the near future we need to extent pmi's interface to cover power source changes
<pitti> mjg59: /etc/apm scripts support that at least
<ogra> pitti, i'm just very careful since i had to learn it the painful way and its still how i understood Keybuk 
<ogra> pitti, up to you if you want to interpret it differently
<Kinnison> mjg59: thanks for that upload to g-p-m
<ogra> pitti, but i think the part about virtual package names in the bug might apply 
<Amaranth> err, don't xscreensaver and gnome-screensaver both try to lock the screen?
<Amaranth> i guess gnome-session would have to start both of them for that to be a problem though
<ogra> Amaranth, yes
<seb128> Amaranth: only one is started
<ogra> and gnome-screensaver had a Replaces as well back then 
<ogra> even if the bug only states the conflicts
<seb128> could you move that to #random-discussion-place? :)
<Amaranth> so until we get the redesigned gnome-session... :)
<seb128> ?
<seb128> what are you talking about
<seb128> gnome-session starts gnome-screensaver first and fallback on xscreensaver if it's not installed
<seb128> what do you want to redesign?
<Amaranth> seb128: i thought gnome-session was being completely redone for 2.16
<Amaranth> using .desktop files in /usr/share/autostart or something to decide what to start in the session
<seb128> that change is already in current dapper version ...
<seb128> and that's a new feature, nothing has been redesigned
<Amaranth> err, so shouldn't packages handle whether or not they're added to the session?
<seb128> they do
<Amaranth> and not the gnome-session package
<Amaranth> ok...
<Amaranth> *sigh*
<seb128> g-p-m, n-m, g-v-m install a .desktop to /usr/share/autostart
<Amaranth> i should just stop coming to these channels until the end of march when i'm actually using ubuntu again
<seb128> I just have to debug why the feature doesn't work atm, that might be a distro patch breaking it
<Amaranth> oh, that reminds me, alacarte and pyxdg will get no love from me until dapper+1
<seb128> no big change :)
<Amaranth> heh
<seb128> they have not changed for months now :)
<Amaranth> a couple of bugs still though
<Amaranth> iirc one of the bugs has been fixed in pyxdg cvs for about 6 months
<seb128> do you have a cvsdiff or something?
<seb128> maybe we should patch the package
<Amaranth> i don't even have access to cvs
<Amaranth> the program, i mean :P
<Amaranth> and it was a series of cvs commit's, i'll have to piece together which ones actually fixed it
<seb128> http://cvs.freedesktop.org
<Amaranth> someone else said they wanted to take over pyxdg maintainership, i wish i could remember who
<seb128> in case you have access to some kind of internet browser
<Amaranth> seb128: yeah, lanius committed it weird
<Amaranth> seb128: it's a couple of different commits, i think because he got it wrong and didn't test before committing
<seb128> what file has the change?
<Amaranth> Menu.py
<Amaranth> http://cvs.freedesktop.org/pyxdg/pyxdg/xdg/Menu.py?r1=1.142&r2=1.143
<Amaranth> there's a start
<Amaranth> but the diff is on top of all the other unicode fix attempts
<zyga> hello
<zyga> Amaranth: hi
* Amaranth points at zyga 
<Amaranth> good luck :P
<zyga> what's up?
<zyga> what unicode fix attempts?
<Amaranth> it'd be nice if pyxdg in dapper could get the utf-8 fixes and tryexec support from cvs
<lfittl> BenC: ping
<Amaranth> if someone has non-utf8 data in their .desktop file, pyxdg will die trying to read it
<Amaranth> cvs has a fix
<zyga> Amaranth: are those fixes in cvs?
<zyga> k
<zyga> I'll look at them today
<Amaranth> actually, i think it only fixes non-utf8 filenames
<zyga> is there a bug number?
<Keybuk> pitti: C/R is fine, I'd also recommend one of the packages was dropped from the archive
<Keybuk> because otherwise we get bitten when we change our minds before release
<Keybuk> like we *ALWAYS* do
<Amaranth> bug 25699
<Ubugtu> malone bug 25699 in pyxdg "smeg won't start at all!" [Normal,Unconfirmed]  http://launchpad.net/bugs/25699
<zyga> Amaranth: thanks
<Amaranth> and 29961
<ogra> Keybuk, so i misunderstood it ? 
<Keybuk> ogra: conflicts or replaces on their own are bad unless you mean what they mean
<Keybuk> together they *can* do what you want
<Keybuk> but only if you're never, ever, going to change your miund
<Keybuk> e.g. udev conflicts and replaces hotplug
<pitti> Keybuk: well, we don't want to drop pbbuttonsd from the archives
<Keybuk> pitti: then you don't want C/R
<pitti> Keybuk: I'd like to push it out of desktop
<Keybuk> pitti: you instead want to make mvo's magic upgrade tool uninstall it
<Keybuk> desktop or main?
<pitti> Keybuk: desktop primarily
<pitti> it's still good for xfce etc.
<pitti> and we can uncripple pbbuttonsd again
<Kamion> I think we also need to make the consequences of having them simultaneously installed much less bad
<pitti> if we use g-p-m
<Kamion> because not everyone will be using mvo's magic upgrade tool
<Keybuk> the problem is that we're bound to change our minds and not ship g-p-m
<pitti> and if we don't use g-p-m, then the c/r won't hurt
<Kamion> for example each could refuse to start if the other's running
<Keybuk> we've done this every damned release so far
<Keybuk> kamion++
<Kamion> that would be much safer and simpler IMO
<Amaranth> maybe g-p-m could stop the pbbuttonsd daemon when it starts?
<Kamion> and wouldn't cause massive package manager pain
<pitti> Amaranth: no
<pitti> Amaranth: g-p-m runs in the user's session, pbbuttonsd is a system daemon
<Amaranth> hrm
<Amaranth> pbbuttonsd could see if g-p-m was installed?
<pitti> Kamion: but if we make g-p-m not doing anythign at all if pbbuttonsd is running, then we can as well not install it at all
<pitti> Amaranth: no, because not everyone uses gnome
<pitti> Amaranth: you do want pbbuttonsd for !gnome
<Kamion> pitti: then make pbbuttonsd not start up if g-p-m is installed?
<pitti> so that should be sorted out in the *-desktop metapackages
<Kamion> that would work on the next reboot
<pitti> Kamion: well, *that* seems hackish to me
<Kamion> and is no worse than Conflicts
<Amaranth> pitti: ok then, doesn't gdm run as root? :)
<Kamion> and a hell of a lot less painful for package managers to resolve
<pitti> Kamion: what's so bad about having two alternative solutions for a common problem and declarign a C/R about it? maybe I'm blind, but I still don't understand the fuss about it
<pitti> the final u-desktop should depend on whichever solution we eventually want, and the c/r would make sure that the transition works either way
<Kamion> pitti: because when we change our mind and want to switch back to pbbuttonsd, package management tools will start claiming that the sky is falling
<Keybuk> Kamion: not for the first time, I wish for a testing/*_probs history
<pitti> Kamion: how did we solve the notification-daemon -> notify-daemon and back case?
<pitti> mvo: ^ ?
<Kamion> pitti: notify-daemon has gone from the archive, which is sufficient for upgrade tools to work it out, AIUI
<pitti> hm, so if I have notify-daemon installed, then the dpkg behavior when upgrading to notification-daemon depends on whether or not some mirror has a file? that seems weird to me
<pitti> in any case, I'm opposed to make them both work together, but I would actually like to uncripple pbbuttonsd
<pitti> right now it's half-useless with gnome, and half-useless without gnome
<Kamion> pitti: it's not dpkg behaviour, it's apt behaviour, and apt knows about whether packages are available ...
<pitti> I see
<Keybuk> pitti: apt behaviour
<Keybuk> pitti: "I have foo installed, which C/R bar, which is a dependency of meta which I also have installed"
<Keybuk> MOMMY HELP!!!!!!
<Kamion> AIUI unavailable packages are scored down, although I might be making that up
<Treenaks> I want XGL for DAPPER!#
<Keybuk> the only way to fix the problem is to violate the user's package choices
<Treenaks> :P
<ogra> Treenaks, pfft
<Keybuk> Kamion: installed=100, available=500
<Treenaks> ogra: or at least dapper+1 :)
<ogra> Treenaks, pfft+1
<Treenaks> ogra: how about a pony then?
<pitti> Keybuk: ok, so the only other sane thing I can see is to make g-p-m not start if pbbuttonsd is running
<ogra> Treenaks, youre a MOTU, just package it for universe ;)
<Kamion> Keybuk: where's that done?
<pitti> i. e. breezy->dapper upgrades will continue to use pbbuttonsd, and fresh installs will have g-p-m
<Treenaks> ogra: actually.. xserver-xgl is packaged
<Keybuk> Kamion: inside apt somewhere
<Treenaks> ogra: but universe can't really be a default, can it :)
<ogra> pitti, just make mvo's tool sort it ...
<Kamion> I think the numbers must have changed then
<Keybuk> and 100 is the magic apt barrier for something
<Keybuk> Kamion: not recently, it's been 100/500 for as long as I can remember
<pitti> ogra: that can happen independently then
<ogra> Treenaks, i doubt it will be ready enough to be a default before dapper+3
<Keybuk> (it's certainly 100/500 on my woody box)
<Kamion> 500 doesn't match anything relevant here
<Treenaks> ogra: isn't Novell pimping it for NLD10 ?
<Kamion> oh, hang on, missed one
<Kamion> ok, maybe that's it in pkgPolicy::InitDefaults, would have to remember how more of apt works to understand it properly
<ogra> Treenaks, are we novell ? 
<pitti> ogra: yay, sound on ppc is back
<pitti> BenC: thank you! ^
<Treenaks> ogra: Maybe :)
<ogra> pitti, what did you do to get it working ? 
<Amaranth> Treenaks: NLD10 won't be out until the end of the year
<ogra> it doesnt work here 
<Treenaks> Amaranth: dapper+1 then :)
<Keybuk> Treenaks: +2 more like
<Treenaks> Amaranth: won't be out before october :)
<Keybuk> Novell seem to be clinging onto their patches and not releasing them
<pitti> ogra: nothing actually, it just worked now after unmuting
<ogra> hrm
<Treenaks> Keybuk: yeah, that's bad...
<Treenaks> Keybuk: They 'open up' a bunch of stuff in one go
<pitti> ogra: in my last boot, everything was unmuted and I still didn't hear anything
<Amaranth> Keybuk: they're at least making code dumps now
<Treenaks> then leave it, and dump a load of patches on it every $long_time
<pitti> ogra: maybe something the alsa scripts did on shutdown/next reboot/when the moon phase advanced
<Amaranth> Keybuk: if they hang on too tight the code available will go a different direction
<ogra> i tried everything ... i even found where Keybuk has hidden the alsa powermanagement now :P
<ogra> but no sound for me :(
<Amaranth> Keybuk: that started happening, they freaked and released the new code
<Treenaks> ogra: Powerbook/ibook? because I've had sound on my mac mini since the _previous_ kernel upgrade
<Keybuk> ogra: alsa power management? :p
<Keybuk> ogra: it's in the same place as before
<Treenaks> Keybuk: 'APM'
<ogra> Keybuk, oh, was the initscript only a link to apm ?
<pitti> ogra: but now I don't get /dev/sda1 for my usb stick any more
<Keybuk> ogra: the init script was only called by the apm script.d file
<pitti> ppc is doomed *sniff*
<ogra> Treenaks, todays kernel upgrade is supposed to fix it
<ogra> Keybuk, oh, how silly
<Keybuk> pitti: quest has the neat "root fs is sdg" bug
<Treenaks> ogra: I hope it doesn't break it again for me then :)
<Keybuk> looks like I'm going to have to fix that <g>
<Treenaks> ogra: also, I haven't actually seen that kernel in my upgrade yet
<ogra> ok, lets try another reboot
<mullen_> Kamion: ping
* Mez|Work growls
<Mez|Work> I tried a flight 3 install with LVM
<Mez|Work> and that failed.
<Kamion> Mez|Work: hmm?
<Mez|Work> now It wont get to the partioner - it freezes.
<Kamion> if you mean the automatic LVM setup, that's fabbione's baby
<Mez|Work> any ideas Kamion: seeing as you're the installer guy
<Mez|Work> ah well
<Mez|Work> it failed
<Kamion> switch to alt-f2 and hit 'ps x' to see what it's doing
<Mez|Work> and now I get stuck just before loading the partiioner
<Kamion> last couple of processes, excluding sh and ps x
<Mez|Work> will do
<Mez|Work> give me a mo to reboot it though and get to that point
<Mez|Work> was gonna reformat hard drive with windows 98 :D
<Kamion> /var/log/partman may also help
<Mez|Work> It's at the "scanning disks" phase it stalls
<Mez|Work>  It's runing parted_server
<Mez|Work> as the last process
<Kamion> that's not meaningful - any particular /lib/partman/ script?
<Mez|Work> and init.d/30parted
<Kamion> oh, is there by any chance more than one parted_server running?
<Keybuk> hmm, the x-chat notification icon has suddenly become FIST SIZED!
<Mez|Work> only one running
<Kamion> try killing off everything parted_server/partman-related and trying again
<Kamion> that sort of thing can sometimes happen if partman dies very hard
<Mez|Work> it;s doing same thing
<Keybuk> seb128: apparently is all your fault ;)
<Mez|Work> and this is after about 7 reboors
<Mez|Work> reboots *
<Kamion> Mez|Work: anything interesting in /var/log/partman?
<seb128> Keybuk: I blame dholbach, he's the icon guy :)
<Mez|Work> parted_server: OUT: ok
<Kamion> Mez|Work: putting it somewhere I can see it is probably easiest, it's not an easy log to read
<seb128> the xchat-gnome icon is fine
<Mez|Work> Kamion : I can try and email it to you
<Mez|Work> whether that'll work i dunno
<Kamion> that's an example of a very uninteresting line in /var/log/partman :-)
<Kamion> e-mail, stick on web, whatever
<seb128> but right, gnome-icon-theme guys are on crack, we will probably revert to one of the previous version for that GNOME
<Mez|Work> it's 34 lines long
<Mez|Work> well I';m not sure how to get it from a machine thats installing to the web tbh
<Kamion> back up to the main menu and select "Save debug logs"
<Kamion> or switch to alt-f2 and 'anna-install openssh-client-udeb' to get scp, if you prefer
<Mez|Work> Kamion: for some reason it's unstalled itself - it's now somewhere else
<Kamion> I need the logs before you perturb the situation much more :)
<Mez|Work> well I'm not doing anything - just watching the log file :D
<Mez|Work> oh, and it's behind an annoying proxy
<Mez|Work> Kamion: I beleive it fixed itself :D I'll shout back in a mo if not
<ogra> pitti, no sound :(
<Mez|Work> I've got the partioner up and running now
<Kamion> Mez|Work: I'd still like the log file if possible
<Kamion> something that takes 7 reboots to fix itself isn't really all that fixed
<Treenaks> it _is_ a special number (7)
<Mez|Work> Kamion: It had no HDD activity etc etc ....
<Mez|Work> Kamion: does it save the logs to anywhere- because I've no idea how to get back out to the menu or if I even want to now :D
<Mez|Work> actually
<Kamion> 18:03 < Kamion> or switch to alt-f2 and 'anna-install openssh-client-udeb' to get scp, if you prefer
<Mez|Work> I can copy the logs to the target 
<Kamion> no
<Kamion> it will save them to /var/log/installer/ itself if you actually manage to complete an installation
<Mez|Work> ok
<Mez|Work> well - I'll send you them once it's completed
<Mez|Work> I'll actually be able to get to some sort of FTP site then :D
<Mez|Work> It's installing the base system anyways :D
<Kamion> thanks
<Kamion> obviously I don't know if I'll be able to do anything with them, and we probably won't be able to verify any fix now anyway
<Mez|Work> colin.watson@canonical.com ?
<Kamion> cjwatson@ubuntu.com preferred
<Kamion> though the above works
<Mez|Work> Kamion: if they help - they help :D if they dont - hey - it's only bandwidth (and not mine)
<Amaranth> fish fries?
<jbailey> Simira: What issue are you having?
<ogra> pitti, Kamion, Keybuk any news aboput inputattach ? i really need ltsp installable soon...
<Kamion> ogra: I'm waiting for elmo to tell me how to change overrides in soyuz
<ogra> Kamion, ah, fine then ...
<Kamion> bugging pitti and Keybuk won't help you in the least
<ogra> Kamion, didnt know on whose table it currently was ...
<elmo> Kamion: what needs done?
<Kamion> elmo: inputattach -> main
<Kamion> also python2.4-soappy -> main, IIRC
<Kamion> pitti's oked the former and the latter is just a binary from source already in main
<Surak> hello
<elmo> Kamion: should be done now, I'll hopefully get the stuff cleaned up and instructions to you and mdz later
<ogra> hmm, intrestingly LP always showed it in main ...
<Surak> Hi, I have trouble compiling linuxant's hsfmodem for breezy amd64. the error message is: "Unknown Debian architecture x86_64, you must specify GNU system type, too at /usr/bin/dpkg-architecture line 214.
<Surak> dpkg-buildpackage: unable to determne host architecture
<Mez|Work> Kamion: logs sent - from mezzle@gmail.com
<Mez|Work> Subject: Installer logs
<Simira> jbailey: on my last update (yesterday), time-admin was updated, but it did not install locales. So time manager sat my time zone to utc, and I wasn't allowed to change it (or any other time issue).
<ogra> hmm
<ogra> http://fridge.ubuntu.com/event
<ogra> looks quite funny in my firefox
<ogra> (the tabs spread across the calendar)
<jbailey> Simira: locales are depended on by ubuntu-minimal.  How did you not have it installed?
<jpatrick> ogra: same here in Konqueror
<ogra> jpatrick, ah, fine, so its the css, not the browser ... calming
<Simira> jbailey: I don't know. I think it was uninstalled by some update I did
<jbailey> Simira: Something to watch for in future upgrades, anyway.
<Simira> jbailey: I probably need a hint on what logs to check
<stratus> ogra: calm down yes
<stratus> ogra: you are always a reload away from the fix
<jbailey> Simira: All the logs get rotated, so there's no promise that you'd even find it.
<jbailey> Simira: Given that we know the problem, though, I wouldn't worry about it.
<stratus> ogra: it's happening with a lot of websites.
<Simira> jbailey: ok, thanks
<sistpoty> elmo: is it possible to have universe test-rebuilt like it was done for breezy?
<janimo> ogra, you know anything more about the gdm themese issue than it is on LP?
<ogra> janimo, seb128 promised to look at it ...
<janimo> thanks
<ogra> are you in a hurry with the artwork ? 
<janimo> not really just planning
<ogra> artwork deadline is still far out ...
<ogra> we can already use the alternative etc ... seb128 will pick it up with gdm ...
<janimo> do you already provide an alternative in edubuntu-art?
<janimo> to etc/gdm/gdm.conf.deriv I mean
<ogra> nope, not yet 
<ogra> but we should have that ready before feature freeze (23th)
<ogra> err
<ogra> 23rd 
<janimo> ok thanks
<Kamion> elmo: great, thanks
<Kamion> ogra: source was in main, binaries weren't
<Kamion> Mez|Work: thanks
<ogra> Kamion, oh ... yes ..
<ogra> mjg59, regarding the screen lock complaints on lid close, do you also think we should have a "only lock screen" option in g-p-m preferences ? 
<Bombshell> !list
<jpatrick> Bombshell: huh?
<daved> i've got a stumper involving breezy amd64, pam, and vmware gsx..
<daved> Feb  7 14:48:34 virtual01 vmware-authd[14351] : PAM unable to dlopen(/lib/security/pam_unix.so)
<daved> that file most certainly exists (the next line in the log after that is No such file or directory)
<daved> so i'm wondering if there is a /lib /lib64 /lib32 issue going on here trying to load the pam modules
<daved> ldd of the binary shows    libpam.so.0 => /lib32/libpam.so.0 (0x55573000)
<daved> i can't find any package that would introduce pam modules into /lib32/security
<daved> #ubuntu sent me here, so i apologize if this isn't the proper place to get support
<elmo> does anyone know if it's possible to override dpkg's sense of architecture when building a source package?
<tseng> elmo: the man page shows a --force-architecture
<elmo> that's for installing
<ogra> only through changing the control file afaik...
<jbailey> elmo: It looks like dpkg-buildpackage has a -a option.
<ogra> to be used with the -d option
<elmo> right, but this source is building a mixture of architectures
<elmo> not to worry, I just wandered if anyone knew off hand, if not, I'll mess around and figure something out
<jbailey> I probably played with something like this early on with Hurd stuff, but haven't looked at it in forever.
<Keybuk> ok then mr computer, why won't you boot?
<elmo> mvo: grr, breezy broke --print-uris as non-root, is that known/fixed in dapper?
<Keybuk> oh, I see why you won't boot
<Keybuk> because you're all wet inside!!
<mvo> elmo: what is broken? apt-get --print-uris install ? update?
<elmo> mvo: install
<elmo> mvo: specifically, I'm running 'apt-get -qqq -y --print-uris --reinstall install libc6 libncurses5'
<elmo> which works with hoary, breaks on breezy
<mvo> $ apt-get -qqq -y --print-uris --reinstall install libc6 libncurses5 -o Debug::NoLocking=true
<mvo> 'http://archive.ubuntu.com/ubuntu/pool/main/n/ncurses/libncurses5_5.5-1ubuntu3_i386.deb' libncurses5_5.5-1ubuntu3_i386.deb 291404 5e1677c5d6f5995855a4a2cfb9e272c0
<mvo> that is dapper, I'm checking breezy now
<elmo> ah, ok, the intuitively named Debug::NoLocking works for breezy too
<mvo> elmo: oh, so the problem is that it tries to lock in breezy?
<elmo> mvo: yes
<mvo> elmo: let me check that
<mvo> elmo: sorry for the inconvenience I hope using NoLocking=true helps for now
<elmo> mvo: that's fine, thanks :)
<pygi> hello, anyone that can kick people in #ubuntu?
<elmo> mvo: apt-get -o Debug::NoLocking=true --print-uris --reinstall install libc6 libncurses5 libstdc++2.10-glibc2.2
<elmo> mvo: any idea why that wouldn't print a URI for the last pkg?
<elmo> oh, it's cached
<elmo> so much hate
<mvo> :/
<pygi> ah, well :) will be better :P
<elmo> mvo: 'tis ok, -o Dir::Cache=/die/screaming/apt/die works ;-)
<elmo> well once I create /d/s/a/d/archives/partial/ anyway
<Skenvoy> dead easy question: how do i specify a file pointer as an argument to a function in C
<spacey> any  idea how i can find out why Xorg takes 50% cpu after reboot
<slomo_> spacey: update-notifier maybe?
<mvo> Skenvoy: sorry, this is not a support channel for programming, please try somewhere else
<Skenvoy> <_<
<slomo_> spacey: it was doing such weird things for me lately
<pygi> mvo: join ##c
* mvo kicks update-notifier
<Skenvoy> people familiar with C blatantly hang out here :P
<pygi> skenvoy: lol :))
<pygi> sorry mvo, wrong person :)
<Skenvoy> k, will try :P
<mvo> good luck :)
<Skenvoy> ta
* pygi feels lost in so many channels :)
<spacey> slomo_ update notifier takes like 20% cpu
<slomo_> spacey: try killall update-notifier
<slomo_> spacey: i bet your cpu usage of Xorg is gone then :)
<spacey> yup
<spacey> just did
<spacey> slomo know of a filed bug regarding the problem?
<mjg59> ogra: Yeah, I've been thinking that
<spacey> anyway i can't find it
<slomo_> nope... mvo do you know about this problem already?
<spacey> guess i'll file one
<ogra> mjg59, i'll add a patch for it during the week then :)
<mvo> slomo_, spacey: known problem, working on a fix
<spacey> mvo: so no need to file bug?
<mvo> spacey: no, thanks
<spacey> ok
<mjg59> ogra: Cool
* ogra fears he loses all his C skills over ltsp scripting ... 
<ogra> need to do smoe C stuff inbetween :)
<neuralis> ogra: after a year of python, my c went down the drain ;)
<Simira> isn't ekiga in Debian? I have a friend that can't find it
<pitti> ogra: C is indeed something more people should forget about :/
<ogra> neuralis, i usually try to change between C python and scripting ...
<neuralis> pitti: hear hear.
<ogra> pitti, was that meant as a secret hint ?
<ogra> :)
<pitti> ogra: no, just a general attitude after having better alternatives (for most tasks anyway) for decades
<ogra> yup :)
<ogra> yay, my ibook has an f-spot :)
<ogra> thanks slomo_ , works fine 
<seb128> Simira: maybe it's in NEW, or maybe they have not uploaded it yet
<pitti> ogra: I'm *so* glad that it's not a gnome app starting with 'g'
<neuralis> pitti :-D
<ogra> hehe
<Simira> :D
<pygi> :P
<seb128> we should get f-spot on the default desktop
<neuralis> pitti: actually, there's a (win32) application called g-spot that extracts codec information from video files, afaik
<neuralis> seb128: f-spot, tomboy, and beagle, hopefully
<seb128> no no no
<tseng> neuralis: not really dude
<seb128> beagle is not ready for that
<tseng> pass the pipe
<ogra> only f-spot
<tseng> beagle can be dapper+1 imo
<neuralis> oh, you meant for dapper? 
<seb128> yep
<pygi> still too unstable and unreliable
<tseng> seb128: did you figure out how to get mono onto the cd
<neuralis> i was talking post-dapper. 
<tseng> well then yes
<tseng> tomboy less than the others
<seb128> tseng: no, I was waiting on you or slomo to do some estimation on how much CD place is required for that
<tseng> its nice, but im not sure it warrants a mono process in the default install
<tseng> (all the time)
<neuralis> tseng: that's probably true.
<seb128> tseng: did you do the wiki page for beagle/main?
<seb128> I still want to build nautilus with libbeagle
<tseng> seb128: hm no
<tseng> it needs gmime2.1 and beagle -> main yet
<seb128> before feature freeze would be nice :p
<neuralis> then again, tomboy's one of the shiny things that non-linux people love to play with when i show it to them.
<tseng> i just did a report to UVF update beagle
<ogra> neuralis, while youre here ... do you have any clue how openssi solved the cross access to /dev over the different nodes ? 
<tseng> to make everything work again
<seb128> first step :)
<seb128> do you know if somebody did one for f-spot?
<neuralis> ogra: /dev is a cdsl, if i remember correctly
<tseng> seb128: ajmitch_ is supposed to
<seb128> having the new version would be nice
<seb128> cool
<ajmitch_> seb128: I will, I've got 0.1.8 ready to upload to debian
<tseng> seb128: if he doesnt i will do it and kick him around a bit
<seb128> ajmitch_: thank you
<seb128> tseng: thank you too :)
<slomo_> seb128: i'll take a look at how much space would be used tomorrow... but before we put that stuff on cd we need to fix mono on ppc... otherwise the ppc cds will fail to be created :/
<ajmitch_> seb128: the major change to go into main will be changing to sqlite 3
<ajmitch_> which will of course break everyone's install
<tseng> seb128: ugh
<tseng> er
<tseng> slomo_: ugh
<seb128> ajmitch_: not cool
<seb128> slomo_: yeah, better to fix that
<tseng> seb128: dude we are pretty stuck on the mono ppc stuff
<tseng> seb128: because.. no one outside canonical has ppc-smp
<ajmitch_> seb128: I know, but I don't know if there's an easy way to fix that apaer from shipping a migration script
<ajmitch_> seb128: a python script to dump & reload the db shouldn't be hard, it just needs written
<ogra> neuralis, i was wondering if that could be the solution for local device acces in ltsp ...
<slomo_> ajmitch_: you could hack the f-spot shell script to do the conversion if an old database is found
<ajmitch_> slomo_: I could, but that requires that the sqlite 2 & 3 command line utils be installed
<neuralis> ogra: probably not without serious kernel hacks
<ogra> neuralis, since i think the *real* solution is to have a secured access to the clients /dev from the server ... 
<ogra> yes, i was suspecting that 
<ajmitch_> which won't happen for most f-spot users (they'll only have the lib)
<slomo_> ajmitch_: oh yes... i didn't think about that
<tseng> like i said once before
<tseng> if someone already has f-spot installed they have universe enabled
<ajmitch_> slomo_: it's painful either way
<tseng> and have sqlite2
<tseng> if they are installing fresh, they have no db
<neuralis> ogra: if it were possible, it'd probably be the most elegant solution, but it's impractical
<slomo_> seb128: at least the people who have enough knowledge to fix it don't have access to a smp ppc... do you know someone who could give shell access to one?
<ajmitch_> tseng: yes, which doesn't help if it's automatic, since f-spot never depended on the util, just the lib
<tseng> blargh
<ogra> neuralis, our kernel already has ocfs support builtin ... probably something is possible on top of this 
<tseng> im off
<tseng> cya
<ajmitch_> bye
<neuralis> ogra: hmm
<sistpoty> cya tseng
<neuralis> ogra: i'd be pretty careful about going that route
<slomo_> bye tseng 
<ogra> neuralis, sill plenty of time until dapper+1 ...
<seb128> slomo_: nop :/
<neuralis> slomo_: i can probably get you a ppc smp shell
<ajmitch_> neuralis: that would be great, this problem has been unfixable for awhile
<slomo_> neuralis: that would be perfect :) it wouldn't be for me but for one of the mono devs
<neuralis> do you require ubuntu on it, or is osx fine? (i'm unfamiliar with the problem you're trying to solve)
<neuralis> ogra: sure, but how are you going to secure ocfs? and it would still require non-trivial kernel hacking, i think
<slomo_> neuralis: ubuntu... or some other linux distribution... the problem doesn't show up on os x from what we know
<ogra> neuralis, i havent looked at it at all yet ... its only a weird idea ...
<neuralis> slomo_: hm. that i might not be able to do. i'll send out some e-mails and let you guys know if i come up with anything.
<slomo_> neuralis: thanks :)
<neuralis> slomo_: sure. sent to a few people at mit genetics, i seem to recall they have a bunch of smp ppcs on hand.
<slomo_> neuralis: ah... and we need a 32 bit userland on them... no idea if it shows up in a pure 64bit environment
<neuralis> slomo_: i asked if they have one that i can just borrow, so if they do, i can put whatever you need on it
<Keybuk> yup
<Keybuk> definitely know why this pc doesn't work
<slomo_> neuralis: great :)
<Keybuk> diagnosis: the coolant isn't supposed to leak all over the motherboard and cards
<ogra> Keybuk, awww ... watercooled ? 
<elmo> is there some way to feed stuff to a serial console, short of expect + minicom ?
<Keybuk> ogra: yes, quite literally it seems
<ogra> ouch
<Keybuk> *shrug* it can go back :)
<Keybuk> and then I can wait another few weeks for a new one <g>
<ogra> if it still works with all the liquid on it ? 
<Keybuk> it doesn't work
<Keybuk> well, that's not true
<Keybuk> it worked for nearly three second
<Keybuk> then it stopped working
<slomo_> neuralis: when you get an answer can you write me a mail? :) slomo@ubuntu.com
<neuralis> slomo_: sure. i'm not too hopeful (it's a lot easier to get an osx shell than to borrow lab hardware), but it's worth a try.
<slomo_> neuralis: do you need to tell them a reason or can you just ask for hardware there? :)
<ogra> Keybuk, i rather meant if it will work again if dried ...
<Keybuk> ogra: no idea, it still leaks
<Keybuk> so it'd get itself wet again pretty quickly
<Keybuk> I'm going to suggest they just build another one, rather than trying to give me components that have already had a wash ;)
<Keybuk> amusingly it's leaking directly onto the main bus
<ogra> heh
* Keybuk makes it leak some more, so they can't pull a fast one
<neuralis> Keybuk: evil :)
<Keybuk> lol, I know I would
<Keybuk> I'd just replace the bit of leaky pipe and mop up the spillage
<Keybuk> "if it boots, ship it back"
<ogra> heh
<Keybuk> oops
<Keybuk> so that made it drench the graphics cards and switched itself off
<ed1t> do i wanna grant "stopThread" in jre installation?
<tiredbones> I'm getting a seg fault while upgrading to breezy from hoary. The module is python2.4-minimal, how do I work around this/
<LadyNikon> greetings
<LadyNikon> I am having the same issue as this :https://launchpad.net/distros/ubuntu/+source/vpnc/+bug/29727
<Ubugtu> malone bug 29727 in vpnc "vpnc: missing script vpnc-connect" [Normal,Unconfirmed]  
#ubuntu-devel 2007-02-05
<Robot101> thom: are you going to fosdem? :)
<Kano> hi, when will be a kernel based on 2.6.20 final?
<mjg59> Soon
<Kano> you should check for working nvidia drivers... there was a change since rc6
<mjg59> The most recent kernel is post-rc6 anyway
<Kano> but not final?
<crimsun> mjg59: when the latest patch_sigmatel changes are merged, feedback from testing on your Intel Mac would be appreciated
<Kano> why dont you use only libata?
<mjg59> crimsun: Don't have one right at the moment, but when I do again I will do
<mjg59> crimsun: cjwatson has the one I used to have
<crimsun> mjg59: ah ok, many thanks
<mjg59> Kano: Because not all libata drivers are complete
<Kano> which aren't?
<Kano> isnt it a bit stupid to have both the same time
<Kano> piix 0x00008086 0x0000245b
<Kano> ata_piix 0x00008086 0x0000245b
<Kano> both for same hardware
<Kano> with that there are 229 pci ids with more than one driver
<Kano> grep drivers/ata modules.dep |sed -r 's/.*\/(.*)\.ko:.*/-e \1/'|sort -u|xargs grep modules.pcimap|awk '{print $2" "$3" "$4" "$5" "$6" "$7" "$8}'|sort -d|wc -l
<Kano> 229
<Kano> or 31 modules which share pci ids
<Kano> grep drivers/ata modules.dep |sed -r 's/.*\/(.*)\.ko:.*/-e \1/'|sort -u|xargs grep modules.pcimap|awk '{print $2" "$3" "$4" "$5" "$6" "$7" "$8}'|sort -d|sed -r 's/(.*)/-e "\1"/'|xargs grep modules.pcimap|cut -f1 -d' '|sort -u|wc -l
<Kano> do you really think thats usefull
<kylem> of course they share ids. they both support the same hardware.
<Kano> but they could not work the same time
<kylem> so?
<Kano> only one of em
<Kano> maybe better find pci ids which are only supported by old ide 
<Kano> grep drivers/ide modules.dep|sed -r 's/.*\/(.*)\.ko:.*/-e "^\1 "/'|sort -u|xargs grep modules.pcimap|awk '{print $2" "$3" "$4" "$5" "$6" "$7" "$8}'|sed -r 's/(.*)/-e "\1"/'|xargs grep modules.pcimap|awk '{print $2" "$3" "$4" "$5" "$6" "$7" "$8}'|sort|uniq -u|sed -r 's/(.*)/-e "\1"/'|xargs grep modules.pcimap|sort -u|wc -l
<Kano> 71
<Kano> uniq ids only for old driver, but these could be matched by generic patterns maybe too
<Kano> which are preffered?
<Kano> in case of dups
<Kano> any special probing sequence?
<xhaker> crimsun, noticed your upload of alsa-lib, and I have something I feel you're the one to ask.
<xhaker> crimsun, what alsa version for the final feisty release?
* xhaker is one of those using acer + alc883
<crimsun> xhaker: which part of alsa are you asking about?
<crimsun> xhaker: alsa-lib will be 1.0.13 with any appropriate bugfixes backported from hg
<crimsun> xhaker: alsa-kernel (via linux-source-2.6.20) will be a mash of current hg and 1.0.14rc2
<crimsun> xhaker: -utils will be 1.0.13 with any appropriate bugfixes; -tools will be 1.0.14rc; -firmware will be 1.0.14rc
<xhaker> thanks crimsum, i'll wait and see, looking forward to 2.6.20 final and new alsa
<carebear666> if you ever try to kick me or ban me i will get my uncle(irc opp) after you and by the way i have a nuke and a mail bomb on the way asshole
<carebear666> if you ever try to kick me or ban me i will get my uncle(irc opp) after you and by the way i have a nuke and a mail bomb on the way asshole
<concept10> anyone around
<thom> Robot101: yes
<mjg59> Win
<glatzor> morning mvo_ Riddell
<mvo_> hey glatzor!
<glatzor> mvo_: Riddell: I several issues in software-properties and python-apt. would be nice if you you upload them mvo_
<mvo_> glatzor: merging python-apt now
<glatzor> mvo_: the update-manager separation branch is also up-to-date
<mvo_> glatzor: I will merge that one next and upload them 
<glatzor> mvo_: thanks a lot
<mvo_> glatzor: cheers! thanks for working on the branch!
<glatzor> mvo_: software-properties currently has got some waiting_for_implementation issues regarding the mirror support (if you choose a mirror from the chooser it won't be used). but i haven't had the time to fix it. I think that is more important to get the KDE stuff in
<glatzor> mvo_: perhaps I find the time to the this on my today's train ride :)
<glatzor> to do this
<jsgotangco> mvo_, glatzor hi
<glatzor> hey jsgotangco!
<jsgotangco> how is the german g-a-i connection hehe
<mvo_> glatzor: agreed
<glatzor> mvo_: jsgotangco: i have to prepare for work.
<mvo_> glatzor: ok, see you later!
<jsgotangco> ok later
<glatzor> Riddell: I am going to split show_distro in init_distro and show_distro soon
<elkbuntu> ogra_, *ping* please pm me when you're around. thanks
<cjwatson> crimsun: happy to help test patch_sigmatel if you tell me what it is and how I can test it ;-)
<Tonio_> hi, I uploaded kdepim on friday afternoon, upload is still in the queue, is there a reason for this ?
<cjwatson> Tonio_: looks like Tollef forgot to let the contents of the queue through after unfreezing feisty
<cjwatson> Tonio_: I've done it now
<Tonio_> cjwatson: hehe, okay ;), that can happen :)
<webben> Does anyone know if there are any statistics available on which packages are downloaded from the Ubuntu (or Debian or indeed any) repository?
<webben> I'd be interested to find out how many downloads there are of some of the alternative browsers and Emacspeak.
<mvo_> webben: the closest thing we have is poopcon.ubuntu.com
<webben> mvo_, thanks :)
<elkbuntu> um, i believe he means popcon.ubuntu.com
<elkbuntu> not sure i want to know if the former even exists
<Chipzz> is feisty frozen wrt new translatable strings already?
<TheMuso> cjwatson: What is the absolute latest that something can be seeded before ff?
<seb128> Chipzz: no
<Chipzz> mvo_: sorry for bugging you again, but could you take a look at that patch I pointed you at a couple of days ago? IMHO, it's nice polish, and the patch is only a couple of lines really
<cjwatson> TheMuso: Thursday
<Chipzz> seb128: is there even such a thing as a string freeze? :)
<cjwatson> Chipzz: https://wiki.ubuntu.com/FeistyReleaseSchedule
<Chipzz> oh, still a month away
<Chipzz> I expected it to be sooner really ;)
<seb128> feisty is still not opened on rosetta anyway
<seb128> so no real point to freeze strings
<pitti> carlos: how did the experiment go about rosetta + feisty?
<carlos> pitti: not as good as it should, we are still doing some tests to see how to do it faster
<fabbione> morning
<fabbione> ogra_, pitti: ping?
<pitti> hi fabbione 
<fabbione> hey pitti
<TheMuso> cjwatson: Thanks.
<fabbione> pitti: could you be so kind to look at bug #83059? I am not sure if it's gnome-power-manager or hal that's exporting info at random
<Ubugtu> Malone bug 83059 in Ubuntu "Hibernation button only appears after second time in Feisty Herd 3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83059
<cjwatson> TheMuso: (but pushing the deadline is deprecated)
<seb128> fabbione: that's already fixed
<fabbione> i have seen it happening on powerpc too (while we were in Olso)
<seb128> fabbione: could you try pinging right people about bugs?
<seb128> fabbione: ogra is maintaining that package
<pitti> seb128: he did
<fabbione> seb128: i did ping both ogra and pitti...
<pitti> seb128: good morning, btw *hug*
<fabbione> seb128: because i was not sure what the fault was
<seb128> hey pitti :)
<fabbione> seb128: and i was asking for information..
<TheMuso> cjwatson: I understand that the sooner the better is preferable. Just wondering as espeak is approved for main, but as far as I know is not seeded. At this point, I'd rather wait till Wednesday to seed it, as there is a new release due on Tuesday that I'd like to get in first.
<TheMuso> While its still in Universe.
<seb128> fabbione: did you install the update package from friday which ships the autostart desktop again?
<seb128> fabbione: it looked like you were trying to get people fixing bugs you point again
* seb128 hugs pitti
<fabbione> seb128: this bug is from hw-cert on herd-3. machines don't get upgraded. we certify the release
<fabbione> seb128: it would be nice if you could speak with your manager about that.
<seb128> about what?
<heno> TheMuso: why does that matter, isn't that just a bug-fix release?
<fabbione> seb128: about me reassining bugs to people
<TheMuso> heno: Not sure.
<seb128> fabbione: I don't need to, I'm happy to fix support bugs, I'll not fix random bugs you point though
<heno> TheMuso: I would suggest seeding it before Feature Freeze and then address bugs afterwards
<fabbione> seb128: it's not a random bug.. it comes from the support center
<seb128> well, then make clear the procedure
<heno> I'm in late on this conversation, but I assume that's the deadline cjwatson was referring to
<fabbione> seb128: could you be so kind to explain to me what is not clear?
<fabbione> seb128: so that we can actually fix that?
<seb128> it looks like you point random bugs to random people and try to make them fix them
<Robot101> thom: cool :)
<fabbione> seb128: ok sec..
<seb128> nobody told me I was supposed to fix your bugs, so I'll no do until I'm asked to do so
<webben> The README and FAQ for popcon.ubuntu.com are both down. Are the voting figures effectively votes received /this/ week? Or are they on a longer cycle?
<ogra_> fabbione, thats fixed with my last upload, did you upgrade after herd3 ? 
<fabbione> ogra_: as i said to seb128 , we don't upgrade the machines. we certify the milestone
<ogra_> oh, ok
<ogra_> well, its broken on the milestone 
<cjwatson> TheMuso: I'm with heno on this
<TheMuso> o kok fine
<heno> we'll have enough madness around FF without adding this ;)
<cjwatson> fabbione: but now we know that the milestone is broken, so would it hurt to test the fix?
<fabbione> cjwatson: of course we can test the fix. I was only looking for somebody to tell me where the bug was because i am not familiar with that part of distro
<heno> cjwatson: can I just request the seed change of you here, or in some other format? eSpeak seeded for the CD, Festival un-seeded
<ogra_> fabbione, the autostart file wasnt installed so g-p-m isnt run ... if you want to reproduce: if you start the power preferences applet g-p-m is started in the background ... if that fixes the logout screen, thats the bug
<cjwatson> heno: festival doesn't seem to be seeded?
<cjwatson> heno: anyway, seems like a good time for you to learn how to make seed changes yourself :)
<fabbione> ogra_: thanks for the details. can you please add it to the bug in LP so that cr3 can double-test
<fabbione> ?
<cjwatson> heno: oh, you aren't in ubuntu-core-dev
<fabbione> (i can't copy paste from this machine atm)
<ogra_> oki
<heno> cjwatson: no, I think I've tried pushing seed changes before without luck
<cjwatson> heno: http://people.ubuntu.com/~cjwatson/germinate-output/feisty/rdepends/ALL/festival
<cjwatson> heno: ^-- indicates that festival is in main due to dependencies, not due to being explicitly seeded
<cjwatson> specifically the libgnome-speech3 dependency
<TheMuso> cjwatson: dholbach has gnome-speech ready to be uploaded with a dependncy on libespeak1.
<TheMuso> As far as I am aware when I was talking to him last.
<heno> cjwatson: so libgnome-speech3 depends on festival? 
<TheMuso> heno: Are we dropping festival completely?
<heno> right, so libgnome-speech should depend on eSpeak and recommend festival I guess
<heno> Festival should stay in Main IMO but be dropped from the CD
<TheMuso> heno: If we are going to recommmend festival, gnome-speech's festival driver will probably ahve to be in its own package.
<heno> TheMuso: why, can you not install that driver without installing festival?
<TheMuso> Gnome-speech can have a festival driver present and festival not be available, but I think it would make things confusing if there was a festival option there, but no speech was heard.
<cjwatson> TheMuso: that should just be uploaded, and then espeak can be promoted
<cjwatson> heno: yes
<cjwatson> heno: if festival is to stay in main, it needs to be added to the supported seed. dholbach should be able to do that
<heno> ok, and we should probably remove gnopernicus from main now, It's ot much supported anymore
<heno> cjwatson: ok, I'll email dholbach with these requests
* ogra scratches his head, wondering where that alsa-plugins accepted mail come from
<ogra> *comes
<Mithrandir> siretart: gxine is main and now build-depends on xulrunner, which isn't in main.   I suggest you either revert your change or talk to pitti about xulrunner in main.
<pitti> yet another firefox copy in main? only if ffox itself uses xulrunner
<ogra> switch it !!
* pitti redirects ogra's enthusiasm towards asac
<ogra> :)
* elkbuntu looks purposefully at ogra.
<seb128> xulrunner to main? waouh :)
* seb128 runs
<seb128> *g*
<ogra> :)
<asac> hello :)
<ogra> elkbuntu, i'm on it ...
<elkbuntu> ogra, thanks.
<Chipzz> pitti: firefox not using xulrunner is an upstream problem, right?
<pitti> Chipzz: I don't know anything about xulrunner
<asac> Chipzz: not exactly I would say :) ... mozilla plans to switch to xulrunner for firefox 3
<pitti> hey asac!
<asac> hello pitti 
<Chipzz> asac: yes. WAY too late
<pitti> slomo: ping
<asac> yes ... for feisty there will be no xulrunner
<Chipzz> they should have switched for firefox 2
<slomo> pitti: pong
<pitti> slomo: not sure whether you got my q last week: do you actually get apport reports from mono program crashes in current feisty?
<pitti> slomo: whenever I kill -SEGV a mono program, mono intercepts the signal, prints out its stuff and then just exits the program
<pitti> slomo: apport isn't even triggered
<pitti> slomo: (context: I wanted to add the mono blacklisting)
<Chipzz> asac: I don't get it anyway... isn't postponing that creating more of a maintenance nightmare anyway?
<slomo> pitti: hmm, i didn't get a new crash since some time... but when testing now with -SEGV it just crashes... something must've changed in apport then (as mono wasn't changed in months) :/
<asac> Chipzz: maybe ... anyway, its not supported by mozilla.org; so what can we do?
<pitti> slomo: but as I said, apport is not even triggered. hmm
<pitti> slomo: ok, so I leave this at it is for now
<slomo> pitti: probably the best until someone touches mono to add apport magic :)
<asac> so how can I get the power to change all firefox bugs? e.g. severity?
<pitti> asac, siretart: easiest is IMHO to build gxine against firefox, not xulrunner
<Chipzz> asac: hrrrm, I was somehow under the mistaken impression that you were related to mozilla development ;)
<pitti> asac: you probably need to become member of the bugsquad team; can anyone confirm? cjwatson?
<asac> Chipzz: related .. yes ... but not deeply involved atm ;).
<Adri2000> only members of the QA team can change severity
<asac> Adri2000: package maintainer too, right?
<Adri2000> ubuntu-dev and ubuntu-core-dev can since they are members of ubuntu-qa, otherwise I don't think so
<pochu> pitti: to change importance you need to be a member of ubuntuQA, and to be a member of ubuntuQA you need to be a member of the BugSquad :)
<Fujitsu> pochu, you don't need to be a member of the bugsquad.
<pochu> oups: Adri2000: didn't see your message ;)
<pochu> Fujitsu: not? I think yes :)
<Fujitsu> No.
<pochu> but sfllaw knows it :)
<pochu> Fujitsu: then?
<Fujitsu> Being a member of bugsquad isn't a requirement. ubuntu(-core)-dev are implicitly members of ubuntu-qa, among others.
<heno> pochu: it's the most common way, but not a requirement. People who contribute reliably to the ISO testing team should also qualify for Ubuntu QA
<heno> I agreed this with sfllaw in Oslo
<pochu> didn't know :)
<heno> pochu: are you in Ubuntu QA yet?
<pochu> this is from the wiki: In order to join:
<pochu>     *
<pochu>       sign up: with the BugSquad.
<pochu> heno: not, but I would like to join in the next hug day :)
<pochu> heno: February 14th :)
<heno> didn't I encourage you do join, I meant to
<heno> pochu: you should join the bugsquad, it's a great team
<pochu> heno: I'm a bugsquad member :)
<heno> pochu: but if you just sign up to Ubuntu QA I'll see that you are approved
<pochu> ?
<gnomefreak> heno: he shouldnt have a problem at all
<heno> I've already agreed your case with Simon
<pochu> which case? mine? I can't understand you :(
<heno> pochu: yes, just apply on Launchpad for Ubuntu QA
<heno> pochu: your contributions to organising ISO testing are enough
<heno> no need to wait for hug day
<pochu> heno: ok :) I haven't done that because I read on the wiki about triaging and the hug day
<pochu> however, I will come to the hug day :D
<Mithrandir> heno: sorry about not seeing your questions before today, but I haven't been watching work channels, I was hacking on photo stuff all weekend.
<heno> Mithrandir: sounds sensible. We'll just leave it as it is now I think
<pochu> heno: about the iso team, some people still reports in the forum. I've asked them to report the real bugs to Launchpad, but don't know if I should ask them to make their reports to the iso tracker. Should I?
<Mithrandir> heno: yes, I just need to fix up the script (and put it in bzr somewhere so you can get at it)
<heno> Mithrandir: need to think about how this will hold up/scale to more demanding release phases
<heno> Mithrandir: cool, thanks
<pochu> heno: also I've read your mail to the -devel list. If you need some help, just tell me what can I do
<heno> pochu: ok, thanks. I think you are right to point people at filing Launchpad bugs They could also file ISO test comments (I've now posted Herd 3 tracker bugs)
<pochu> heno: ok, I'll do it
<seb128> doko: do you plan to ask for a sync of the new ttf-dejavu from Debian?
<doko> seb128: IMO we should update to the new upstream release
<sfllaw> doko: Would it be possible to make a ttf-dejavu-lgc version?
<seb128> doko: they have a newer version, is there yet another new version upstream?
<sfllaw> doko: That builds the Latin-Greek-Cyrillic only versions of these fonts?
<sfllaw> Apparently, the Chinese character sets for DejaVu do not look very good.
<siretart> Mithrandir: pitti: I have to apologize, I didn't notice that gxine was promoted to main. Darren did a lot of work to fix gxine issues with gtk 2.10. I tried to get the package so that we can sync it from debian, but obviously, this won't work
<geser> Mithrandir: Hi, now that herd3 is out have you some time to look at the build failure of xmms2? It builds in a pbuilder, during lucas' rebuild and on Debian's buildds but not on ours.
<pitti> Checking for working C compiler... no
<pitti> OPTION CC MUST POINT TO A VALID C COMPILER!
<pitti> haha
<Mithrandir> geser: I have no idea about it, really.
<Mithrandir> geser: upload a new version where you run the configure with -x or its equivalent.
<doko> seb128: didn't see that; yes, 2.14 sounds fine
<seb128> doko: ok, can you do a sync request then please? ;)
<pitti> seb128, doko: I can sync it right away if you want to
<doko> sfllaw: looks good, but one week before ff? if you do have the time please go ahead
<doko> pitti: please do
<seb128> pitti: please do if doko is ok
<pitti> oh, hm, Mithrandir seems to do syncs ATM
<seb128> ok, he is, then do ;)
<sfllaw> seb128: Are we sticking with bug 81608?
<Ubugtu> Malone bug 81608 in kubuntu-default-settings "Please use DejaVu Sans Condensed as the default font" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81608
<sfllaw> If so, I will upload a version that does LGC.
<seb128> sfllaw: well, looks like that need discussion, maybe somebody should mail the ubuntu-devel-discuss list about it?
<sfllaw> seb128: Are you planning to revert?
<seb128> revert what?
<seb128> we didn't change anything yet
<sfllaw> Oh, I thought you had uploaded something...
<sfllaw> Never mind.
<Keybuk> when you change your home IP range ... remember to update the ACL of your DNS server
<StevenK> Hah
<StevenK> Done that myself
<zul> hey
<pitti> hi zul
<Hobbsee> heya pitti 
* pitti hugs Hobbsee, hi!
<Hobbsee> :D
* Hobbsee hugs pitti back
<Hobbsee> pitti: requestsync needs to be upgraded not to break when a package isnt in the ubuntu archive yet. 
<Hobbsee> (ie, when a package is new to ubuntu)
<pitti> Hobbsee: specifying a '0' basever (3rd argument) doesn't work as a workaround?
<Hobbsee> pitti: didnt try
* Hobbsee wonders what I: mailody [universe]  -> mailody_0.4.0~rc2-1 [universe] . means
<Hobbsee> (where that's the old versoin)
<pitti> Hobbsee: that's just some debug output of sync-source (in particular, the current overrides)
<Hobbsee> pitti: oh right.  so it can be ignored.
<Hobbsee> pitti: it seems not.  
<fabbione> ogra: sorry do you have the bug number for the missing g-p-m file? it's not in the changelog
<fabbione> (so i can mark duplicate etc. etc.)
<heno> cjwatson: which package will you be uploading the braille script with, brltty, casper? I'e has dome updated work from Dave and would like to compare and sync
<Mithrandir> Hobbsee: https://launchpad.net/ubuntu/+source/kimdaba/+bug/83162 ; a small reason would be nice.
<Ubugtu> Malone bug 83162 in kimdaba "please remove kimdaba from the archive (feisty)" [Undecided,Unconfirmed]  
<cjwatson> heno: brltty I think
<cjwatson> I did a chunk of it on Friday but got stalled for a bit - I'll take it up again today or tomorrow
<Hobbsee> Mithrandir: i'm positive i put one in there.
<pochu> heno: I'm interested in the braille feature, is there any spec, or something?
<Hobbsee> Mithrandir: oh bugger it
<heno> cjwatson: ok, thanks. feel free to send me whatever you have by mail as well to look over
<Hobbsee> Mithrandir: maybe only the original bug did.  done.  upstream renamed it
<Mithrandir> Hobbsee: ok, what's the new name?
<Hobbsee> Mithrandir: kphotoalbum
<Mithrandir> thanks
<heno> cjwatson: or better, yet: I'll just send you what Dave sent me
<Hobbsee> Mithrandir: :)
<heno> pochu: https://wiki.ubuntu.com/Accessibility/Specs/BrailleSupport
<pochu> heno: thanks!
<tkamppeter> I have a question about the uplaod of a new package and its availability. See https://launchpad.net/ubuntu/+source/m2300w/0.51-0ubuntu2
<pochu> tkamppeter: #ubuntu-motu
<cjwatson> pochu: it's fine here
<vernes> so, this channel is only for anouncements?
<tkamppeter> One can see on the left that m2300w was successfully built on all platforms, but on http://archive.ubuntu.com/ubuntu/pool/universe/m/m2300w/ only the source packages show up and not the binaries. How long will it take until the binary packages appear?
<pochu> cjwatson: ok :)
<cjwatson> vernes: no
<cjwatson> vernes: this channel is for discussion and coordination among Ubuntu developers
* Hobbsee wonders if that's sitting in binary NEW still
<vernes> ah, ok
<cjwatson> tkamppeter: undetermined - it's in the NEW queue
<Hobbsee> s/still//g
<tkamppeter> The last message got broken, here it is again: One can see on the left that m2300w was successfully built on all platforms, but on http://archive.ubuntu.com/ubuntu/pool/universe/m/m2300w/ only the source packages show up and not the binaries.  How long will it take until the binary packages appear?
<cjwatson> tkamppeter: you can see the NEW queue here: https://launchpad.net/ubuntu/feisty/+queue
<cjwatson> tkamppeter: is the split of m2300w-ppds really worth it? that package is tiny
<tkamppeter> Thanks, cjwatson, some weeks ago I asked here where I can see the NEW queue and no one answered me.
<cjwatson> tkamppeter: there are some much bigger files in m2300w - if there's to be a split at all it should be those files that are split out, if they're architecture-independent; if they're not, I'd just put the lot in one binary package
<tkamppeter> The split is because other printer driver packages were built in a similar way.
<tkamppeter> But it seems that the package was in general accepted this way because the source was accepted.
<tkamppeter> So for me it was strange that the binary was correctly built but not uploaded.
<cjwatson> binary packages with new names are *always* held in the new queue
<cjwatson> always always always
<cjwatson> tkamppeter: the person processing the source probably didn't notice. I'm noticing now, and recommending that it be done differently
<cjwatson> I'll accept the binaries anyway for now, but I recommend that you rethink the split
<Mithrandir> or it wasn't split when the source was uploaded.  And it's hard to judge sizes when all you have is the source package.
<Tonio_> pitti: ping ? maininclusionqueue show kde-style-polyester has been approved, but https://wiki.ubuntu.com/MainInclusionReportKdeStylePolyester doesn't...
<Tonio_> pitti: is it really being proceed ? In case yes I will change the kubuntu-desktop seed
<Riddell> Tonio_: pitti didn't handle it, iwj did
<hunger> Is there any iptables-based firewalling script that still works on feisty?
<Tonio_> Riddell: okay
<Riddell> Tonio_: and I've added it to the seeds
<Riddell> Tonio_: so now we go back to pitti to ask him to promote it :)
<Nafallo> hunger: firestarter
<hunger> Nafallo: firehol is still borked:-(
<hunger> Nafallo: Have you tried that recently?
<Nafallo> hunger: I run it atm.
<pitti> iwj: right, if you approve a MIR, you need to change the wiki page, too
<pitti> Tonio_: it has been promoted earlier by Mithrandir 
<iwj> pitti: Err, didn't I ?
<iwj> I meant to update both the page for the review itself and the queue page.
<pitti> apparently not
<iwj> Let me fix that.
<iwj> I must have forgotten to save the page or something.
<pitti> doko, seb128: I just synced ttf-dejavu
<geser> Mithrandir: I've uploaded a new xmms2 which prints now the config.log if scons fails
<geser> Mithrandir: but I can't make much sense from the build log: http://librarian.launchpad.net/6221835/buildlog_ubuntu-feisty-i386.xmms2_0.2DrHouse-3.1ubuntu2_FAILEDTOBUILD.txt.gz
<Tonio_> pitti: yes Riddell told me thanks :) just the MIR page missed the info so I wanted to be sure :)
<iwj> pitti: Fixed, sorry.
<pitti> iwj: no worries, thanks
<seb128> pitti: thank you
<Chipzz> geser:'
<Chipzz> gcc -o .sconf_temp/conftest_0.o -c -O2 -Wall -g .sconf_temp/conftest_0.c
<Chipzz> /bin/sh: -c: line 0: syntax error near unexpected token `('
<Chipzz> it's executing gcc, which appears to be a symlink to /bin/sh or something?
<geser> Chipzz: check the next line in the log
<Mithrandir> geser: where does that env call come from?
<Chipzz> oh, right
<geser> Mithrandir: I don't know
<Mithrandir> it seems to be unhappy about the HASH(0x82db558)="" which has snuck into the environment
<pitti> BenC: hm, it seems we get invalid core dumps pretty often now -- since the kernel already reaps the crashed process before writing to stdin is finished, may it be possible that parts of the core dump get lost?
<Chipzz> heh
<BenC> pitti: it's possible
<BenC> pitti: I can look into the wait4 stuff I did before
<doko> BenC: you did ping me yesterday
<BenC> doko: You have an atheros wifi, right?
<doko> BenC: yes, non-working :)
<BenC> doko: Can you test the latest (6.4) lrm in feisty and tell me if it works?
<tepsipakki> could someone sync nfs-utils from experimental?
<pitti> tepsipakki: did you test the new version?
<seb128> tepsipakki: if you tried it open a sync bug and get somebody confirming it
<tepsipakki> pitti: hmm, actually no
<tepsipakki> seb128: I was about to
<cjwatson> FYI, "UbuntuSpec:launchpad-spec-name" now works on wiki.ubuntu.com
<cjwatson> which saves all the [https://blueprints.launchpad.net/ubuntu/+spec/launchpad-spec-name launchpad-spec-name]  nonsense
<pitti> yay
<BenC> cjwatson: nice
<seb128> nice
<geser> Mithrandir: looks like the env call comes from Scons
<tepsipakki> why is it that on my systems none of the scripts in /etc/network/if-up.d are run for eth*? I'm pretty sure it works for some
<geser> Mithrandir: but I don't know where the HASH came from. does perhaps the buildd set it?
<doko> BenC: it's not yet in the archive
<BenC> It's built, maybe you can get it from launchpad
<Mithrandir> it's from sbuild, it's a perl thingy.
<cjwatson> looks like a stringified hash reference
<cjwatson> $ perl -le '%foo = (); print \%foo'
<cjwatson> HASH(0x100158b4)
<BenC> doko: http://librarian.launchpad.net/6220771/linux-restricted-modules-2.6.20-6-generic_2.6.20.1-6.4_i386.deb
<BenC> doko: or for amd64 http://librarian.launchpad.net/6220744/linux-restricted-modules-2.6.20-6-generic_2.6.20.1-6.4_amd64.deb
<geser> and how do I avoid it?
<cjwatson> get somebody to fix that sbuild bug? :)
<cjwatson> probably infinity
* pitti sings 'Another one bites the dust' and marks increase-hwdb-participation as implemented
<tepsipakki> mvo: "software-properties-gtk has no installation candidate" ;)
<tepsipakki> oh it's in the queue
<bddebian> Heya
<cjwatson> pitti: woo, thanks
<pitti> cjwatson: thanks for your suggestions
* ogra applauds pitti 
* seb128 hugs pitti
* bddebian doesn't know why but applauds pitti too
<seb128> * pitti sings 'Another one bites the dust' and marks increase-hwdb-participation as implemented
<seb128> bddebian: usually reading a few lines back give you an hint
<seb128> ;)
<doko> BenC: seems to work
<bddebian> seb128: I don't stay connected to keep a scrollback :)
<pitti> seb128, ogra, bddebian: thanks :)
<fabbione> mjg59: ping?
<seb128> bddebian: that was the first line after you joined ...
<seb128> bddebian: if you ignore the part line
<ogra> fabbione, i duplicated the g-p-m bug, thanks for notifying ...
<bddebian> Oh, heh, lost in the shuffle
<pitti> nevermind, guys, that was really a trivial one
* bddebian crawls back under a rock
<fabbione> ogra: thanks to you.. i just couldn't find the reference..
<fabbione> ogra: i still asked Marc to verify it with a dist-upgrade.. to be extra sure
<ogra> ok
<BenC> doko: Cool, thanks
<pitti> BenC: oh, if you touch the apport kernel bits: can you export the process' core file size ulimit in an env var?
<BenC> pitti: Sure
<pitti> BenC: Keybuk and I discussed that last Friday, and I got a complaint about not writing cores to people's cwd if ulimit > 0
<pitti> BenC: (for non-packaged programs)
<BenC> pitti: Makes sense
<pitti> BenC: so while this dynamic decision seems a bit hackish, it's the best approximation of what we actually want; WDYT?
* iwj mistypes `udev' for `udeb', _again_.
<pitti> iwj: autofingers strike back :)
<cjwatson> udebs were here first. :)
<iwj> cjwatson: Can I ask you a question about udebs ?  I'm doing udev-device-mapper and it turns out that the udev scripts for dm devices are going to call a symlink to dmsetup.
<iwj> (a) Is that relevant at all to udebs ?  (b) If so, is it OK ?  (c) If so, what should I do to the dependencies in the udebs to make sure dmsetup is installed if it's required ?
<iwj> (Don't ask why it's a symlink to dmsetup; that's the way I found it.)
<davmor2>  bug 83324 this bug has been partially resolved now in that hardware database item has been added to app>system tools  but I still think that the item needs to go in control center alongside hardware information.
<Ubugtu> Malone bug 83324 in hwdb-client "hardware datatbase is requested but in wrong location" [High,Confirmed]  https://launchpad.net/bugs/83324
<pitti> ogra: ^ that spec didn't talk about *where* to add the menu item, so I just took whatever already was in the .desktop
<ogra> pitti, which is fine imho ... i start to hate the control-center more and more every day ...
<bddebian> heh
<ogra> it slows me down a lot by just waiting for a grouping window to come up instead of providing direct access to the function i want ....
<chrisj> cjwatson:Ping, about the partitioner re-write
<ogra> but since i have a general objection against that usability drawback, i'm probably the wrong person to judge at all
<mvo> can we get a hwdb-client that can be translated?
* mvo ducks
<davmor2> I only suggested that it go into control panel as it is already in the hardware information app which is in the control center
<ogra> mvo, i thought pitti fixed that last upload
<cjwatson> iwj: (a) yes, though it would be worth running through partman's LVM and MD support afterwards to make sure it still works; (b) yes, sounds fine; (c) Depends: dmsetup-udeb
<cjwatson> chrisj: i
<cjwatson> hi
<ogra> at least there was a lot in the changelog
<cjwatson> (damn keyboard)
<pitti> mvo, ogra: no, I fixed the handling of the po/ files, I didn't actually fix any code
<pitti> ogra, mvo: unless the reason was a missing .pot file; I fixed that
<mvo> pitti: unfortunately that is not enough
<chrisj> cjwatson: heno said to ping you about lending a hand.  Has anything be done yet or is it a blank slate? 
<cjwatson> chrisj: taking to /query
<iwj> cjwatson: Great, thanks.
<iwj> I think some of partman's lvm support may become obsolete, since things will get activated automatically.
<DaSkreech> Hello
<DaSkreech> Why is there no more progress bar on the Bootsplash?
<cjwatson> iwj: a little, but probably not lots. Most of it is keeping track of what's there vs. what should be there.
<cjwatson> having VGs be brought up automatically will be interesting
<Nafallo> DaSkreech: atleast you got a bootsplash... :-)
<DaSkreech> Nafallo: Yours is broked? :)
* Nafallo wonder when that disappered ;-)
<Nafallo> wonders even
<DaSkreech> The progress bar?
<cjwatson> iwj: one thing to make sure of is that it's possible to deactivate and delete PVs etc. in partman
<cjwatson> without them coming straight back up again
<Nafallo> DaSkreech: no. my bootsplash :-)
<cjwatson> DaSkreech: erm, I don't believe it was intentionally removed ...
<DaSkreech> cjwatson: It's very very distracting
<cjwatson> if it's gone, it's some kind of accidenet
<cjwatson> accident
<cjwatson> how can the lack of something be distracting?
<DaSkreech> without that and kernel messages it's impossible to tell if the OS is actually booting
<cjwatson> that's not "distracting", it's "annoying" or something
<DaSkreech> after 10-12 minutes you just kind of guess nothign is happeneing
<cjwatson> it's a bug, file it
<DaSkreech> no it's distracting
<cjwatson> I guess this is distracting as my stepson uses the word :-)
<DaSkreech>  I used to be able to turn on the computer and just kind of glance at it to see messages streaming past
<DaSkreech>  now I HAVE to sit and watch the screen
<cjwatson> the messages were intentionally removed, but the progress bar wasn't
<cjwatson> it should still be there
<DaSkreech> I know but I can jimmy the messages back in :)
<DaSkreech> I don't know how to restore the progress bar
<DaSkreech>  Is there a way?
<cjwatson> it's not supposed to be gone. *file a bug*
<iwj> cjwatson: Right.
<cjwatson> also it shouldn't take 10-12 minutes for the computer to boot; that in itself is a problem
<DaSkreech> I'm doing that now
<iwj> cjwatson: We're only going to be running vgchange on block device addition, not removal, so we should be OK.
<DaSkreech> cjwatson: Right but I don't know it's a problem till 10-12 minutes have gone
<DaSkreech> cause there is no progress bar
<DaSkreech> I can't tell how far it's gone or without watching the clock how long this has been going on
<cjwatson> do you have a custom kernel or something?
<DaSkreech> no Herd Live CD
* Nafallo ponders what can be the most likely to blame for getting usplash to disappear on amd64 with the 0.4-34 upload :-P
<DaSkreech> so a) it's a new kernel and b) it's a live cd
<cjwatson> well, it worked fine in testing, AFAIK
<DaSkreech> Yeah I find random computers simply won't boot from a Ubuntu live CD for a release for soem reason
<cjwatson> so since it's a bug, nobody can answer your question of "how do I get the progress bar back?" without diagnosing and fixing the bug
<DaSkreech>  some will throw a kernel panic as soon as you hit enter some pretend to boot then just stop doing anything
<DaSkreech> Of course without a progress bar it's much harder to figure that out
<DaSkreech> cjwatson: ok I was just wondering if there was some hidden option like foolnewbsintothinkingitswindowsxp
<cjwatson> no.] 
<DaSkreech> :-)
<DaSkreech> Good to know
<cjwatson> press F6 at gfxboot and delete the "quiet splash" boot arguments
<cjwatson> then try booting with that
<Nafallo> ehrm... dudes. should I have /etc/usplash.conf on amd64? :-)
<cjwatson> if it's kernel-panicking, you'll see that
<cjwatson> DaSkreech: if it panics before the progress bar is set up, then that would explain it
<cjwatson> DaSkreech: in that case, please file a bug on linux-source-2.6.20 with the best transcription of the panic that you can manage
<DaSkreech> No if it panics on this machine the progress bar goes away and I get Scary Messages (c)
<DaSkreech> But this machine actually boots fine
<DaSkreech>  It's just annoying that I have to be distracted by a boot process
<DaSkreech> When for many years it was done so well
* Nafallo rebuilds initramfs without it
<pochu> pitti: I think you should look at this bug: https://launchpad.net/bugs/83324
<Ubugtu> Malone bug 83324 in hwdb-client "hardware datatbase is requested but in wrong location" [High,Confirmed]  
<pochu> pitti: it's "fixed", however it could be better ;) but feel free to close it if you think it's done
<cjwatson> hmm, https://launchpad.net/ubuntu/+source/usplash/+bug/81413 suggests some unzeroed struct members or somethin
<Ubugtu> Malone bug 81413 in usplash "[Feisty]  no usplash" [Undecided,Unconfirmed]  
<cjwatson> g
<iwj> cjwatson: So to test out my crazy new udebs I should drop them in build/localudebs of my unpacked and ready-to-build-an-image d-i tree ?
<iwj> Is there an easier way that doesn't involve writing huge cds ?
<seb128> pitti: ok, using an old linux version make apport works fine again
<seb128> pitti: BTW were is the ignore list and the package crashes counter for apport?
<seb128> I want to reset some of them ;)
<pitti> seb128: I guess it's the piping that crops the coredump
<pitti> seb128: ~/.apport-ignore.xml
<seb128> ah, thank you
<pitti> or just sudo touch the executable :)
<seb128> and there is a "that package already got 3 crash reports today" counter too, no?
<Nafallo> thanks cjwatson :-)
<tepsipakki> ok, nfs-utils from Debian experimental works fine, bug #83435
<Ubugtu> Malone bug 83435 in nfs-utils "please sync nfs-utils (main) from Debian experimental" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83435
<tepsipakki> it is a newer snapshot which will (hopefully) soon become 1.0.11
* Nafallo reboots
<cjwatson> iwj: if you can arrange not to need any of this until you reach the stage of the installer when networking is brought up, you can wget the udebs and udpkg -i them on the fly
<cjwatson> iwj: alternatively, you may be able to nuke all the .debs from pool/, which would make writing CDs quicker
<cjwatson> (presumably you don't need to go as far as installing the base system)
<Nafallo> usplash came back when I removed /etc/usplash.conf :-)
<seb128> pitti: and there is a "that package already got 3 crash reports today" counter too, no?
<Nafallo> we are not trying to make that pretty for feisty are we? :-)
<cjwatson> yes
<cjwatson> it just needs ported to new libx86
<Nafallo> so not supposed to work now then :-)
<Nafallo> good
<iwj> cjwatson: This is for the root fs so I'd have to nobble it not to look at any of that, and then I'd have to tediously retype my dpkg -i's when I got it wrong.
<iwj> But your suggestion of nuking .debs sounds work a try.
* Nafallo comments on the bug
<mjg59> fabbione: Hi
<cjwatson> iwj: can't be for the rootfs in the installer surely :)
<pitti> seb128: that counter is in the report itself, just delete it
<iwj> cjwatson: Well, indeed :-).  But doesn't it go and detect hard disks quite early ?
<seb128> pitti: ok, so that's not it (I've clean /var/crash), killall -11 rhythmbox produce no crash for whatever reason
<iwj> Anyway this is all a bit moot because atm my main initrd generator is evidently broken ...
<cjwatson> iwj: yeah, but you could probably nobble it not to ...
<cjwatson> iwj: BOOT_DEBUG=3 is often useful if you need to edit stuff before udev starts
<iwj> Thanks.  In this case it fails to run udev for some reason.
<iwj> I've obviously done something really freaky to this install.  udev is failing to create /dev/{mem,tty0,...}
<DaSkreech> cjwatson: https://launchpad.net/ubuntu/+bug/83438
<Ubugtu> Malone bug 83438 in Ubuntu "No Progress bar on bootsplash" [Undecided,Unconfirmed]  
<fabbione> mjg59: hey.. sorry to bother you.. do you have an idea of what could cause bug #83078 ?
<Ubugtu> Malone bug 83078 in Ubuntu "Hibernation on Feisty herd 3 doesn't wake for Sun Ultra 20 Work" [Undecided,Needs info]  https://launchpad.net/bugs/83078
<DaSkreech> Thanks
<mjg59> Is ultra 20 x86?
<mjg59> If so, no, that gives me no useful information
<mjg59> Get them to boot without splash quiet
<fabbione> mjg59: yes it's x86
<fabbione> mjg59: ok thanks a lot..
<tkamppeter> pitti, ping
<iwj> Grrr.  Every time you do an install it changes the uuid of the swap partition all your other installs are using.
<cjwatson> should be fixable by telling it not to format swap
<cjwatson> which IIRC is an option these days
<wasabi> udev rules question. Trying to figure out how to make evms_activate when ANY block device comes and goes
<wasabi> The rules lines are weird. Weird language. Looks likea filters + actions.
<fabbione> cjwatson: only if you do manual partitioning AFAIK.
<iwj> cjwatson: But if you install an earlier version it breaks your most recent versions.
<wasabi> If I just remove the filter, for KERNEL=="dm-*" would that be good enough?
<iwj> I think we're pretty crappy at coexistence given that we can't even manage it with ourselves, which makes it hard to justify complaints about M$ antics.
<cjwatson> iwj: maybe I need more coffee, but I can't parse your second-last statement
<cjwatson> fabbione: if you aren't doing manual partitioning, it won't reuse the existing swap partition
<wasabi> So, um. Is it reasonable at this point for somebody (other than me, who can't upload to main) to fix evms? 70-evms.rules should be included in the initramfs, and the udev rule should run on ALL block devices.
<iwj> cjwatson: I mean, if you have a working feisty install and then you install dapper, dapper's installer will break your feisty's swap.
<fabbione> cjwatson: hmm ok.. i might remember it wrong then.
<cjwatson> I guess dapper didn't have the option not to format swap
<iwj> wasabi: Err, it's probably best not to touch that right now.  I'm doing the same thing for lvm2 now and I'll do evms when I've got it working.
<wasabi> I still wonder why we use swap partitions.
<wasabi> I was sort of fond of swapd before I realized it was broken.
<iwj> cjwatson: Which means that when we made dapper we thought it was OK to randomly change the uuid of a swap partition and now we think it isn't.  And this isn't the only example of this kind of thing.
<iwj> wasabi: There are two rules in 70-evms.rules, aren't there ?
<wasabi> Yes. One for dm-*
<wasabi> and... um. Some kernel ENV thing
<cjwatson> no, when we were making dapper we didn't think about it at all
<wasabi> which I just nuked
<fabbione> iwj: oh btw... i found a way to get rid of that script that creates the symlinks to lvm in initramfs
<cjwatson> I mean, I take your point, but there's not much I can do about dapper
<fabbione> iwj: just prefix the calls with lvm
<wasabi> Except make a dapper service pack. :0
<fabbione> iwj: vgscan -> lvm vgscan
<cjwatson> I think we should probably fix feisty so that when it formats swap it extracts the prior UUID of the swap partition and reinstates it after formatting
<cjwatson> so that even if you format by mistake it doesn't trash the UUID
<iwj> cjwatson: That would be a way for us not to break the promise we made to ourselves in dapper.
<cjwatson> in reality, formatting a swap partition (that doesn't have a hibernate signature in it) is just a much faster way of checking it :-)
<iwj> fabbione: Oh, hmm.  I'm making the symlinks in a hook script now anyway.
<wasabi> Real question though... why swap partitions?
<iwj> It's so totally lame that you can't put symlinks in the initramfs!
<fabbione> iwj: yes and AFAIK it was the only reason why we were shipping the hook...
<fabbione> iwj: so we can just get rid of it by calling lvm $command
<iwj> wasabi: Err, are you finding that the trigger isn't working when it should ?
<cjwatson> which is in fact why partman started formatting swap by default - checking the swap partition was really slow
<wasabi> iwj: doesn't work at all during the initramfs.
<wasabi> I have to break and run evms_activate manually.
<wasabi> Also, it's not even included. ;)
<iwj> wasabi: Yes, but that's nothing to do with the dm-* condition on the second rule.
<wasabi> I need to restore that file one sec
<iwj> See https://wiki.ubuntu.com/UdevEvms, last section `Notes from the actual implementation'.
<lemsx1> is anybody working on the new tzdata file for Dapper/Edgy ?
<iwj> wasabi: So yes I'm going to fix the initramfs for evms but I think the udev rules are right.
<cjwatson> wasabi: last I checked (a) swap partitions were still more efficient than swap files (b) partman has absolutely no clue of how to set up swap files so it would be a chunk of work to do even if we did want to switch over
<iwj> Also if you use swap partitions you can't share them if you dual boot which is actually useful.
<wasabi> Hmm. swapd is neat.
<wasabi> It's a daemon that auto creates swap files when swap space runs low.
<lemsx1> This is very important for us on the East coast of the US: http://wiki.debian.org/TimeZoneChanges and http://packages.qa.debian.org/t/tzdata.html
<wasabi> It could be fixed/tuned. And then you could have a nice "Ubuntu is running low on swap space and is increasing it to meet demand" tip like windows.
<wasabi> or whatever.
<iwj> wasabi: I don't have time now to argue with you about swapd but it's a hideously bad idea.
<wasabi> heh. Just want to know why.
<wasabi> iwj: I'm looking at the evms rules now. Are you saying the first rule should cause evms to run?
<iwj> wasabi: Do you still think the evms udev rule is wrong ?
<wasabi> ENV{ID_FS_USAGE}?
<iwj> Yes.
<wasabi> I need to know what that means. ;)
<cjwatson> iwj: apparently the use of cpio --dereference is to save space while building the image - it creates a big symlink farm to the stuff on the system where you're running mkinitramfs and then cpio dereferences them on the fly
<wasabi> Ahh. I see. vol_id stuff.
<iwj> cjwatson: Yes.
<iwj> cjwatson: Really we want   cpio --dereference-only-absolute-symlinks  or something.
<wasabi> iwj: Probably works for things where your block device is in fact for raid. But pure LVM?
<wasabi> Hmm. Guess that would be dm
<iwj> root@samual8:~# /lib/udev/vol_id /dev/hda13
<iwj> ID_FS_USAGE=raid
<iwj> ID_FS_TYPE=LVM2_member
<wasabi> okay, cool. It probalby works... just needs to be in the initramfs. I don't really have anything to test it with that doesn't get handled during the initramfs
<iwj> wasabi: Right.
<iwj> Damn, debugging a system where udev doesn't start is a PITA.
<cjwatson> iwj: swap UUIDs> fix in my local partman-basicfilesystems tree now, although I'll need to test it
<iwj> cjwatson: Excellent.
<iwj> cjwatson: Would you have any useful tips for a system where udevd doesn't seem to run in the initramfs for some reason ?
<cjwatson> obviously dapper installs will still confuse feisty, but I can't do anything about that now
<iwj> cjwatson: Yers.
<cjwatson> iwj: I'd try cranking udev_log up to debug in /etc/udev/udev.conf
<cjwatson> to see if it's being started at all
<iwj> Does that help in the initramfs ?
<cjwatson> other than that I think I'd be inclined to break=top and step through the initramfs by hand
<cjwatson> provided you can get it in place early enough, should do
<Adri2000> any archive admin: please give back gaupol (i386, it's an architecture: all)
<cjwatson> I think it just prints to stdout
<cjwatson> Adri2000: you need somebody in launchpad-buildd-admins for that (== "buildd admin"), not somebody in ubuntu-archive (== "archive admin")
<iwj> It runs fine if I say `udevd&' from the initramfs shell.
<Adri2000> cjwatson: ah, I didn't know
<cjwatson> iwj: can you tell if it's running in the initramfs? (break=bottom and 'ps')
<Adri2000> Mithrandir: please give back gaupol (i386, it's an architecture: all)
<Kano> hi, did you patch mount to support UUID for ntfs?
<iwj> cjwatson: It bombs out due to not finding the root fs and then in that shell it's not running, but starts fine when I run it by hand.
<Kano> i dont get why this does not work on pure debian
<iwj> cjwatson: Oh, I see it now.
<iwj> cjwatson: BTW, YM debug=y, not BOOT_DEBUG=3
<iwj> (I think)
<cjwatson> iwj: in d-i it's BOOT_DEBUG=3
<cjwatson> which is what I thought you were talking about
<iwj> Ahhh.
<cjwatson> perhaps we were at cross-purposes
<Kano> is Scott James Remnant here?
<Keybuk> yup
<Kano> is it you?
<Keybuk> it is
<cjwatson> Kano: /whois
<Kano> well do you know about that UUID thing for Ntfs
<Keybuk> you'll have to be more specific, I'm afraid
<somerville32> Mithrandir, Can we get herd 3 released for Xubuntu?
<Kano> well on ubuntu UUID=... can be used for ntfs and on debian not
<Keybuk> right... ?
* Keybuk still doesn't know what you're talking about; I'm afraid
<Kano> what did you change
<Kano> in the fstab
<Kano> ubuntu usually uses UUID instead of /dev/XXX entries
<Keybuk> yes, it does
<Kano> but when i use the same entries on etch, i can not mount ntfs
<Keybuk> ahh
<Keybuk> see, if you'd started this with "Why can Ubuntu mount NTFS partitions by UUID, when Debian can't?" I would have been able to answer you instantly
<Kano> so tell me why
<Keybuk> the answer is that Ubuntu's util-linux package contains a patch from SuSE to use libvolumeid for UUID detection, instead of libblkid
<Kano> well i found a similar entry in the mount changelog
<Keybuk> libvolumeid comes with udev and is actively maintained, and supports far more filesystems than libblkid which comes with e2fsprogs and isn't actively maintained
<Keybuk> the one with my name on it, I assume?
<Kano> yes
<Keybuk>   * Steal the libvolume_id-support patch from SuSE and apply here so that
<Keybuk>     we use libvolume_id for accessing devices via UUID and/or LABEL instead
<Keybuk>     of the less-capable blkid.
<Keybuk>  -- Scott James Remnant <scott@ubuntu.com>  Mon, 21 Aug 2006 15:23:58 +0200
<Keybuk> ironically
<Keybuk> the changelog entry you refer to appears to answer your question for you :)
<Kano> well why did n't you tell debian about it?
<Treenaks> Debian is currently in a very deep freeze
<Keybuk> because writing over 1,000 individual e-mails to each Debian developer would take a long time?
<Kano> thats an important change
<jamesh> Kano: you could ask SUSE why they didn't tell Debian about it either
<Keybuk> the Debian maintainer of util-linux is well aware of the patch
<Keybuk> aren't you lamont ? :)
<Keybuk> you'd be better off asking the Debian maintainer why he hasn't applied the patch to Ubuntu
<Keybuk> err
<Keybuk> s/Ubuntu/Debian/
<Keybuk> I suspect you'll get the entirely sensible and legitimate answer that udev isn't essential in Debian
<Keybuk> so an essential thing like mount can't depend on it
<Keybuk> (udev is part of a minimal Ubuntu installation, so we *can* depend on it)
<Treenaks> Keybuk: how.. Debian..
<Kano> Keybuk: why could the patch not use volid first and if not there use old code?
<Keybuk> it could
<Keybuk> go write it like that :p
<Keybuk> there's no point Ubuntu spending time doing that, because udev is in our base install, so we don't need that patch
<Keybuk> (where "that patch" = "the clever use volid-or-blkid one"
<Keybuk> of course
<Keybuk> using dlopen() inside mount might make people run away
<Keybuk> (unless you know of a clever ELF hack to load alternate .so files?)
<kylem> LD_PRELOAD mount.
<kylem> muahahahahahah.
<kylem> that's not a root hole waiting to happen.
<Keybuk> please don't suggest that to Lamont
<Keybuk> he might get ... carried away
<Kano> Keybuk: the funny thing is: suse is not even using UUIDs in 10.2's fstab
<Keybuk> they're going to
<Keybuk> pretty much everyone is, as it's the easiest way to deal with /dev/hda1 suddenly becoming /dev/sda3
<keescook> mornin'
<Kano> Keybuk: i want to use it too...
<kylem> morning kees.
<keescook> hiya kylem 
<iwj> OMG
* iwj sees why it's not working.
<iwj> + mknod /dev/root b 253 0
<iwj> + ROOT=/dev/root
<iwj> (253 is devmapper)
<Keybuk> iwj: no 50p in the meter?
<pkl_> i.e. when the ide drivers move over to the new serial ide infrastructure.
<Keybuk> Kano: grab the util-linux source package from Ubuntu, copy the appropriate patch (I think it's just libvolumeid-support or something) out of the debian directory into the Kanotix package, profit
<Keybuk> Share And Enjoy
<iwj> Time for one last attempt before I go to dinner.
<Kano> will just recompile yours in case the version is higher
<Keybuk> our util-linux package also carries a different hwclock script
<Keybuk> the feisty util-linux package is the same base version as the unstable one
<Kano> is that essential?
<Keybuk> no, it's just because of our different boot process in edgy
<Kano> so better fetch only that patch from it?
<Keybuk> yeah
<Kano> ok
<Keybuk> those are the only two, afaik
<Keybuk> lamont touched it last
* somerville32 hugs Keybuk.
<Kano> libvolume-id-dev 
<Kano> that to use for debian
<Kano> hmm looks that is exists too..
<Kano> just notthing with ubuntu...
<Keybuk> hmm?
<Kano> libvolume-id-d 0.103-2 
<Kano> libvolume-id-dev (>= 093-0ubuntu11),
<Kano> >=0.93 then?
<Keybuk> whatever matches
<somerville32> sladen, ping
<Kano> Keybuk: do you know ntfs-3g
<Kano> Keybuk: the patch works for ntfs
<Kano> but not for ntfs-3g
<Kano> Keybuk: i guess, because /proc/mount shows /dev/disk/by-uuid/XXX
<Kano> but output of mount is "fixed" to show the real device
<Kano> just not for ntfs-3g
<Kano> (type fuse)
<infu> hello
<pochu> hi infu!
<infu> excuse me...this channel is only for ubuntu's developers?
<pochu> infu: not only, but mostly :)
<infu> ah ok
<infu> =)
<infu> are there some employee of canonical?
<somerville32> I'm sure there are
<infu> 'cause after university
<infu> i would like to work as developers for free software
<infu> and canonical or red hat i think are a great point
<cjwatson> Keybuk: our patch doesn't require udev, of course, just libvolumeid - I'm sure that could be borged into Debian's base system without a problem, post-etch
<pochu> infu: you can start helping now without being employed ;)
<infu> sure
<cjwatson> infu: you're welcome to watch out for positions that interest you on http://www.ubuntu.com/employment
<infu> yes i'd read that document
<infu> it's "simple" can work for canonical?
<cjwatson> the majority of our contributors aren't employed by Canonical, though, which is a good thing :)
<infu> became an employee
<cjwatson> our job interview processes are much like those of many other companies, except for being generally conducted by phone out of necessity
<infu> yes i know but there are also some employee on canonical or red hat or novell or oracle
<infu> oh ok
<sladen> somerville32: yo, !justask
<somerville32> sladen: How is the writeup coming for the Oslo weekend?
<sladen> somerville32: haven't started, when's it needed for
<somerville32> sladen: Today
<sladen> somerville32: sounds good
<crimsun> cjwatson: BenC has merged it into ubuntu-2.6.git, should be in the next kernel
<cjwatson> crimsun: what *is* it, though? :)
<crimsun> cjwatson: oh, right. Patches to make your audio work.
<cjwatson> aha
<cjwatson> sure, I can test that
<lamont> jamesh: the libvolumeid patch is going in right after etch
<lamont> Keybuk: we'll have to chat sometime about udev and hwclock and all that fun stuff so that I can understand what ubuntu did to my poor little package
<LaserJock> mdke: is it ok if we make it clearer on SyncRequestProcess who non-MOTU people should subscribe (ubuntu-universe-sponsors in case of Universe packages, ubuntu-sponsors for Main?)
<LaserJock> mdke: sorry that was for mdz
<LaserJock> but he's not here, darnit
<Kano> why is gspca not in the kernel
<mez> hmm - in main, something isnt meant to link against something in universe - right ?
<mjg59> Kano: Because it's crack?
<kylem> society for the prevention of cruelty to animals?
<Kano> it works
<mez> for some reason, installing xorg-driver-fglrx just pulled in gfortran from universe
<LaserJock> mez: because Fortran is awesome ;-)
<Kano> mez: too funny
<Kano> mez: for fglrx i would prefer using my script ;)
<mjg59> Kano: Reading it makes me vigerously unhappy
* mez cant get the darn thing to work
<mez> it just fails on the modprobe :(
* bluefox_ gives mjg59 an FPAV :)
<bluefox_> o.o buki
<geser> !seen infinity 
<geser> has somebody seen infinity here lately?
<davmor2> Query:  In ubiquity you were told in advance of partitioning that there was windows or whatever installed, use remaining space for install?  At what point does it do it in the new partitioner?
<bddebian> cjwatson: I know you are swamped.  Are you ever going to touch kbd-chooser?
<Mez> is there an easy way to find out what packages B-D on any package in a source package
<Kano> dpkg -S file
<Kano> apt-get source result
<Mez> Kano, thats not helpful ;)
<slomo> apt-cache showsrc $package
<Mez> slomo, I know of that, but I want to find out if ANY package B-Ds on a package
<Mez> like apt-cache rdepends
<Kano> build-deps
<Kano> thats easy
<Kano> apt-get build-dep package
<slomo> Mez: ah... that's not that easy... grep-dctrl on the Sources files ;)
<Mez> Kano, reverse build-deps
<slomo> Mez: grep-dctrl -FBuild-Depends -FBuild-Depends-Indep libglib2.0-dev /var/lib/apt/lists/*_Sources | grep ^Package
<slomo> for example
<Kano> Mez: i just use pbulder
<Kano> but ok...
<Mez> Kano, I'm trying to basically code in regression testing for prevu
<Mez> so, it'll build something, install it, then go in and build everything that B-D's on it against it 
<Mez> see if they break
<slomo> then hope that nobody uploads dpkg-dev ;)
<Kano> Mez: i use a reverse pbuilder for that
<Mez> slomo, ?? 
<Kano> that uses the already build debs in higher priority
<Mez> Kano, reverse pbuilder ?
<Kano> basically i call pbuilder
<Kano> but while running i use apt-ftparchive on the results dir
<Kano> and then alll later runs will use that dir
<Mez> Kano, yeah, we have that in my branch of prevu
<Kano> well i have it in a script
<Kano> adopted from a website
<Kano> http://kanotix.com/files/fix/pbuilder-adv.sh
<Kano> just use the commented feisty settings
<Kano> defaults to etch
<Kano> then pbuilder-adv.sh clean
<Kano> first
<Kano> pbuilder-adv.sh build file.dsc
<Kano> later
<Kano> thats cleaner als compiling in your standard environment
<Mez> Kano, you dont know of prevu do you
<Kano> no i dont
<Kano> but that works for me, when i want to build vdr or something 
<LaserJock> Mez: where is your branch of prevu?
<Mez> LaserJock /scratch/development/prevu/hooksnstuff/
<LaserJock> Mez: is https://code.launchpad.net/~mez/+branch/prevu/prevu a good branch?
<Mez> it's not the best ;)
<Mez> probably a bit old
<Mez> https://code.launchpad.net/~ubuntu-backporters/+branch/prevu/dev
<cjwatson> bddebian: sometime this week, I guess
<bddebian> cjwatson: I wouldn't mind doing it for ya but man it's messy :-(
<cjwatson> there's no sense wasting your time on it
<cjwatson> the only possible reason to merge it is to improve the statistics
<cjwatson> and so it might as well be left to somebody who already understands it :)
<bddebian> cjwatson: Just trying to clean up the list. :-)
<vdepizzol> what composite-by-default spec with delivery "Deferred" means exactly?
<mdke> vdepizzol: the question on everybody's lips
<mdke> otherwise known as the "how the heck can you get to see spec change history with launchpad" question
<cjwatson> there'll be an announcement soon; I don't really want to pre-empt it
* cjwatson -> bed
<cjwatson> but basically, means "won't be done in this form for this release"
<Mez> ne1 for a game of frozen-bubble2?
#ubuntu-devel 2007-02-06
<Robot101> hmm, who's responsible for Release files on archive.u.c?
<Robot101> feisty-updates and feisty-securoty claim to be v=6.10, its throwing my apt pinning off
<Robot101> actually, it might not be, but it still looks suspicious.
<rideout> hello, I'm just upgraded to feisty an noticed a problem, when compiling kde trunk, I get a linker error for a class that links to openexr, it isn't linking to libstdc++, this a regression from edgy
<pitti> good morning
* keescook hands off the security baton to pitti and heads to bed
<Mithrandir> somerville32: yes, sure.  Which date is good?
<somerville32> Mithrandir, What ever is best for you.
<Mithrandir> somerville32: uh; which date have you tested and such?  I'm not going to just release a random snapshot and hope it works.
<Mithrandir> Adri2000: no, no point.  There's a missing build-dep on python-dev there.
<somerville32> Mithrandir, I got the impression from Jani that it was already tested.
<Mithrandir> somerville32: well, then there is a particular image which is tested.
<somerville32> ok
<dholbach> good morning
<dholbach> ogra: new dia release
<cjwatson> Robot101: I think it's just because they haven't been regenerated since November, but I'll follow it up
<cjwatson> in fact, since they haven't been regenerated, screw it, I'll just edit them
<cjwatson> or, no I won't, that would break signatures
<cjwatson> Robot101: chasing it up with the soyuz team
* Mithrandir wonders if this is like the quickest implemented spec ever.
<pitti> Mithrandir: changelog-closes-bugs, the dpkg-scanchangelog side?
<Mithrandir> pitti: yes.
<pitti> s/scan/parse/
<Mithrandir> : tfheen@golem /tmp/hello-2.2 > dpkg-parsechangelog | grep ^L
<Mithrandir> Launchpad-bugs-fixed: 1112 1234 2345
<pitti> yay
<Mez> Mithrandir, I've just modified the backports task for wordpress, you closed the dapper backports instead of the edgy backports ;)
<Mithrandir> Mez: oh, sorry.  Thanks.
<Mithrandir> Mez: finger macros..
<Mez> Mithrandir, no problems, the dapper one's approved now too (I lost it in the ether cause it was closes! thank god someone poked me!)
<Mithrandir> Mez: seb will hopefully get to it tomorrow, then
<Mez> cool ;)
<glatzor> mpt: hi, some time ago we talked about the software-properties and about where it should be accessible.
<glatzor> mpt: it would be nice if you could also leave a comment on the universe-multiverse-by-default spec.
<glatzor> mpt: mainly it is about removing s-p from the control center and gnome-app-install. and only making it available in update-manager and synaptic
<seb128> ogra: there is a new dia pre version available
* dholbach hugs seb128
* seb128 hugs dholbach
<Mirv> pitti: thanks for handling bug 82143. feisty will be so bercool for the Finnish people now :)
<Ubugtu> Malone bug 82143 in language-support-fi "Add main-accepted Voikko packages to a seed, language-support-fi should depend on Voikko spellchecking libraries in 7.04" [Undecided,Fix released]  https://launchpad.net/bugs/82143
<pitti> Mirv: yay
<tepsipakki> yes, that's cool
<Adri2000> hi Mithrandir 
<Hobbsee> Mithrandir
<Hobbsee> !!!
<Mithrandir> hiya Hobbsee, Adri2000
<Hobbsee> :(
<Hobbsee> * :)
* Hobbsee kicks her keyboard
* Mithrandir tickles Hobbsee 
* Hobbsee stomps on Mithrandir's feet
<Fujitsu> Greet, Adri2000, Hobbsee, Mithrandir.
<Treenaks> Hobbsee: just blame your cat ;)
<Mithrandir> downtime was a bit larger than anticipated, I forgot to plug in power to one of the RAID drives and wondered why it refused to start..
<Hobbsee> Mithrandir: heh
<Hobbsee> hey Fujitsu 
<Hobbsee> Treenaks: hrm, there's an idea.  or my fish
<Treenaks> Hobbsee: something like that
<Adri2000> Mithrandir: gaupol already build depends on python-dev, and I asked a give-back because there is no problem when building it in my up to date pbuilder
<Mez> Mithrandir, tis an easy mistake to make
<Mithrandir> Adri2000: then why isn't python-dev mentioned in the build log?
<Adri2000> Mithrandir: ah sorry, I apt-get source'd it but didn't see I was downloading the version in debian
<Adri2000> I will request a sync
<Mithrandir> ah. :-)
<Adri2000> gaupol (0.7.2-2) unstable; * Add python-dev build requirement (FTBFS with python2.5)
<Adri2000> :)
<Mithrandir> indeed.
<Adri2000> well, sync already requested
<Adri2000> but needs an ack
<Fujitsu> Adri2000, I'm sure you can organise that :)
* Hobbsee thought Adri2000 was a MOTU
<Mithrandir> iirc, he became one like a week ago.
<Adri2000> I am now, and I've just acked the sync
<cjwatson> mvo: in progress on the edubuntu-on-two-cds g-a-i work now
<mvo> cjwatson: me too
<cjwatson> mvo: you'll get a .disk/add-on file on the add-on CD containing a path to the app-install data directory relative to the CD root (i.e. '/app-install')
<mvo> cjwatson: ok, thanks. I have a patch for update-notifier to get the detection done. and now I'm working on the g-a-i integration
<mvo> cjwatson: we probably need a applications.menu file on the cd as well (from app-install) so that people can customize that
<mvo> customize the menu structure
<mvo> that is displayed
<cjwatson> is there one of those in app-install-data?
<ogra> i guess we need a dedicated one, no ?
<ogra> depending on the shipped apps
<cjwatson> ah, yes
<cjwatson> won't the menu code just automatically ignore the irrelevant bits?
<ogra> i'm fine with manually generating that for one release though ...
<cjwatson> I'd much rather it did it automatically - excluding bits of XML in debian-cd will be a pain
<cjwatson> can I just try it and see what happens? :)
<ogra> heh :)
<mvo> the stock one should work fine 
<mvo> ie. the one that is normally in /usr/share/app-install/desktop
<cjwatson> mvo: ok, done
<mvo> thanks
* cjwatson tries another build
<elkbuntu> hello ogra :)
<fabbione> morning guys
<sladen> jbabies!
* Keybuk prods pitti hopefully
<Hobbsee> Keybuk: he might bite, you know
<kwwii> dholbach: did you see the process-stop icon improvement? I tihnk we should include it
<dholbach> kwwii: ok, I just needed a decision on it
<dholbach> kwwii: will do it
<kwwii> dholbach: great, thanks :-)
<mvo> cjwatson: is the addon cd for amd64 good? should I download it for testing?
<dholbach> kwwii: i'll also add some translations to h-i-t
<mvo> cjwatson: does the .disk/ contain information about the distro/architecture that the cd is designed
<mvo> for?
<kwwii> dholbach: h-i-t? 
<dholbach> kwwii: human-icon-theme
<kwwii> dholbach: hehe, gona take awhile till I know all the acronyms ;-)
<cjwatson> mvo: the 20070206.1 build should be good
<dholbach> np ;-)
* dholbach hugs kwwii
<cjwatson> mvo: it does, but it's not all that easily parseable
<cjwatson> mvo: wouldn't it be easier to look in dists/ ?
<cjwatson> I think that's normal
<cjwatson> dists/blah/Release I mean
<mvo> cjwatson: fine with me, I was just wondering
<Kagou> anyone know why murrine is compiled but not available ?! ( https://launchpad.net/+builds/+build/298279 )
<Hobbsee> Kagou: probably sitting in binary NEW
<dholbach> same as libtapioca-cil, I guess
<Hobbsee> https://launchpad.net/ubuntu/feisty/+queue?queue_state=0&queue_text=murrine
<Hobbsee> yep
<dholbach> yep
<dholbach> can somebody promote espeak to main? I'll do a ubuntu-meta upload later then.
<Kagou> thanks Hobbsee 
<Mithrandir> dholbach: it's not promoted until it shows up in anastacia.txt
<dholbach> hum, it's in there
<dholbach> I wonder why ubuntu-meta's ./update doesn't reflect the seed change I did like 2-3h ago
<carlos> seb128, pitti: Last fesity translation opening went quite well, I'm going to schedule the final opening with Stuart
<seb128> carlos: ah, good
<seb128> carlos: did you make it faster? ;)
<carlos> seb128: it took 2 hours and 15 minutes 
<carlos> instead of 29 hours..
<seb128> what did you change?
<carlos> so I guess the answer is 'yes'
<cjwatson> dholbach: ubuntu-meta will only ever accept items in main
<cjwatson> dholbach: so the promotion has to be done before ./update will pick it up
<carlos> seb128: we disabled a trigger that updates another table that is not needed for this process
<seb128> ok
<dholbach> cjwatson: ok, thanks - that's how I understood it also.
<dholbach> kwwii: uploaded
<kwwii> dholbach: great, thanks :-)
* kwwii hugs dholbach
<dholbach> kwwii: lapo wants to work on tangerine-icon-theme again
<kwwii> dholbach: I never understood what the point was with the tangerine theme...it is very close to the human theme, or?
<dholbach> kwwii: they recolored a bunch of tango icons to make the whole feeling smoother (we use Human, then fallback to Tangerine, then Tango, then GNOME, then hicolor)
<kwwii> dholbach: ahaa, now I get it
<pitti> carlos: yay!
<kwwii> dholbach: good to see that people are being productive :-)
<dholbach> yeah :)
<Robot101> is feisty going to ship with pulse as default?
<elmo> edgy has madwifi-ng right?
<Robot101> pulseaudio
<Ng> yes
<Robot101> if so, could I recommend /etc/libao.conf having the default driver as pulse? then ogg123 and mpg321 will work.
<elmo> how do I tell madwifi-ng from madwifi?
<Keybuk> elmo: ifconfig | grep wifi0
<elmo> Keybuk: I had to modprobe ath_pci manually, and even then it didn't detect the card
<Keybuk> odd
<elmo> it's yet another f"^#$ing intel macbook
<asac> pitti: are -dbg packages automagically generated in future?
<elmo> these things follow me around like lost puppies.  and like lost puppies, I just want to kick them
<pitti> asac: not -dbg, bug -dbgsym packages are automatically created since edgy
<pitti> asac: I called them -dbgsym in order to not conflict with the already existing -dbg packages
<pitti> asac: we don't need the -dbg ones any more, but removing them all would be too much (and pointless) work
<asac> pitti: ok so we don't need one for thunderbird ... fine :)
<Keybuk> elmo: lspci -n -v > #ubuntu-kernel
<pitti> asac: yep
<pitti> asac: if you touch the firefox package, feel free to remove that one, too
<thom> elmo: new macbook(pro) atheros parts aren't supported yet
<pkl_> thom: by Edgy, or by madwifi-ng?
<asac> pitti: ah ok ... and apport-retrace is ment to be run by developers/bug-triagers vs. the user himself?
<thom> pkl_: latter
<thom> needs new HAL
<pitti> asac: yes, so far; however, I'm working on an automatic solution
<mjg59_> pitti: I can't get apport to stop giving me crash dialogs for the same application
<mjg59_> Even if I tick the "Don't tell me again for this version" box
<pitti> mjg59_: it will show up again once the binary gets touched
<thom> pkl_/elmo: http://madwifi.org/ticket/1001 or so; kyle was thinking about trying to rip the hal out of osx
<asac> pitti: gogo ;)
<Kano> hi, why do linux-headers require libc6?
<elmo> thom: ! because there's no potential license issues with that :-P
<thom> yeah yeah, didn't say it would go in the distro :P
<mjg59_> pitti: I haven't done anything that ought to touch the binary
<pitti> mjg59_: do you have an ~/.apport-ignore.xml, and does the process in question run as your user?
<mjg59_> pitti: I do, and it does
<mjg59_> mtime is in January
<pitti> mjg59_: can you put /var/log/apport.log somewhere?
<mjg59_> pitti: www.codon.org.uk/~mjg59/tmp/apport.log
<mjg59_> Oh, hang on, 403
<mjg59_> Try again
* cjwatson attempts to port usplash to libx86
<cjwatson> belatedly
<mjg59_> pitti: Eh, it's been rotated
<mjg59_> pitti: Hm. I just got a crash dialog without anything appearing in apport.log
<mjg59_> pitti: It seems to be the apport dialog (it's got the "Ignore future crashes of this program version" button)
<pitti> mjg59_: hm, /var doesn't happen to be mounted noatime for you or so?
<mjg59_> No
<cjwatson> Kano: because executables in the scripts subdirectory are linked against it
<Kano> i really dislike that the libc6 is differnet than in etch
<mjg59_> cjwatson: Should just need you to drop x86emu and link against libx86 instead of lrmi.o
<cjwatson> mjg59_: yup, that's what I'm doing
<cjwatson> Kano: use a chroot, and deal
<mjg59_> Ok. Let me know if there's any trouble.
<Mithrandir> we should sync libx86 first, though
<Mithrandir> since it's not in the archive, at least wasn't a week or so ago
<cjwatson> I apt-get sourced it today
<Mithrandir> oh sure, it's not hard, we just need to do it.
<mjg59_> pitti: Anything useful I can provide?
<Kano> cjwatson, that linux-kernel package creates more than 1 kernel it seems. how to compile only one?
<Mithrandir> Kano: it's on the wiki
<mjg59_> Kano: The package is designed to build all flavours.
<pitti> mjg59_: so, do you get the same report displayed in apport-gtk over and over, or do you actually have new crashes in between?
<Kano> the generic one would be enough for me
<mjg59_> pitti: New crashes in between
<pitti> mjg59_: log file would still be interesting
<mjg59_> telepathy-butterfly is utterly funted
<mjg59_> pitti: There's nothing in the logfile
<pitti> ugh
<cjwatson> Kano: prod debian/rules, it should be obvious
<Nafallo> cjwatson: rock on! :-)
<Kano> will look into it
<pitti> mjg59_: which process crashes?
<mjg59_> pitti: telepathy-butterfly
<mjg59_> pitti: It doesn't have a "restart program" option
<Nafallo> cjwatson: feel free asking me to test usplash if you need it later :-)
<Kano> is there a new source available which is 2.6.20 final based?
<cjwatson> we do need to promote libx86 though
<cjwatson> Nafallo: if it works for me I'll just punt it at the archive; I'm sure you'll notice ;-)
<pitti> mjg59_: ah, it's a python crash then, no SIGSEGV or so
<mjg59_> pitti: Right
<pitti> mjg59_: right, those cannot go into the log file, since they are called as user
<Nafallo> cjwatson: :-(
<Nafallo> cjwatson: :-) even
<mjg59_> pitti: Ok. That explains the lack of logging, but not the fact that it keeps showing me the dialog :)
<pitti> mjg59_: right, then I know what's wrong
<mjg59_> pitti: Ok, cool. Do you want a bug filing?
<pitti> mjg59_: in apport I check the 'ExecutablePath', which is still 'python2.5' at that time
<mjg59_> pitti: Ah! Figures.
<pitti> mjg59_: bug report would be nice
<pitti> mjg59_: so for interpreted programs I need to check mtime of the interpreted script, not mtime of the interpreter
<Mithrandir> cjwatson: fyi, sync request filed.
<pitti> mjg59_: thanks for pointing that out
<cjwatson> pitti: what's the difference between "Packages proposed to be included into main" and "Unreviewed packages" in UbuntuMainInclusionQueue
<cjwatson> Mithrandir: please reject it. It's already there.
<cjwatson>     libx86 |     0.99-1 |       testing | source
<cjwatson>     libx86 |     0.99-1 |      unstable | source
<mjg59_> pitti: apport or python-apport?
<cjwatson>     libx86 |     0.99-1 | feisty/universe | source
<Mithrandir> cjwatson: oh, ok
<Mithrandir> cjwatson: meh, ok.
<pitti> mjg59_: it's just one source, 'apport'; the particular binary is python-apport, but that's not really important for the bug
<cjwatson> it failed to build on amd64, though
<cjwatson> mjg59_: http://librarian.launchpad.net/5155088/buildlog_ubuntu-feisty-amd64.libx86_0.99-1_FAILEDTOBUILD.txt.gz
<Mithrandir> I have a fix for that somewhere.
<pitti> cjwatson: good question, I didn't see this section before; iwj?
<mjg59_> cjwatson: Needs to build with backend=X86EMU or something, which I thought rules did but I may have been wrong
<cjwatson> looks like just incorrect build rules - it shouldn't be using lrmi on amd64
<cjwatson> debian/rules looks to be using spaces wrongly
<mjg59_> Eh, could be
<mjg59_> Feel free to NMU a fixed version to Debian :)
<cjwatson> I'll prod it once my amd64 box upgrades, if Tollef doesn't beat me to it
<pitti> cjwatson: that section should just be merged into unreviewed, I figure
<mvo_> ogra: the support for edubuntu-on-two-cds should be finished with the recent upoads of u-n, g-a-i and python-apt. please test. there are some warts left, but that seems to be mostly ui-glitches
<Mithrandir> cjwatson: nah, I'd need to dig it out of somewhere so I'll just leave it to you, but you seen to have identified the problem, so. :-9
<Mithrandir> s/9/)/
<mjg59_> Kano: Check git.
<iwj> fabbione: So do you have actual boxes with root on lvm and the standard setup ?  Are they using lilo or grub ?  And when update-initramfs runs, what runs lilo ?
<iwj> This stuff all looks quite broken to me.
<cjwatson> mjg59_: is it in bzr or anything?
<fabbione> iwj: i have them yes. they are using grub (/boot is not on lvm). no idea about lilo
<fabbione> iwj: note that I am montreal now so i don't have access to all of them
<mjg59_> cjwatson: Nope
<fabbione> iwj: the default install autopartitioner will always keep /boot outside lvm
<iwj> fabbione: OIC
<iwj> fabbione: OK.  AFAICT anyone who is using lilo with ubuntu atm is completely SOL.
<fabbione> iwj: if people force /boot on LVM, only lilo *might* work
<iwj> fabbione: Yes, but everything and its dog runs update-initramfs and nothing runs lilo.
<fabbione> iwj: i do have a server with lilo but it's still running breezy... 
<iwj> Do you run lilo by hand ?
<fabbione> yes i do because
<fabbione> because of old memories...
<iwj> Yes.  Well.
<fabbione> yeah you get my point
<iwj> Very wise of you is all I can say.
<fabbione> it's a production server and  i can't cope with minimal breakage there
<iwj> I think I might try to fix that with an initramfs hook script, but after feature freeze.
<fabbione> but i have machines we can test on
<fabbione> as many we like
<iwj> Test boxes aren't a problem really.  I have a perfectly good test setup here.  Well, when I say perfectly good I mean that it demonstrates very well all of the things that are hosed.
<fabbione> iwj: ehehe ok..
<iwj> But it's nice to be a bit reassured that it's not just me.  It's definitely a case of "this couldn't possibly work" and the answer seems to be "it doesn't".
<fabbione> iwj: the whole raid/lvm thing is busted... we do agree and needs fixing..
<cjwatson> I suspect that at the moment it would be best fixed in kernel-package
<fabbione> so it's just not us
<cjwatson> which is what is *supposed* to take care of running boot loader installers
<fabbione> cjwatson: the kernel does run lilo on upgrades
<cjwatson> oh I see, it's stuff other than the kernel, ok
<fabbione> the issue that iwj is thinking about is that we do run a lot of update-initramfs
<fabbione> triggered by other pkgs
<iwj> cjwatson: update-initramfs which is run by the postinsts of about a dozen packages will break your boot.
<iwj> Unless we fix it to run lilo.
<fabbione> yeps
<cjwatson> yeah, sorry, forgot about that
* iwj puts it on the paper bug list for dealing with later.
* fabbione gets an extra cup of coffee
<iwj> Still, I'm making surprisingly good progress.
<fabbione> anyone wants some? mneptok is really good as coffe maker :P
<cjwatson> mjg59_: you'll have an NMU as soon as I can convince the damn thing to build on powerpc, which I think will take upgrading my Debian chroot from prehistoric
<iwj> I have / on lvm and I think I can boot it (one more test to do).
<mjg59_> cjwatson: Ah. PPC may still be an issue.
<pkl_> everyone who installs Ubuntu on an Intel Mac uses Lilo...
<iwj> We should get the ftpmasters to make links for all of {unstable,testing,stable,oldstable,old,ancient,prehistoric} on archive.debian.org.
<iwj> pkl_: Presumably they are used to all of this crazy lossage ?
<mjg59_> pkl_: Not nowadays
<mjg59_> iwj: grub used to fail with the Mac bios emulation, but that's been fixed for some time
<iwj> Is watershed wrong to expect /var/run to exist ?
<fabbione> iwj: do you have a second for a dpkg question?
<iwj> mjg59_: Aha.
<iwj> fabbione: Sure.
<pkl_> Grub doesn't work on bootcamp.  There's an article in the latest Linux Format (MacBook HowTo/February) which tells people to use lilo :-) 
<mjg59_> pkl_: No, it really does
<fabbione> iwj: is there any specific reason why dpkg -l doesn't output the epoch in the version?
<iwj> fabbione: My mistaken belief at the time that people wanted pretty rather than complete output.
<iwj> See also field truncation.
<fabbione> iwj: the field truncation happens only when directing to a terminal.. i noticed that
<fabbione> when redirected to a file it comes in full
<iwj> I really need to make  dpkg -s DTRT if you pass it no package names.
<fabbione> but still no epoch
<fabbione> hmm
<iwj> fabbione: I think that's a bug.
<fabbione> ok thanks for the explanation.. 
<fabbione> mind if i file a bug to get epoch?
<iwj> NP.  Sure.  Sorry :-).
<fabbione> iwj: sorry for what? thanks for the help :)
<iwj> Assign it to me.  Sorry for making it wrong to begin with :-).
<pkl_> mjg59: since when was it fixed, I tried installing edgy under bootcamp about a month ago, and it failed.  Even if its fixed, articles are still saying use lilo anyway.
<mjg59_> pkl_: I don't know precisely when it was fixed, merely that it's been fixed.
<fabbione> iwj: if it has gone unseen for all this time, i guess not that many did really care..
<mjg59_> Anyway, it's hardly unusual for articles to contradict documentation.
<iwj> If there are people using lilo they must be having a pretty fun time.
<evand> bootcamp, refit and grub work fine for me (short of not being able to use the keyboard in grub)
<fabbione> iwj: done thanks. bug #83567
<Ubugtu> Malone bug 83567 in dpkg "dpkg -l doesn't display the epoch" [Wishlist,Confirmed]  https://launchpad.net/bugs/83567
<pkl_> Yeah, articles often don't follow documantion or are plain wrong.  Fact of life.  I wasn't reading the article for myself :-) just seeing ehat was being said etc.
<iwj> fabbione: Ta.
* iwj waits for 4x update-initramfs.  Damn, we need triggers.
<fabbione> iwj: you can specify what version you want to upgrade..
<fabbione> update-initramfs -u -k $version
<pkl_> evand: when I found wifi didb't work under edgy, that was reason enough to run Linux only in Parallels.
<cjwatson> pkl_: as mjg59 says, that's been fixed since. There were two issues: one was grub trying to use BIOS calls that bootcamp didn't emulate (AIUI), and the other was grub not supporting GPT so you had to use a tool called mbrsync to copy the GPT into the MBR partition table (which is no longer necessary)
<cjwatson> pkl_: the latter part was certainly broken in edgy
<evand> pkl_: If it's the same model (BCM4328 wifi), just use ndiswrapper.
<cjwatson> pkl_: that's not fixed in grub upstream though, just in Ubuntu's grub (though I got the patch from the upstream mailing list)
<mjg59_> Please don't say "Just use ndiswrapper"
<cjwatson> mjg59_: at the moment it's failing due to lack of sys/io.h
<mjg59_> cjwatson: Yes, PPC doesn't have port i/o
<pkl_> evand: yes I saw that on the madwifi ticket mentioned previously.  I've lots of machines running Linux, and so it wasn't important for me to get it running under BootCamp.  I wanted to see how it worked "out of the box"
<cjwatson> mjg59_: oh, joy
<cjwatson> I'll just build the thing on amd64 then
<mjg59_> cjwatson: So that actually needs to be implemented in libx86
<mjg59_> I'll rip the code out of X at some point
<evand> pkl_: If it's the same model (BCM4328 wifi), just use ndiswrapper.
<evand> sorry
<evand> wrong terminal
<xerxas> cjwatson,  are you an uploader on the ftp ?
<cjwatson> xerxas: why?
<xerxas> I have a package that have been advocated on revu but it doesn't appear on the distribution , for sth like 10 days 
<cjwatson> -> #ubuntu-motu
<xerxas> I'm waiting that package to package other things 
<xerxas> cjwatson,  I've asked on #ubuntu-motu 
<cjwatson> don't ask here, then
<Hobbsee> xerxas: wasnt it decided that it was in binary NEW?
<xerxas> Hobbsee,  ahh , and then ? 
<xerxas> where it is ? 
<cjwatson> oh, sure, if it's in NEW, that can be dealt with here
<xerxas> what is binary new ? 
<cjwatson> what's the package name?
<Hobbsee> xerxas: then you wait for it to be fixed, or poke
<xerxas> libtapioca-cil 
<xerxas> Hobbsee,  I don't see any build problems 
<cjwatson> NEW queue> https://wiki.ubuntu.com/UbuntuDevelopment#head-48234c6bdac8679844493fcc4613f128adf658eb
<Hobbsee> xerxas: all new binaries, including those from packages new to ubuntu, go into binary NEW queue.
<Hobbsee> aka the abyss, maybe
<cjwatson> rubbish
<cjwatson> it's nowhere near that bad
<Hobbsee> :P
<Hobbsee> oh, sorry, SRU process is the abyss
<cjwatson> xerxas: processed; it'll be in the archive in about an hour
<Mithrandir> it's been in binary new for four days, which is a bit much, but not horrendous
<xerxas> cjwatson,  cool 
<xerxas> what does that mean ? 
<xerxas> cjwatson,  can I apt-get install libtapioca-cil in 2 hours on a feisty ? 
<cjwatson> yes
<Hobbsee> xerxas: wait ~1hr, then download it
<xerxas> what happened ?
<cjwatson> I processed it
<xerxas> should I bug you again if my next package is slow to appear ? 
<Mithrandir> no, please don't
<cjwatson> not me personally
<Hobbsee> xerxas: the archive admins bite if poked too much
<cjwatson> and no, you shouldn't bug in general
<Hobbsee> dont they, Mithrandir?
<cjwatson> we have a queue for this
<Mithrandir> binary new is processed as a queue, there is no need to poke us unless it's urgent for some reason.
<Mithrandir> Hobbsee: we breathe fire first, because we like our food roasted.
<Hobbsee> Mithrandir: hhe
<Hobbsee> *hehe
<Mithrandir> of course, if it's urgent or holding up something, feel free to ask.
<xerxas> ok , in my case, I need that package to continue my work , I can bug you, right ? 
<Keybuk> you don't need that package to continue your work -- you can build it yourself for testing
<xerxas> but the next package is the final, so I'll just wait .. 
<Hobbsee> xerxas: of course, the next package, if it's new to ubuntu, will sit in NEW too.
<xerxas> Keybuk,  it works, but then if I want to pbuild sth that require that package , I need the uploaded package
<Mithrandir> xerxas: no, you don't.  You can easily set up a local repository.
<Hobbsee> xerxas: then there's pbuilder magic that gets around that.
<Keybuk> no you don't; set up a local repository for pbuilder
<Hobbsee> Mithrandir: you dotn even have to go that far, do you?
<xerxas> me fault then :)
<Mithrandir> Hobbsee: maybe not, but I have all the stuff running already, so it's easier that way.
* Hobbsee hadnt thought of a local repo for that sort of thing.  just bindmounting the working dir, installing the extra dep, then debuilding.
<xerxas> too much things to learn :)
<Hobbsee> heh
<Mithrandir> Hobbsee: oh, sure, that works too
<Hobbsee> that's what i tend to do, at least
<Mithrandir> or you could just build in a regular system, there's nothing magic about chroots.
<Hobbsee> Mithrandir: yes, only uploads ftbfs whenever someone else tries to build them.
<Mithrandir> and if building in a regular system produces a different binary or different depends than what you get in a chroot, that's (arguably) a bug.
* Hobbsee had one fail SEVEN TIMES for that reason.  owner of said package got thoroughly larted.
<Mithrandir> or rather, it's a bug, but we can discuss the severity.
<Hobbsee> good point
<iwj> Aaargh.  If you say to udev   RUN+="one thing", RUN+="another thing"   it only does the second1
<iwj> s/1/!
<Keybuk> it does?  arguably that's a bug
<cjwatson> it's certainly not as documented
<Keybuk> cjwatson: it kinda is
<cjwatson>        RUN
<cjwatson>           Add a program to the list of programs to be executed for a
<cjwatson>           specific device.
<Keybuk> yes, but read above as to the actual format of each line
<Keybuk> each line is a series of key/value pairs
<Keybuk> it never says you can use a key more than once :p
<cjwatson> oh, I didn't realise iwj was literally talking about a single rule there
<Keybuk> you can certainly do...
<Keybuk> something, something, RUN+="one thing"
<Keybuk> something, something, RUN+="another thing"
<Keybuk> on separate lines
<iwj> That's pretty damn lame.
<Keybuk> iwj: work around it for now -- I'll chat to kay later about fixing it
<iwj> Right.
* iwj uses sh -c.
<Keybuk> you could do something like:
<Keybuk> something, something, GOTO="run_the_thing"
<iwj> Yes.
<Keybuk> GOTO="dont_run_the_thing"
<Keybuk> LABEL="run_the_thing"
<Keybuk> RUN+="one thing"
<Keybuk> RUN+"another thing"
<iwj> But actually sh -c is nicer because it involves only one copy of watershed.
<Keybuk> LABEL="dont_run_the_thing"
<Keybuk> ok
<iwj> Also, why oh why oh why doesn't it use PATH ?  (Not that that's annoying me today but it's very silly.)
<zul> Mithrandir:/win 12
<zul> oops..
<Keybuk> because most of PATH is usually not available while udev is running
<Mithrandir> zul: you're not in my windows # 12. :-P
<Keybuk> so it instead makes people put things in /lib/udev and defaults to there
<zul> Mithrandir: obviously :)
<popey> is cdimage. down?
<popey> well, files unavailable
<cjwatson> popey: in particular?
<popey> http://cdimage.ubuntu.com/releases/feisty/herd3
<popey> "The requested URL /releases/feisty/herd3 was not found on this server." 
<cjwatson> works fine here ...
<popey> aha
<popey> herd-3
<cjwatson> ah yes, I was following the links ;-)
<cjwatson> did something link to the URL you gave?
<popey> hehe
<popey> a support ticket, dunno where he got that url from tho
<popey> https://answers.launchpad.net/ubuntu/+ticket/3528
<iwj> Yay!  Finally I have defeated it.
<iwj> it = udev+lvm2+devmapper+lilo+aargh
<pitti> mjg59_: fixed the apport ignoring bug (one of these cases where it takes 20 minutes to write the test case and 10 seconds to fix the bug...)
<cjwatson> iwj: Well done on fixing aargh. That one has been bugging me too.
<mjg59_> pitti: Heh
<mjg59_> pitti: Thakns!
<fabbione> cjwatson: i am having a small problem with preseeding netcfg. basically the 2 interfaces (one standard realtek and a wireless) keeps swapping name
<fabbione> cjwatson: is there a way i can tell netcfg to skip the wireless reliably?
<fabbione> or make sure to always use the fixed one, no matter of the name?
<fabbione> (this is on a dapper install)
<Keybuk> seed /etc/iftab so they don't swap?
<cjwatson> fabbione: not within netcfg AFAIK; I think the right answer is to make netcfg preseedable with a MAC
<cjwatson> you could seed /etc/iftab from a preseed/early_command if this is a CD install, or from /preseed.cfg in the initrd if this is a netboot install
<fabbione> MAC can change
<fabbione> i mean this is a test box out of N for massive install
<Keybuk> what can't change?
<elmo> 915resolution is in main for feisty right?
<Keybuk> elmo: I hope not!
<fabbione> Keybuk: what do you mean?
<fabbione> Keybuk: if i preseed iftab, it won't match at the next machine
<Keybuk> fabbione: what about the two interfaces is unique, and cannot change?
<fabbione> the model
<Keybuk> if the MAC can change, you can't use that to uniquely identify them
<fabbione> one is realtek and one is ipwsomething
<cjwatson> it's fairly straightforward to implement per-machine preseeding
<Nafallo> elmo: universe
<cjwatson> although a bit of a pain in the initrd, granted, but you could make it a boot option
<Keybuk> elmo: install xserver-xorg-video-i810-modesetting instead
<cjwatson> then the DHCP server can set it per-machine
<Keybuk> elmo: you'll have *MUCH* better luck, plus projectors will work, and kittens will come back to life
<mjg59_> Keybuk: Uh, no
<mjg59_> It won't give any projector-based advantages
<fabbione> cjwatson: i have no control over the dhpcd
<cjwatson> !
<Keybuk> mjg59: it does, because you can then just RandR to different resolutions for the projector
<mjg59_> Keybuk: No, it won't
<Keybuk> mjg59: with 915resolution, that doesn't work, because that only programs one mode into the card
<troy_s> is the gksudo source code on bzr somewhere?
<cjwatson> effective netboot preseeding assumes control over the dhcpd
<mjg59_> Keybuk: Uh, that's really not true.
<Keybuk> mjg59: works for me
<Keybuk> mjg59: then what is true?  because the above is what Keith told me
<mjg59_> 915resolution doesn't just program one mode. It modifies one mode.
<Keybuk> right, and what it modifies it to is hard-coded in a particular config file?
<mjg59_> You still have all the other modes
<mjg59_> Yes, but your bios will still have 1024x768 and so on
<Keybuk> isn't that the one it reprograms?
<mjg59_> I sincerely hope not
<mjg59_> If it is, that's a bug in our package rather than anything else
<elmo> ok, so, all I care about is the macbook having working video out of the box :)
<Keybuk> with 915resolution, I couldn't get my laptop to talk to a projector
<Keybuk> with modesetting everything just worked
<elmo> whether that's -modesetting or 915resolution, I don't mind
<Keybuk> and I can change resolution to whatever I want
<fabbione> Keybuk: do you know if udev-udeb can be preseeded to blacklist module loading?
<Keybuk> fabbione: it cannot
<fabbione> (if you remember)
<fabbione> ok
<Keybuk> it would be module-init-tools-udeb anyway
<Keybuk> and that can't either afaik
<elmo> mvo_: ping
<Keybuk> mjg59: you'd recommend 915resolution over the modesetting video driver?
<mjg59_> Keybuk: No
<mjg59_> Well, not for 915 and higher
<mjg59_> But a great deal of its extra functionality is limited for us because we have relatively ancient X
<Keybuk> well, yes
<mjg59_> xorg 7.2 will be out next week - are we planning on shifting?
<Keybuk> haven't got anybody to do the shift for us :-/
<mjg59_> Yeah, thought that might be the problem
<Keybuk> we've having lots of luck hiring the X.org maintainer position
<Keybuk> unfortunately all the luck is bad
<mjg59_> It's a shame - all the code to move to randr 1.2 for feisty exists
<mjg59_> And when I say "xorg 7.2 will be out next week", I mean "it's already all been released except for the docs"
<mvo_> hello elmo
<elmo> mvo: hi - is it a known bug (in edgy) that searching for '915' or 'resolution' returns nothing in add/remove programs?
<mvo> elmo: add/remove only contains stuff that has a .desktop file
<mvo> elmo: 915resolution apparently does not have one
<elmo> mvo: oh
<mvo> I assume this is what you looked for, right?
<elmo> hmm, how confusing
<elmo> mvo: yes
<mvo> elmo: sorry. the idea for add/remove is to only show "end-user" applications
<mvo> and that includes desktop files, otherwise its hard for end-users to find the programs :)
<mvo> elmo: if you think 915resolution should be there, I can add it. we have a special section for stuff like codecs and plugins and the like
<elmo> mvo: no, it's fine - I just forgot about the .desktop thing.  which is reasonable, it's just hard to explain to a new user
* mvo nods
<pitti> Riddell: I need a simple heuristic check whether the current session is KDE (for Gnome I use 'pgrep -u 1000 gnome-session'); what's a typical process for a KDE session?
<Riddell> pitti: ksmserver iseh kde equivalent of gnome-session
<pitti> Riddell: thanks
<ogra_> meh, any archive admin around who could push thin-client-manager through new ? its student-control panel with new name and new binary names
<pitti> ogra_: source or binary new?
<pitti> ah, I see
<ogra_> both
<pitti> ogra_: it's really just a rename?
<ogra_> thin-client-manager -> source; thin-client-manager-backend (all the cli functions of student-control-panel), python-tcm (all functions that could go into py modules); thin-client-manager-gnome (the gnome frontend and glade stuff from student-control-panel)
<ogra_> apart from being a rename it implements the features from https://wiki.ubuntu.com/StudentControlPanelSpec
<ogra_> (one of them is "Generalisation of SCP", which means renaming it to thin-client-manager)
<ogra_> ... and splitting it
<cjwatson> hooray, no more confusing acronym
<ogra_> hehe
<ogra_> well, tcm is a nonfood chain selling stuff at coffeeshops in germany ...
<geser> Mithrandir: do you know what happend to the last python2.5 build on amd64? LP reports a successfull build but the debs didn't hit the archive yet
<ogra_> i strill find it confusing :)
<pitti> ogra_: ok, a quick check looks good
<ogra_> thanks 
<pitti> ogra_: accepted
* ogra_ needs to seed it ...
<ogra_> thanks even more :)
<pitti> ogra_: it'll need a binary NEW after it built
<pitti> ogra_: please ping me again
<ogra_> yep
<pitti> ogra_: shall I remove s-c-p?
<ogra_> willdo
<ogra_> from feisty, yes please
<pitti> ogra_: (I guess the transitional package shuold be built from t-c-m)
<pitti> ogra_: btw, the current t-c-m doesn't build a transitional package, will you still add that?
<ogra_> yep
<ogra_> i didnt find it FF critical ... will be done before next herd
<pitti> right, no problem
* pitti removes s-c-p
<pitti> ogra_: ^ done
<ogra_> thanks ! :)
<Mithrandir> geser: no, sorry.
<iwj> fabbione: I'm a bit confused by the status of https://blueprints.launchpad.net/ubuntu/+spec/udev-mdadm.
<iwj> Have you done anything about or to it ?
<iwj> Keybuk: Hmm, I see that you were the person who wrote "Most of the work for this to be supported has been done in Debian, ensuring that mdadm is run on udev events for the md block devices" but AFAICT that's not true.
<cjwatson> there was certainly a good deal done in the mdadm package (by madduck), although it's possible it's not complete
<fabbione> iwj: not since we did talk at UDS..
<fabbione> iwj: there is an general issue that mdadm needs to be converted to udev events
<fabbione> iwj: because as it is now, if a device appears later than when we run the script, it's all doomed
<fabbione> iwj: if you have time to look at it, it would be great, otherwise i guess i will have to work extra time next week
<iwj> fabbione: I'm just checking that I'm not missing something because the info in the wiki seems to be wrong.
<fabbione> iwj: Keybuk did misinterpreted what has been done in Debian
<iwj> IC
<iwj> I don't really have time now to set up a root-on-md test setup (or at least, not if it's going to be as much of a PITA as root-on-lvm).
<fabbione> iwj: basically mdadm in Debian *after* a raid is started, will make sure that a udev event is generated
<Keybuk> nothing to do with me
<Keybuk> I just drafted the spec
<Keybuk> other people discussed it and decided what was done in Debian was sufficient
<iwj> "What was done in Debian" seems to be nothing.
<fabbione> Keybuk: ok.. the comment was from you.. so i assumed
<fabbione> iwj: but it doesn't solve the main issue that we need to wait for devices to appear before we run mdadm
<fabbione> anyway.. the spec needs to be implemented...
<iwj> The spec currently says `Implementation:  * Merge mdadm from Debian.   * Upload udev 103."
<iwj> But those have both been done and we still have no support.
<iwj> So before I go and just make something up I'd like to check that (a) that's OK with everyone and (b) we have some way to test it.
<iwj> fabbione: So do you have a root-on-md system you don't mind breaking ?
<fabbione> iwj: i am ok if you want to do it otherwise i will take it i guess. (b) yes we do.. plenty
<fabbione> iwj: i have 2 of them
<cjwatson> iwj: I think the information in the discussion came from me, because I was aware that a lot of work *had* been done in Debian's mdadm since edgy
<fabbione> iwj: and they can break
<cjwatson> iwj: it's not nothing - but it may well not be enough
<iwj> cjwatson: They seem to have reverted quite a bit of it.
<cjwatson> I'm entirely happy to be wrong there
<fabbione> iwj: i can even give you console on one of them if you want
<Keybuk> if it's been reverted ... then the spec isn't wrong, merely out of date
<iwj> `Removed all udev-related stuff.' etc.
<cjwatson> joy
<fabbione> iwj: i am happy to give you access
<iwj> Keybuk: "[not]  wrong, merely out of date".  You're obviously an incurable optimist :-).
<keescook> goood mornin'
<iwj> fabbione: Well, I'm not really familiar with mdadm so if you want to take it feel free.  Otherwise I'll RTFM and make something up.  I'm not too happy about the timing of my discovery that it wasn't already basically done ...
<fabbione> iwj: if it's ok with you, i will work on it next week. I won't be able any time before.
<iwj> fabbione: That's fine by me but you will need a freeze exception, surely ?
<fabbione> iwj: implementing this spec means fixing  plenty of bugs
<fabbione> iwj: not really....
<fabbione> we have bugs that must be fixed and they rely on that spec
<fabbione> so look at it as fixing bugs
<fabbione> or implementing a spec
<fabbione> makes no diff
<iwj> fabbione: Err, OK.  You can argue that with Tollef or Scott or Colin or someone.
<iwj> I don't have an opinion.
<iwj> Keybuk: ^
<iwj> or,
<iwj> cjwatson: ^
<fabbione> iwj: sure don't worry.. i have enough bugs and arguments... we all have 24h/day :)
<fabbione> iwj: and 2 hands
<iwj> *snort*
<Keybuk> iwj: when would you have time to work on it?
<iwj> Well, I could do it right now this instant.
<cjwatson> iwj: up to Scott as far as I'm concerned
<iwj> But Fabio seems to prefer to do it himself, which I can understand as I think he actually knows more about mdadm.
* cjwatson happily delegates sideways
<Keybuk> iwj: the spec is assigned to you -- please go ahead and do it
<iwj> Keybuk: OK.  But consider this a heads-up: since I've discovered that the spec turned out not to be true any more, it may miss the feature freeze deadline.
<Keybuk> noted
<Keybuk> you're pretty familar with the races and the solution employed for lvm, so you've already got a head start on it
<fabbione> Keybuk: we need it done. FF or not FF.. systems with / on raid or / on lvm on raid are unbootable atm
<iwj> Keybuk: True.
<fabbione> and we bugs tracked in LP
<fabbione> cjwatson: do you happen to remember what's the equivalent of finish-install in dapper?
<cjwatson> fabbione: prebaseconfig
<fabbione> cjwatson: thanks
<fabbione> iwj: worst case scenario, i am here on IRC till thursday your late afternoon and then back on monday
<fabbione> iwj: so if you need any help or you have questions... i will be around
<fabbione> iwj: also if you want access to hw
<iwj> fabbione: Right, thanks.
<iwj> I'll see how I get on.
<iwj> I'm currently RTFMing and writing a designlet. 
<fabbione> iwj: no problem.. sorry you are getting this spec dumped on you..
<cjwatson> hmm, usplash still not happy
<iwj> Oh, I was expecting this spec but I wasn't expecting it to be lies :-).
<exobuzz> knetworkmanager is very nice, but there is a problem, since multiple network profiles are broken in knetworkconf, which makes the while knetworkmanager less useful (when it comes to cabled networks).
<exobuzz> https://launchpad.net/ubuntu/+source/kdeadmin/+bug/73788
<Ubugtu> Malone bug 73788 in kdeadmin "Network profiles completely broken" [Undecided,Confirmed]  
<iwj> fabbione: So AFAICT mdadm-using systems pretty much always have an mdadm.conf to tell it what to do ?
<fabbione> iwj: yes and you can use /usr/share/mdadm/mkconf to generate one on the fly if there is no config
<fabbione> iwj: the major issue here is: install system -> boot -> add raids -> reboot.
<fabbione> iwj: or better.. one of the major issues..
<fabbione> mdadm.conf is not updated in that specific case
<iwj> Right, I don't propose to fix that now.
<fabbione> right
<Riddell> exobuzz: so set up a static config and network manager will stop interfering
<iwj> Yay!  If you run   mdadm -As   3 times in parallel, two of the copies segfault.
<exobuzz> Riddell: thats not the problem
<exobuzz> Riddell: the problem is that knetworkconf (which knetworkmanager calls for settings up static networks), has a profile feature, which doesnt work
<Riddell> oh, right, it's full of bugs is knetworkconf
<Riddell> I can add it to my todo of stuff to look at, but can't promis it'll get fixed in time
<exobuzz> but as knetworkconf is so broken, perhaps knetworkmanager shouldnt "call it"
<exobuzz> ok
<fabbione> iwj: FTW!
<exobuzz> thanks :)
<Riddell> it's still the best thing we have for many uses
<alex-weej> crash reporting has b0rked and i'm getting this in my kernel log: [32666.206448]  Core dump to |/usr/share/apport/apport.5908 pipe failed - any ideas?
<pitti> alex-weej: file a bug against apport, please (sorry, I'm in a terrible hurry)
<pitti> alex-weej: I see the problem
<alex-weej> pitti: ok
<pitti> thanks!
<Keybuk> hmm, where did OFTC go>
<kylem> dunno, it's been screwy all day for me
<Keybuk> irc.oftc.net has address 127.0.0.1
<Treenaks> maybe they're having scr1pt k1ddi3 problems?
<iwj> There is a kernel bug here.
<Keybuk> -- The kernel bug attacks.
<Keybuk> -- You hit the kernel bug.
<Keybuk> -- The kernel bug dies.
<iwj> So far I've forgotten to not have X running at the time.
<jwest--> Keybuk: tor?
<Keybuk> jwendell: ?
<jwest--> ?
<Keybuk> uh jwest--: ?
<jwest--> 127.0.0.1 is tor right
<Keybuk> what's tor?
<Keybuk> apart from a hill with a granite outcrop on it
<elmo> an anonymizing router/proxy thing
<jwest--> localhost
<jwest--> for anonymioty
<Keybuk> 127.0.0.1 is localhost
<Keybuk> there ain't no IRC server running on localhost :p
<_ion> irc6.oftc.net resolves to 2001:968:1::6666
* Keybuk doesn't have irc6 yet
<Keybuk> I have a routed block, but haven't yet had sufficient CFT to do anything about it
<Keybuk> ipv6 either :p
<pkl_> http://tor.eff.org/
<jwest--> to connect to freenode they have an onion server for it something
<maswan> Keybuk: yes, they are having serious packeting issues
<maswan> now they have a total of one server in rotation though. :)
<Keybuk> I don't get the anonymizing proxy thing; I spend sufficient time and money making sure I have real, routeable IP addresses -- hiding that seems pointless
<maswan> Keybuk: It depends on if you are doing something that you need to hide.
<Treenaks> Keybuk: but you don't live in China
<Treenaks> (to give the 'standard' argument)
<maswan> Like posting political blogs in iran/china or cracking nsa.gov machines in the US
<Keybuk> if the proxy is outside of china, how does that help?
<elmo> the whole live in china argument is very valid, it's just a shame tor is mostly visible for all the jerkwads (who don't live in restrictive countries like china or iran) who use it purely to abuse other people
<_ion> Or posting political blogs in the US in a few years, by the looks of things ;-)
<Treenaks> elmo: every anonymising service will attact unwanted guests
<Treenaks> elmo: (and always will)
<Keybuk> proxy outside of china => great firewall of china will show the real IPs => doom
<Keybuk> proxy inside china => subject to chinese law => can get real IPs by force of law => doom
<Keybuk> unless I'm missing something
<Treenaks> Keybuk: it's encrypted and doesn't keep logs by default
<elmo> Keybuk: it's an onion based system, knowing the IP of the first hop doesn't get you much
<Keybuk> encryption isn't useful
<Keybuk> as you just set up a man in the middle that proxies that
<Treenaks> Keybuk: it is if They are sniffing the link between you and the Tor network
<Keybuk> certification of the remote end is useful, assuming that it can obtain the fingerprint of the cert by some means other than across the internet
<Keybuk> if over the internet, it's trivial to intercept and change the cert
<Keybuk> Treenaks: assuming It is used for illegal purposes, and They care about it, then They will do this kind of thing
<Treenaks> Keybuk: you choose your own entrypoint
<Keybuk> and where does the list of entrypoints come from?
<Treenaks> Keybuk: so all you have to do is know someone 'outside' you trust
<Spads> the sad thing about tor is that the location of all tor servers is necessarily published
<Keybuk> so you can intercept the list of servers, and change them
<Keybuk> we used to do this all the time with file sharing apps :p
<Spads> making it less of a whack-a-mole for those who wish to suppress it
<Treenaks> Keybuk: ask the EFF, they seem to believe in it
<Keybuk> in order for it to be "useful" for people in $STATE, it needs some component that is not transmitted over a medium commonly intercepted by the government of $STATE
<Keybuk> otherwise if I were government of $STATE, I'd cheerfully intercept it and log it
<Keybuk> and never tell anyone
<Keybuk> I would have thought these kinds of things are great for them -- makes it easy to spot the naughty people
<Spads> Treenaks: it was Seth Schoen at the EFF who first told me of Tor's limitations
<Keybuk> the thing about governments is that they like to get what they want
<givre> cjwatson: there is something strange with fuse package. binary of the latest version are available for sparc and powerpc since friday night, but not yet for i386 and amd64. Is this normal ?
<Treenaks> Keybuk: the thing about a repressed people is that they always seem to find a way
<Keybuk> they don't think anything of turning up at a major ISP and using arguments like "we've got a big truck outside, we're going to confiscate every single piece of equipment in your data centre ... unless you fancy helping us find people downloading kiddie porn off usenet?"
<Keybuk> Treenaks: sure, I'm not disputing the will to be non-repressed ... I'm just slightly amused that Tor seems to make it easier for the government to intercept than simply not using it at all
<elmo> Keybuk: at which point you say "sure, he's the tor server" and they find nothing useful?
<elmo> anyway, this is wildly off topic
<Keybuk> elmo: ime, they'd cheerfully replace it with one that looks and acts the same -- but logs everything
<Keybuk> of course, me is with the UK government and police, who may be somewhat more with it and evil than the chinese police :p
<elmo> Keybuk: and someone from the ISP lets the tor community know that that server is compromised?
<Treenaks> Keybuk: You need a government? A popular cable ISP here will start filtering all web traffic soon
<Keybuk> elmo: wouldn't happen -- they would have used some very serious leverage to get into the ISP in the first place
<Treenaks> Keybuk: officially only the child porn.. but who knows what else#
<Keybuk> leaking that wouldn't be a CLM, so much as a FLM
<elmo> Keybuk: *shrug* I still think it'd happen - if someone cared enough about tor in the first place to risk the CLM of getting one put in place, I think they'd be find a way to anonymously report  it as compromised
<Keybuk> assuming they know at all
<cjwatson> FLM?
<Keybuk> Freedom Limiting Move
<cjwatson> givre: dunno, dinnertime, sorry
<givre> cjwatson: that's ok, it's dinner time for me too anyway ;)
<Keybuk> (I realise the above shows a high degree of pessimism; however the "Chinese Argument" requires it.  If you have that kind of reason to use something like Tor in the first place, you have to assume that, by the same reason, the thing you're using is the first target for compromise)
<LaserJock> do MIRs have to be completely processed by FF or only filed?
<LaserJock> Keybuk: do you know about ^^ ?
<Keybuk> is the MIR for a feature?
<LaserJock> hmmm, hard to say
<LaserJock> it's for Edubuntu-on-2-CDs so I guess yes
<LaserJock> the build/install structure is complete
<LaserJock> so now we just need to populate the 2nd CD
<Keybuk> ogra's call then
<LaserJock> k
<mvo> LaserJock: edubuntu-on2-cds? this should be mostly done, no?
<LaserJock> well, yes, according to the spec you, ogra, and cjwatson got all the needed pieces
<LaserJock> but now we need to get package to put on the 2nd CD
<LaserJock> we're moving the educational apps that we used to ship (gcompris, KDEEdu) there
<LaserJock> but we wanted to put more, especially high-school and uni level
<LaserJock> so I'm not sure if the actual CD contents count as a part of the feature
<mvo> LaserJock: aha, I see. yeah, the infrastructure should be in place. its generic enough for any kind of add-on CD
* mvo wants a GAMES CD
<LaserJock> the spec itself was about the needed infrastructure
<LaserJock> uh oh, sounds like a slippery slope ;-)
<Kano> hi, i dont get how the source package of the 2.6.20-6 kernel was done
<Kano> a) kernel-wedge is a build-dep
<Kano> b) it searches for abi/2.6.20-6.11/abiname
<Kano> but there is only 2.6.20-5.7
<fabbione> Kano: all of this is documented in the wiki
<fabbione> if you don't understand look at debian/rules and debian/changelog
<Kano> but debuild -S even fails on the original sources...
<fabbione> this isn't a support channel
<Kano> that seems a packageing error
<fabbione> no it's not... 
<fabbione> as i said.. read debian/changelog
<fabbione> all of it
<bddebian> Heya
<mjg59_> Hm.
<mjg59_> Compiz nearly works fine in feisty, but there's no window decorations.
<rtg> zul: You there?
<zul> rtg: kind of 
<rtg> zul: I just wanted to introduce myself. I'm working with Ben Collins on the 2.6.12 release of the kernel.
<rtg> zul: He says he has spoken to you about this?
<zul> rtg: ah hello
<zul> rtg: yep
<rtg> zul: Good, though I'll be  of little use for the next week as I am out until the 14th.
<zul> rtg: not a problem im always around
<rtg> zul: I'll get in touch upon my return.
<zul> sure
<mjg59_> Ah, works if I nuke my gconf settings
<mjg59_> Wonder whose fault it is...
<mjg59_> Except that windows aren't being updated when I type stuff into them
<Amaranth> mjg59_: yes, fun bug
<Amaranth> mjg59_: should be fixed in git, i'll pull out the patches for it if you want
<mjg59_> Amaranth: Winning
<mjg59_> To which one?
<Amaranth> the updating thing
<Amaranth> the commit say something about sync, iirc
<mjg59_> Ah, ok
<Amaranth> it's two parts
<Amaranth> the second part makes unredirect_fullscreen_windows work correctly
<Amaranth> oh, there is a patch in there that fixes the dbus plugin too, if you're pulling in patches for the package :)
<mjg59_> Amaranth: Heh. Could you do me a huge favour and file a couple of wishlist bugs with them in?
<mjg59_> Someone else seems to be taking care of it now, which is great
<Amaranth> gandalfn and seb128 are doing it, i guess
<Amaranth> i'll file the bugs, sure
<Amaranth> actually a full update to current git would only be a good thing, as far as i can tell
<mjg59_> Amaranth: Sounds fine by me
<LaserJock> any almighty Ubuntu core-dev gods know of a script to check deps for MIRs?
<mvo> MIR?
<bhale> main inclusion
* mvo should go to bed
<mvo> thanks
<LaserJock> I'm trying to track down all the deps
<bhale> you can run each of build-dep and depends through apt-cache show | grep Filename
<bhale> and search for !main
<bhale> but you knew that
<LaserJock> sure, but I was hoping for a faster solution
<bhale> few minutes of bash
<LaserJock> I've got a lot to go through
<bhale> ...bash?
<LaserJock> my bash skills aren't good enough to get it to recursively do that and handle |'s , etc.
<bhale> apt-cache showsrc beagle | grep Build-Dep | sed -e "s/, /\n/g"
<bhale> will give you a seed file
<bhale> clean it up with awk
<bhale> for i in `cat mydepfile`; do apt-cache show $i | grep Filename | grep -v main; done
<bhale> something like that, untested
<bhale> rinse and repeat for runtime deps
<LaserJock> k, let me play around with that
<Burgwork> Amaranth: do you know when 0.3.7 will be released? is it worth waiting for it
<Burgwork> ?
<sfllaw> Mithrandir: What isolinux.bin do you use for the LiveCD?
<Mithrandir> sfllaw: the one in the syslinux package, iirc
<sfllaw> I suspected so.
<sfllaw> Thanks.
<Mithrandir> unsure about the version; I can find that out tomorrow if you need it.
* iwj gets udev-mdadm working.  Time to stop for today.
<Nafallo> hi jono! :-)
<jono> hey
<jono> :)
<gnomefreak> jono: i havent had a chance to check mail but tomorrow i will check and respond 
<jono> gnomefreak: no worries :)
<LaserJock> jono! just the man I've been looking for
<jono> LaserJock: :)
<LaserJock> jono: you wouldn't mind if jokosher was in Main would you?
<jono> in Ubuntu Main? serious?
<LaserJock> I'm trying to add to Edubuntu
<jono> ahhh cool
<jono> I think it should be fine for 0.9 (our next release)
<jono> but not for 0.2, too buggy
<LaserJock> jono: ok fine, be that way then ;p
<jono> LaserJock: :)
<jono> yeah we have nailed *loads* of bugs for the next release
<LaserJock> that's one less MIR I have to file
<jono> :)
<jono> wow, Jokosher in main :)
<jono> is ubuntu and edubuntu main the same?
<LaserJock> yep
<jono> wow cool
<LaserJock> well, we'd like to have more music apps
<jono> is this confirmed that it will go into main?
<jono> can we announce this?
<LaserJock> hang on, hang on
<LaserJock> you said 0.2 was too buggy
<jono> yeah, I mean 0.9
<jono> 0.9 is released in March
<LaserJock> hmm
<Keybuk> jono: that's an interesting way of doing releases
<jono> :)
<Keybuk> personally I tend to say that there are *loads* of bugs for the next release
<Keybuk> omitting the "nailed"
<jono> heh
<jono> I know Jokosher will enter main at some point, and I am happy if it is not with 0.9 if needed
<jono> the main focus right now is bug fixing
<sistpoty> LaserJock: what do you want to include into main?
<sistpoty> (just curious)
<LaserJock> nothing, nothing
<LaserJock> nothing to see here ;-)
<sistpoty> hehe
<LaserJock> sistpoty: working on a 2nd CD for Edubuntu
<sistpoty> LaserJock: oh, nice
<LaserJock> I'm trying to narrow down what I can get in
<LaserJock> the deps are killing me ;-)
<jwest--> if i have the 6.06 version of ubuntu, can i upgrade to 6.10 with ease? (including all other software?)
<sistpoty> jwest--: you can upgrade all software installed from official repositories, but this question is rather suited for #ubuntu than for this channel
<cbx33> LaserJock, but i bet the deps are easier to find now ;)
<cbx33> hehehe
<cbx33> mwuhahah
<jwest--> gotcha
#ubuntu-devel 2007-02-07
<Amaranth> Burgwork: (late) no timeline for 0.3.7, i don't think
<Burgwork> Amaranth: ok, just wondering
<null_> hello
<null_> does the network-admin in FF support wpa etc for wireless auth ? other than just plain ole wep
<Nafallo> network-manager does for some cards. you probably want to ask those questions in a supportchannel as #ubuntu in the future.
<Nafallo> null_: ^
<null_> ok ill check there
<Keybuk> if all else fails, you can edit /etc/network/interfaces and add WPA information by hand -- see /usr/share/doc/wpasupplicant/README.modes.gz
<Keybuk> if all else fails, you can edit /etc/network/interfaces and add WPA information by hand -- see /usr/share/doc/wpasupplicant/README.modes.gz
<FantasticFoo> nobody knows the answer on the normal #ubuntu channel, so i'm asking here, sorry for the stupid question:
<FantasticFoo> anyone know what ubuntu edgy package the "X development libraries" are in?
<Hobbsee> FantasticFoo: xlibs-dev?
<FantasticFoo> Hobbsee: thanks! :)
<Liberis> hi
<Liberis> i sign a bug
<Liberis> in ubuntu
<TheMuso> c
<evand> Is posting a link to a main inclusion proposal in ubuntu-devel-discuss required, or is it only if discussion is needed?
<LaserJock> it's probably a good idea
<evand> LaserJock: Ok, thanks
<nixternal> LaserJock: you ever seen Ubuntu loose the shutdown/restart buttons before? anyone for that matter?
<pochu> nixternal, that happened to me :)
<nixternal> pochu: hwo did you fix it?
<pochu> nixternal, sorry, not that, I lost hibernate and suspend
<pochu> :(
<nixternal> hrmm
<nixternal> similar
<pochu> ok
<pochu> starting g-p-m
<pochu> it wasn't started
<pochu> because a bug
<nixternal> ahh
<pochu> nixternal, that bug was fixed a week ago or so, I think
<nixternal> ya, this is with an Edgy system I believe
<pochu> oh, I'm talking about Feisty :)
<pochu> bug?
<nixternal> I had him dpkg-reconfigure to see if that did anything, but it didn't
<nixternal> It very well could be, but he has no clue what he was doing when it started, and now it is always like this. He can't shutdown or reboot from the GUI
<pochu> nixternal: I mean, bug number? :)
<nixternal> ahh, he hasn't filed one I don't believe
<pochu> nixternal, is he running a laptop?
<nixternal> desktop
<pochu> no problem on my edgy :)
<nixternal> ya, same here
<pochu> nixternal, don't you know if that is logged anywhere?
<nixternal> I haven't seen it before
<nixternal> this is a first I have heard of it
<pochu> me too :)
<pochu> nixternal, do you know the command to show the "turn off" menu?
<nixternal> can't say that I do, I am from the Light Side, i.e., KDE :)
* nixternal hides
<LaserJock> :p
<pochu> nixternal, you wanted to say the Dark Side ;)
<pochu> :D
<nixternal> no no, this is the dark side :)
<pochu> hehe
<nixternal> my lord, the fix was easy
<nixternal> Menu: System > Administration > Login Window
<nixternal> In the "Local" tab of "Login Window Preferences", make sure that "Menu Bar: Show Actions menu" is checked.
<pitti> Good morning
<siretart> hi folks! morning pitti :)
<pitti> hi siretart 
<siretart> pitti: I just uploaded a gxine which build depends on firefox-dev *urg*. ugly, but builds cleanly in my main-only chroot :/
<pitti> siretart: great
<siretart> ulgy, because this way you need firefox instealled in the chroot
<pitti> siretart: it needs that to build a firefox plugin, I figure?
<siretart> pitti: right
<pitti> siretart: well, ffox, xulrunner, no big difference for a chroot, is it?
<siretart> build depending on xulrunner is much less to install
<siretart> that's one reason darren does this in debian right now
<siretart> but well, if there's no xulrunner in feisty/main, then so be it
<\sh> moins
<pitti> my main network is broken again :/ I'll work offline for a bit and come back later
<jumpula> is the list of requirement for multiverse packages around somewhere?
<jumpula> +s
<infinity> jumpula: Must be legally distributable.  That's about it.
<givre> cjwatson: did you had some time to look at the fuse issue (no binary of the latest version for i386 & amd64)
<jumpula> infinity: so, what would i need to do to get some packages in multiverse? :)
<jumpula> the motu pages talk mainly about universe
<infinity> jumpula: MOTU handles multiverse as well.
<infinity> jumpula: It's "Universe without free licenses".
<jumpula> okay
<jumpula> so the procedure is the same?
<infinity> Yes.
<dholbach> good morning
<infinity> givre: A quick poke leads me to the very scientific conclusion that the binaries "just effin' disappeared", and I'm unclear as to why.
<infinity> givre: I'll poke a bit more for forensic reasons, then requeue the builds on those arches.
<jumpula> so, basicly all i need to do is to upload the package for revu
<givre> infinity: ok, thanks. 
<jumpula> and (if i undersootd correctly) in multiverse, there are no limits to that that the software has to compile under the that release of ubuntu it's put in :)
<jumpula> seems i do many typos today..
<cjwatson> sfllaw: isolinux.bin> we use whatever the current syslinux package in the archive is
<cjwatson> givre: infinity's better-placed to investigate this than I am anyway, as a buildd admin, so I'm glad he beat me to it. :)
<cjwatson> givre: for the record, though, I didn't touch a computer between your previous request and your request just now ...
<cjwatson> infinity: they seem to be in /srv/launchpad.net/builddmaster/failed-to-move/
<cjwatson> infinity: what's that directory for, anyway?
* tfheen grumbles at file systems.
<Treenaks> tfheen: it's the power connector
<infinity> cjwatson: For complete and utter bustication.  I didn't even look there, as I'm used to it not being populated.
<tfheen> Treenaks: no, not this time.
<cjwatson> jumpula: packages in multiverse do still have to be distributable legally; that's a limit that for some reason many people forget
<cjwatson> jumpula: so, for example, stuff with incompatible licensing can't even go in multiverse
<infinity> cjwatson: It seems to be more populated recently than I'm comfy with.  Perhaps something to get Team Soyuz to poke at, if you've not already alerted them.
<dholbach> tfheen is back again!
<cjwatson> I haven't. I only just noticed
<cjwatson> I have absolutely no clue what it's for
<tfheen> dholbach: until my raid is finished fsck-ing at least.
<Treenaks> tfheen: how large is it?
<tfheen> Treenaks: 2.6TB
<dholbach> so it's tfheen for another week :)
<jumpula> cjwatson: the licencing is not the problem
<jumpula> just that the build system is vary debian sarge specific
<jumpula> *very
<infinity> cjwatson: Basically, failed-to-move means the queue processed it correctly (as an accept, reject, whatever), then the final step (moving it in the filesystem) blew up.
<infinity> cjwatson: Which... Shouldn't happen.
<infinity> cjwatson: So there's clearly an ugly bug staring us in the face here.
<infinity> cjwatson: Can you bring it up with cprov when he wakes up?  I'm dangerously close to quitting for the day.
<cjwatson> jumpula: the only reason to put something in multiverse is licensing. Stuff doesn't go in multiverse just because it's low-quality.
<cjwatson> infinity: sure
<jumpula> and there is no exceptions?
<cjwatson> jumpula: if it's low-quality, it just shouldn't be in the archive
<cjwatson> jumpula: no, that's the entire purpose of multiverse
<cjwatson> multiverse == universe but not free
<jumpula> i see
<Chipzz> infinity: "disk full" would be a foolish guess I guess? ;)
<seb128> ogra_: hi, do you have the new dia on your TODO?
<seb128> ogra_: if you are busy I can have a look at it
<cjwatson> Chipzz: rename(2) shouldn't fail because the disk is full ...
<cjwatson> not on the same fs anyway
<cjwatson> Oh, unless the directory had to grow to accommodate it I guess. But regardless, I don't think drescher's disk has quite filled up recently. It's been close, but ...
<cjwatson> /dev/cciss/c0d0p1    558550928 495834352  34343780  94% /
<seb128> making gdm store its socket to /var/run (instead of /tmp) is fine in all case or need some special consideration (like /var/run is available on any system)?
<cjwatson> /var/run should be fine
<cjwatson> ----r-S--- 1 root       root           4 2007-02-03 09:58 system-tools-backends.pid
<cjwatson> what the heck sort of permissions are those
<seb128> cjwatson: weird indeed
<dholbach> doko: if you have a bit of time, can you help me finding out why  http://librarian.launchpad.net/6336405/buildlog_ubuntu-feisty-amd64.glom_1.3.6-0ubuntu1_FAILEDTOBUILD.txt.gz  ftbfs?
<infinity> dholbach: Seems pretty self-explanatory.
<infinity> dholbach: int and ssize_t are not guaranteed to be equal, they're mismatched types.
<dholbach> infinity: when I looked at the code, I didn't quite see what to do
<infinity> dholbach: Fix the code to use consistent types, I suppose.
<infinity> dholbach: Which, granted, may require reading enough of it to figure out which type to standardise on.
<dholbach> that doesn't really help me, but I'll try something
<infinity> dholbach: If that's too vague, I'll let you bug doko to help you fix it while I go off and do something more like Not Work. :)
<dholbach> infinity: enjoy it :-)
<Hobbsee> infinity: does such a thing exist for you?
<cjwatson> I've promoted libx86 to main on the basis that an earlier version of the code was already in usplash, so it's just a split-out
<mantiena> Hi all
<dholbach> doko: upstream is working on a patch, so no need to look at it
* dholbach hugs doko
<tfheen> iwj: your rendezvous stuff, etc seems to have broken cryptsetup volumes.
<mantiena> cjwatson: hi, do you have some time to talk about gfxboot-theme-ubuntu package ?
<iwj> tfheen: Go on ...
<tfheen> iwj: apparently, the mount.crypt call returns before the devmapper device exists.
<iwj> Hrrrrrm.
<tfheen> iwj: it should be trivial to reproduce if you install libpam-mount and cryptsetup and follow the instructions in libpam-mount's README.Debian for setting up an encrypted volume which is mounted on login.
<tfheen> I don't think it's relevant, but the backing volume for the encrypted file system is an evms volume.
<iwj> That doesn't sound relevant.
<iwj> The rendezvous stuff is specifically to prevent this from happening.
<tfheen> iwj: maybe libpam-mount needs fixing too?
<iwj> Err, I doubt it.  The rendezvous wait is done in libdevmapper.
<iwj> I'll investigate.
<tfheen> thanks.
<tfheen> do you want a bug about it too?
<Keybuk> infinity: doing a rebuild, are we? :p
<iwj> tfheen: bug> Not unless you feel the need.
<tfheen> iwj: as long as it gets fixed, I'm happy. :-)
<tfheen> Keybuk: there's one scheduled now, so yes, I'd assume so.
<cjwatson> mantiena: depends; what do you want to know?
<Riddell> pitti, seb128: either of you fancy poking software-properties through NEW?
<seb128> Riddell: I'll do archive processing in a few min
<Riddell> I'll give you a hug when you do :)
<seb128> good ;)
<carlos> pitti: ping
<pitti> hey carlos
<carlos> hey
<mvo> yes for software-propoerties!
<mantiena> cjwatson: I wanna ask why there are lots of almost identifical strings in .po file ?
<cjwatson> iwj: I noticed in an upgrade today that everything which calls update-initramfs (volumeid, udev) is installed, complaining about devmap_name not existing, and then libdevmapper1.02 is installed
<cjwatson> iwj: seems that there's a risk that upgrades might never end up with devmap_name in the initramfs
<mantiena> cjwatson: "^Start or install Kubuntu" ,  "^Start or install Ubuntu", "^Start or install Xubuntu" ,etc
<mantiena> cjwatson: why do not use just one string "Start or install %s" ?
<Treenaks> mantiena: because they might be translated differently in different languages (because 'Ubuntu', 'Xubuntu' and 'Kubuntu' all start with different letters)
<cjwatson> mantiena: because they're all needed in different CDs, and your solution doesn't work
<cjwatson> mantiena: "Ubuntu" is transliterated in a number of languages, for instance
<iwj> cjwatson: Hrm.
<cjwatson> In Korean it is 
<cjwatson> In Hebrew it is 
<iwj> cjwatson: Did the Recommends support spec not get implemented ?
<cjwatson> In Macedonian it is 
<mantiena> cjwatson: this is not a problem, we can have strings "Ubuntu", "Kubuntu", "Xubuntu etc in .po file
<cjwatson> mantiena: for every possible case variant etc.? I don't think so. I'd much rather do it this way, thanks.
<iwj> I suppose I could have the dmsetup postinst run update-initramfs.
<cjwatson> mantiena: assembling strings at run-time is generally not a good idea.
<cjwatson> iwj: even with the Recommends spec, I don't think it guarantees configuration ordering
<mantiena> cjwatson: ok, but now translators need do a lot of job manually :(
<cjwatson> mantiena: it's only a few strings; they have huge numbers more than that
<StevenK> seb128: Are you around? I wanted to talk about AboutUbuntu if you have time.
<mantiena> cjwatson: and also there are very easy to make a mistake
<cjwatson> iwj: dmsetup doesn't seem to have been installed in this run, only libdevmapper1.02
<cjwatson> mantiena: I'm sorry, but I am not going to change this.
<iwj> cjwatson: Configuration ordering isn't necessary.  I suppose what's happening is that apt is configuring udev (say) before dmsetup has been installed.
<iwj> cjwatson: I think I'll change it to a Depends.
<mantiena> cjwatson: OK, it's a not big problem for me :-P
<cjwatson> iwj: oh, I don't have dmsetup installed at all
<cjwatson> this was just an update-manager upgrade
<iwj> Harrmpfh.
<cjwatson> bless you
<iwj> Oh well, dmsetup is very small.  People will just have to live with having it.
<mantiena> cjwatson: Btw, if you don't wanna change this, then please tell me  what would be correct way to add new string  "Start or install Baltix" to .po fiile ?
<cjwatson> mantiena: there's an add_text command in po/bin/
<mantiena> cjwatson: simply adding new string to .pot and .po files doesn't help :(
<seb128> StevenK: sure, what about it?
<StevenK> seb128: I wanted it to appear in the System menu, as About Ubuntu if it's installed, but it seems the System menu is static from my investigation.
<cjwatson> mantiena: obviously you need to change isolinux.cfg to match
<seb128> StevenK: it is
<seb128> StevenK: gnome-panel can be patched to do that though
<StevenK> I'm also wondering if losing the Ubuntu page in Firefox is a good thing...
<StevenK> (Launching About Ubuntu will just show the about box, evidently)
<seb128> mdke: ping about help menu change, is your help control center ready to be used (ie: can we drop the help submenu now)?
<mantiena> cjwatson: yea I understand this, but there are another problem - because there are no string "Start or install %s" in gfxboot-theme-ubuntu I can't have line "start or install Baltix" translated to all  languages :(
<seb128> StevenK: if you have better than the firefox page feel free to point it ;)
<cjwatson> mantiena: you couldn't anyway, because of the above transliteration problem
<StevenK> seb128: Well, okay, let me explain myself better.
<cjwatson> mantiena: another reason why this needs to be translated manually is that translators need to select suitable non-clashing accelerator keys
<cjwatson> mantiena: you can't do that automatically
<mantiena> cjwatson: there are no transliteration problem for Baltix - Baltix in all languages is Baltix :-P
<cjwatson> well, not within the .po framework anyway
<cjwatson> mantiena: hahaha bzzzt
<mantiena> :)
<cjwatson> mantiena: that's what I thought about Ubuntu
<cjwatson> mantiena: but it is NOT TRUE
<StevenK> seb128: Currently About Ubuntu fires up firefox will a whole bunch of information about Ubuntu and etc. If it's changed to run AboutUbuntu, all that information isn't there at all.
<StevenK> s/will/with/
<StevenK> cjwatson: Just curious, but how did you find out all of the translations for Ubuntu?
<cjwatson> mantiena: you will also find that some languages decline Baltix into different cases
<cjwatson> mantiena: whether you want them to or not
<seb128> StevenK: I thought you were suggesting an extra item, not to replace the "About Ubuntu"
<seb128> StevenK: is there a spec about that?
<StevenK> Sure
<cjwatson> StevenK: long and painful experience; translator contributions; web-searching in some cases
<StevenK> Eek
<cjwatson> mantiena: generally speaking I try to avoid this problem by not mentioning "Ubuntu" at all, but the boot loader screen is one place where I still feel it should appear
<StevenK> seb128: https://launchpad.net/ubuntu/+spec/about-ubuntu
<cjwatson> StevenK: I still don't know how it works in a number of languages. See https://wiki.ubuntu.com/DistributionDefaultsAndBranding
<mantiena> cjwatson: ok, thanks for info, I already know what I should do :) 
<mantiena> I will make new package - gfxboot-theme-baltix, which will be based on gfxbtoot-theme-ubuntu but will remove several language, which are not suported by Baltix (Baltix is only for European countries, not for India/Africa or China/Taiwan :)
<mantiena> this will improve an usability - in Ubuntu therea re too many languages in gfxboot menu ...
<mantiena> I tested opensuse and noticed, that in suse there are 2x less languages
<cjwatson> I suppose that's one attitude to usability
<cjwatson> "make it not usable at all by half the planet"
<cjwatson> must be nice to have that luxury ;)
<mantiena> cjwatson: yea, but don't forget, that Baltix is soft of local distro
<mantiena> cjwatson:  most of the planet can use another distros :)
<cjwatson> like I say, must be nice to have that luxury
<cjwatson> Ubuntu doesn't, so I don't think it's really fair to criticise this as a usability defect in Ubuntu
<cjwatson> given that it's something we've explicitly tried to target
<seb128> mvo, Riddell: could you fix the debian/copyright for software-properties? it states "Upstream Author: Michiel Sikkes <michiel@eyesopened.nl>" and doesn't mention anybody else where the source files have "Copyright (c) 2007 Canonical Ltd." (and some other years variant) and "Copyright (c) 2006 FSF Europe"?
<iwj> Oh bummer.
<iwj> I see what the problem is and it's going to be tedious to fix.
<Riddell> oh meh, he said he'd fix the FSFE thing
<mantiena> cjwatson: I did several usability tests with non IT people and noticed, that some people simple don't find needed language when press F2, because this list is veeerryyy long...
<tfheen> iwj: sorry. :-)
<mantiena> cjwatson: for Ubuntu it's pretty hard to solve such usability problem, but for Baltix it's simple - just remove unsuported languages :)
<seb128> cjwatson, pitti: what should we do with software-properties? That's source new, it's splited from update-manager which should be correct but the debian/copyright has wrong copyright holders
<mantiena> cjwatson: debian-installer also has same problem
<seb128> tfheen: ^
<tfheen> seb128: if it's problematic, notify the uploader, cc ubuntu-archive and reject the package.
<seb128> can I be lazy and do the "ping mvo on IRC, wait on a fixed upload and accept that one" to avoid the reject mail? ;)
<tfheen> seb128: sure, that works too.
<seb128> ok, thanks
<mvo> seb128: I fix this now 
<tfheen> seb128: but please don't leave the package there after today if he doesn't get around to fixing it.
<seb128> mvo: thank you
<tfheen> since pitti might then come along and spend time on it, which is wasteful
<seb128> tfheen: I expect mvo or Riddell to fix it quickly, looks like Riddell waits for it for some kubuntu work
<cjwatson> mantiena: *shrug* this is a usability problem I'm entirely content to have
<seb128> tfheen: right, makes sense
<mantiena> cjwatson: yea, but I'm very happy now, that you help to find the best solution for Baltix :)
<mantiena> I've tested Ubuntu Edgy and latest Feisty on  lots of new laptops in local compuiter shop and noticed several computers, where Ubuntu doesn't start at all
<mantiena> some of them starts only when I add some special boot parameters, like noapci
<mantiena> s/apci/apic
<mantiena> Computer sellers will never use Ubuntu, if in lots of cases they will nedd to write some boot parameters, which they newer know (and don't want to know)
<mantiena> Are there any way to tix such problem in the right way ?
<cjwatson> file bugs
<mjg59> mantiena: Yes. That's why we have a bugtracker.
<mvo> seb128: uploaded
<seb128> mvo: thank you
<mantiena> mjg59: I know this, I have best Karma in Launchpad from Lithuanians ;)
<mantiena> cjwatson: agains which package I should file bugs ? For example in one laptop Ubuntu works fine until X triest to start, when X tries to start Ubuntu gets frozen (even CapsLock doesn't work)
<mantiena> but when I use noapic boot parameter then such problem dissapears
<mjg59> Probably the kernel. I'm guessing it'll be a drm issue.
<cjwatson> it's either the kernel or X; I'd go for the kernel
<mantiena> this is on HP Pavilion dv6103
<mantiena> but in text mode I don't notice any problems
<cjwatson> as mjg59 alludes, bits of X's functionality actually live in the kernel
<mantiena> cjwatson: so, against which kernel should I file bugs ? this bug is in all ubuntu versions, ( I tested with 5.10, 6.06, 6.10 and latest feisty)
<cjwatson> the latest one that manifests the problem
<mantiena> cjwatson: thanks
<mantiena> btw, anybody knows how Microsoft solves such problems ? I've notices, that Windows starts on almost all laptops, while linux has lots of problems with new ones
<elmo> mantiena: eh, laptop manufacturers test with windows before release?
<seb128> tfheen: when doing syncs we the LPUID to use is the one from the ubuntu-dev member who approved the request (when the bug has been opened by some random user), right?
<stdin> and windows isn't designed to work on such a wide variety of hardware
<mantiena> elmo, stin : yea, it seems you are right, but users think, that Windows is better designed, because more hardware works without problems with Windows
<mantiena> it seems we have only one way from this situation - to force hardware manutacturers like HP to tests hardware with Linux before releasing new hardware to the public
<elmo> mantiena: we can't force them to do anything
<cjwatson> seb128: yes
<stdin> heh, good luck with that mantiena :P
<seb128> cjwatson: ok, just wanted to be sure, thank you ;)
<mantiena> elmo: we can  - for example we can recommend only "good" hardware manufacturers on our web pages, etc :)
<elmo> mantiena: no.  that doesn't force them to do anything
<tfheen> seb128: yes.
<mantiena> elmo: for example all  new and old IBM/Lenovo laptops, which I tested worked fine wth Ubuntu, it seems they are testing  with Linux or maybe simply manufacturing better hardware...
<mjg59> mantiena: No, they're just managing not to hit the bugs in Linux that some other vendors do
<mantiena> but there was lots of problems with ASUS, ACER and DELL
<mantiena> in this weekend we tested more than 70 new laptops
<Keybuk> I've had very few problems with my Dell
<mantiena> :)
<Keybuk> those that I have had have turned out to be simply bugs and been fixed
<seb128> cjwatson, tfheen: and what flag is required to sync from experimental? "-C experimental"?
<cjwatson> this is an ongoing process, and is part of why Canonical now employs four kernel developers
<cjwatson> but you can't fix it just by complaining about it, and there is no magic bullet
* Hobbsee notes mantiena sounds like a mac user.
<mantiena> Hobbsee: hehe, no, I'm not a mac user, I'm simply local Linux developer ;)
<tfheen> seb128: yes
<Hobbsee> "if it doesnt work, dont officially support it"
<seb128> tfheen: thanks
<siretart> iwj: I've just read UdevDeviceMapper spec again. From the reading, it seems that this would also be suitable for having crypto support. What changes on the cryptsetup side would be needed to enabling a crypted root filesystem?
<mantiena> cjwatson: hehe, it seems Canonical will become very big soon ;)
<Keybuk> siretart: obtaining the password
<Fujitsu> cryptsetup already uses usplash, doesn't it?
<siretart> Fujitsu: I disabled it again
<mantiena> Keybuk: yea,  very few Dell laptops had problems, not like Acer or ASUS
<seb128> tfheen: in fact it didn't like it, -S experimental seems to work fine
<Fujitsu> siretart, aw...
<elmo> seb128: IIRC, -S is --from-suite and -C --from-component
<elmo> so -S would make more sense
<elmo> but I haven't looked at the source i months
<seb128> elmo: right, it worked with -S apparently
<elmo> (experimental is a suite or 'distrorelease' in LP terms)
<tfheen> seb128: oh, sorry.  -S as elmo says.  I still mess up those terms.
<siretart> Keybuk: the way I say it seems that it should just work. however, I have users mailing me patches for fixing this :/
<siretart> Keybuk: I'll forward you the email
<Keybuk> it should work, yes
<Keybuk> the entire point of the udev-* specs was to eliminate the races that were stopping things from working
<siretart> mail forwarded
<givr1> infinity: did you find the blackhole that eat fuse binary package ?
<tfheen> whoa, the merged casper actually boots.  On first try.
<tfheen> and kqemu isn't all bad.
<hile> siretart, I'll check today without my patch what actually is wrong with latest cryptsetup initramfs
<siretart> hile: that would be great!
<hile> not now, I'm at work ;)
<siretart> hile: see also what Keybuk sad at 12:43
<heno> tfheen: not sure if you're the right person to ask about this; gnome-speech won't build at 0.4.8 because it now depends on espeak, which was seeded to main but hasn't actually made it in there yet
<iwj> siretart: What Keybuk says.  It should work but it all gets rather asynchronous so you have to think carefully about how to do it.
<iwj> For example, you have to not perpetrate a race like I did yesterday.
<tfheen> heno: just a second, I'll promote it.
<heno> yay!
<siretart> iwj: yes, I imagine. See the mail from hile I just forwarded you
<hile> iwj, basically the problems I have seen are that the /usr/share/initramfs-tools/scripts/local-top/cryptroot script is run before sata device nodes are created
<tfheen> heno: promoted
* heno needs to test our utterly redesigned speech synthesis stack before feature freeze :)
<heno> tfheen: thanks!
<hile> and if it does not wait for the node somehow, you can't ask passphrase either
<tfheen> heno: it needs a publisher run before it's published and I only just missed this one, so it'll be visible in about an hour and a half or thereabouts.
<iwj> hile: Right.  The right answer is usually now not to wait for the node explicitly, but rather to have everything triggered from udev.
<heno> tfheen: that's great, thanks
<iwj> hile: Do you know at the start of boot that you're going to be doing cryptsetup ?
<iwj> If so ask for the password then - before udev gets started - and run cryptsetup later.
<hile> yes
<hile> that's one possibility, yes
<iwj> For mdadm I fudged it to run the local-top script from udev.  That was a bit nasty because it's very heavyweight and the initramfs /scripts/functions expects to inherit stuff from the initramfs init script.
<iwj> But if you actually know what this stuff is supposed to do and what parts of the no-doubt crazy complex config script are actually relevant, you can probably rework it more sanely.
<iwj> Eg for lvm I just run vgscan and vgchange from udev.
<iwj> The right way would be a udev rule which triggered on any relevant block device and then checked if the cryptsetup base device name was present.
<hile> so, first udev rule for 'run cryptsetup when device x appears', that's fine, but how does the 'where is my root device!?!' part be done? is it already automatic?
<iwj> That's automatic.
<iwj> cryptsetup will give it a name and there's a thing waiting for the root fs to appear.
<iwj> It'll mount it and get going as soon as the device node appears.
<iwj> You probably don't want to encode the cryptsetup base device name in the udev rule because udev rules are hairy and you'd end up having to modify it.
<hile> iwj, for cryptsetup, there is a file conf/conf.d/cryptroot which tells anything needed for the setup, for example:
<hile> target=sys,source=/dev/sda2,key=none,lvm=sys-root,lvm=sys-root
<iwj> Right.
<hile> no idea why this has lvm=sys-root 2 times ;)
<iwj> So you have a udev rule which calls  /sbin/check-for-cryptsetup-source-being-there  which is a script which looks to see whether sda2 exists yet.
<hile> and since root=/dev/mapper/sys-root the root mounting part will wait for it to appear?
<hile> I mean, in a asynchronous system, how does mounting the root device itself happen if it does not exist when first called?
<hile> oh didn't read what you said, sorry
<iwj> hile: Right, that part is already taken care of :-).
<iwj> hile: NB that you have to stop your bootloader translating  root=...  into major/minor (which lilo did to me!).  I don't know what grub does.
<hile> well, if we are going to go async with cryptsetup, it needs more work.. siretart, I think for current synchoronus version we still could apply my patches until it has been replaced completely with the async version
<iwj> hile: `current synchoronus version' does what ?
<hile> waits for the source=/dev/sda2 appear, runs cryptsetup on it and maybe vgchange if it's lvm 
<hile> works perfectly fine, current version is just missing the 'wait for device node' loop 
<iwj> Oh, right.  Well yes you can add that as a kludge if you like.
<hile> I like the async solution better as well, in long term
<iwj> Mind you if anything else takes the same approach you might lose.  lvm and md are asynch now but if there are several synch thints they might have to be run several times in various orders.
<iwj> s/thint/thing
<mantiena> cjwatson: I don't find add_text command nor in gfxboot nor in  gfxboot-theme-ubuntu package :(
<hile> ipw, you are so right ;)
<hile> siretart: here in .sa  weekend starts today, and I have no party to go - maybe I'll try writing the async script tonight
<siretart> hile: ok. my inbox is open for you :)
<hile> ;)
<mantiena> mvo: you are developer of update-manager and software-proterties ?
<Keybuk> Firefox's Most Annoying Bug Of The Day: when you type into a text box, it drops down the list of previously typed options and *highlights* the top one, so when you press ENTER you get the top option, not what you typed
<mantiena> mvo: it seems there are no posibility to add CD/DVD disk witj packages in latest software-properties from feisty :(
<elkbuntu> Keybuk, cursor position will do that, iirc
<cjwatson> mantiena: it's in po/bin/add_text in the gfxboot-theme-ubuntu source package. I've got it right in front of me.
<siretart>   Warning: /dev/mapper/hades_stripe-chroot_feisty-real,rendezvous: wait for udev processing timed out
* siretart grrrs
<cjwatson> heno: so, braille-support *nearly* works ...
<heno> cjwatson: yay, cool
<cjwatson> heno: the final step here is to partially undo the change we made to the init script to stop brltty ever running
<heno> cjwatson: we just need to get it tested with actual braille displays now :)
<heno> ok
<cjwatson> heno: since I'm not confident that brltty won't still chew CPU/memory on systems that don't require it, as it used to do, I'd like to do this only in certain situations
<cjwatson> i.e. when it's been configured
<cjwatson> heno: but I'm not sure how to handle upgrades
<iwj> siretart: Yes, my fault.
<iwj> siretart: But harmless if you don't mind the wait.
<cjwatson> heno: I'm thinking of creating /etc/default/brltty, with RUN_BRLTTY="no" by default, which the installer sets to "yes" if brltty is configured
<heno> cjwatson: so it won't just work on a random live CD with a USB braille display attached, you do need to press F5+6 first
<cjwatson> heno: it will if it's not USB-serial; udev will start it
<cjwatson> heno: but USB-serial you'd need to press F5+6, yes
<heno> cjwatson: ah, ok cool
<heno> that's as much as we can ask
<cjwatson> heno: (randomly, wouldn't F5+3 or something be better? then it would be in with the other visual impairments items)
<siretart> iwj: oh. I thought it was my fault
<cjwatson> heno: that's not what I'm concerned about though
<siretart> iwj: the thing what annoys me most with this new udev/lvm handling is, that it is pretty hard to diagnose what actually goes wrong
<cjwatson> heno: what about upgrades from edgy, which didn't have /etc/default/brltty, and didn't run brltty by default?
<heno> cjwatson: so what is the upgrade issue?
<cjwatson> heno: I want to preserve the fact that they didn't run brltty by default - but what about systems that were actually using it?
<heno> ah, I see We're not adding a new package just changing it's behaviour
<Keybuk> siretart: it should be easier, no?  the bit that failed will be obvious
<heno> and there is no way to do that in the upgrade
<TheMuso> cjwatson: I'm guessing its too crazy to check the old init script to see whether the exit line has been commented/removed on upgrade?
<siretart> Keybuk: I really do hope so
<cjwatson> TheMuso: well ... the init script is a conffile, and I was going to change it, so they'd get a conffile resolution prompt
<TheMuso> ah
<Keybuk> siretart: ie. if it's lvm that fails, the lvm failure is in the lvm scripts -- not buried inside another script that calls lvm "just in case"
<TheMuso> of course
<cjwatson> TheMuso: perhaps I could just make sure that 'edit /etc/default/brltty and set RUN_BRLTTY="yes"' will be in the diff context?
<cjwatson> it's not wonderful, but it would be fairly in-your-face obvious
<TheMuso> cjwatson: I don't know. Do those prompts show up in GUI managers?
<cjwatson> if they don't, the upgrade will fail :)
<TheMuso> RIght.
<cjwatson> at least some of them pop up a terminal when a conffile prompt happens
<TheMuso> The thing is, the diff context is only shown when its requested if I remember correctly.
<hile> keybuk, the problem currently has been lvm can't do anything before cryptsetup setups device node for PV
<cjwatson> yeah, but you get a prompt suggesting it
<TheMuso> Right.
<hile> and lvm contained the code to wait for underlying disk partition
<siretart> Keybuk: in this case, I told schroot to create an lvm snapshot. without having read UdevLvm, it is absolutely non-obvious what's actually going on there.
<cjwatson> and if they keep the old version, nothing will change
<TheMuso> Right.
<Keybuk> hile: sure; because we assumed and relied on running things in a pre-perscribed order
<hile> ups, differnt case, forget my stuff.
<cjwatson> So can we Just Do It and release-note it just in case?
<Keybuk> hile: the changes mean that lvm can be run whenever any block device is added, including device-mapper block devices -- all from udev events
<hile> keybuk, and running in that order caused three mintes of wait with PV-ON-LUKS
<mvo> mantiena: what error do you get?
<TheMuso> cjwatson: It sounds sane to me. I can't think of anything better.
<cjwatson> I don't want to screw anyone over, but that applies to sighted users as well as blind ones ... a difficult situation
<TheMuso> Yeah.
<Keybuk> so add disk -> block-device sda1 added -> cryptsetup runs -> block-device dm0 added -> lvm runs -> block-device dm1 added -> mount runs -> profit
<hile> keybuk, yeah I know, just haven't been following what's going on - I know it know
<hile> but let's see, I'll review test and check the current stuff tonight
<siretart> hile: thanks for looking into this!
<siretart> Keybuk: how does udev detect that the newly added block device dm0 contains a pv?
<Keybuk> siretart: volid
<heno> cjwatson: most bof the people using this feature i the real world will currently be readers of ubuntu-accessibility or similar We can post a summary of braille changes there ahead of release (including lots of improvements). I think that should be fine.
<hile> does volid understand LUKS partition signature 
<tfheen> hile: if not, it should be taught.
<cjwatson> and the final ultra-fiddly bit is getting the configured /etc/brltty.conf to the root filesystem despite it still being read-only when the initramfs finishes
<cjwatson> it's going to have to go via /var/run
<hile> and can the system now understand that when we run cryptsetup and the new device node is created for unencrypted data, we would run volid for that again?
<Keybuk> hile: according to /usr/share/doc/libvolume-id0/README, yes
<tfheen> cjwatson: wouldn't /dev/.initramfs be more appropriate?
<cjwatson> tfheen: hmm, probaby
<cjwatson> +l
<cjwatson> thanks
<tfheen> (It is still fiddly and it is just a minor detail, though.)
<hile> that's perfect, since now we actually don't need any fance scripts for cryptsetup at all - just the task to run from udev which will ask passphrase .. and maybe a ignore list if there are encrypted partitions you don't want to setup during boot
<cjwatson> heno,TheMuso: I'd be a lot more comfortable if none of this had to edit /etc/brltty.conf, since that's a conffile and editing it in the installer is storing up trouble for ourselves later. However, it's the status quo (the d-i integration does that already). :-(
<hile> ugh, this starts looking Really Cool ;)
<siretart> hile: Keybuk: it does: http://paste.debian.net/21536
<TheMuso> cjwatson: I understand.
<fabbione> seb128: ping?
<Keybuk> hile: yes, now you can encrypt LVM volumes constructed from RAID-5 striped USB keys each containing encrypted volumes of their own
<tfheen> Keybuk: .. useful.
<hile> hih ;)
<Keybuk> (I would laugh, but I know someone who has RAID-5 USB keys as a use case -- they claim RAID is entirely appropriate given the volatile nature of flash)
<siretart> and have the stuff automounted by gvm :)
<_ion> keybuk: Hehe
<hile> oh, one question about gvm - is there support or plans to say it somehow 'never mount partition uuid X'?
<Keybuk> siretart: the whole gvm vs. udev thing is tricksy
<tfheen> now we just need some useful tools to actually create those things without having to use cryptsetup luksFormat, etc.
<Keybuk> hile: you can do that now, add a HAL fdi for that partition
<hile> I have a usb disk with xfs and 2 hfsplus partitions, and I don't really want to automount the 'Boot OSX' partition. ...
<Keybuk> siretart: ie. in theory, crypted user volumes should be mounted by gvm so it can ask for the passphrase in X
<Keybuk> whereas crypted system volumes should be mounted from udev
<hile> hmm, fine and true... I think that needs UI as well
<Keybuk> sure
<seb128> fabbione: pong
<StevenK> And tell the difference in the initramfs?
<Keybuk> reminds me, need to finish that particular job description for mdz
<tfheen> Keybuk: wouldn't it be more appropriate for udev to have a way to communicate with the user which would look for users at the console, etc?
<Keybuk> tfheen: current theory says not
<hile> just like initializing a luks partition needs UI - adding luks support to gparted should be enough, IMO
<StevenK> seb128: Any thoughts about that spec?
<cjwatson> heno,TheMuso: I'll add a NEWS file entry as in case that helps
<fabbione> seb128: do you have a second for 2 problems (on feisty personal laptop... nothing to do with the other stuff)
<seb128> fabbione: yep
<ogra> seb128, i'll package dia on friday if that suffices 
<fabbione> seb128: jut want to make sure it's known before i file a bug
<seb128> ogra: no hurry
<tfheen> Keybuk: do you have a short summary of why?
<tfheen> (or a pointer to a discussion)
<mantiena> mvo: I don't get any error, simply there are no "Add CD/DVD" button in new software-progerties from Feisty :(
<seb128> fabbione: ok, no problem ;)
<ogra> seb128, ok :)
<Keybuk> tfheen: current theory is that you have various policy agents in the user's session, which use HAL methods to do their work
<seb128> StevenK: no, I'm sort of busy and did read it yet
<Keybuk> examples are gnome-volume-manager, gnome-power-manager, network-manager, etc.
<mvo> mantiena: the version that is waiting in NEW has one in the second tab
<fabbione> seb128: i was dist-upgrading this morning (since last week) and gnome-panel did crash. a few applets like xchat and bluetooth got their own small windows and left alone.. even after gnome panel did restart..
<Keybuk> these have the advantage they can be entirely configured by user policy
<Keybuk> and do the work inside the user's session, so can interact well
<fabbione> seb128: logout -> login fixes.. but still :)
<TheMuso> cjwatson: Won't do any harm.
<Keybuk> obviously you need equivalents outside the users session for when there is no user logged in
<mantiena> mvo: ok, thans, you rescued me from filling new bugreport ;)
<mvo> mantiena: cheers :)
<StevenK> seb128: I'm guessing "did not read it yet"
<seb128> fabbione: we got 4-5 dups of that one already, the backtrace are not really useful (looks like a memory corruption), we are trying to get some valgrind log of the crash if somebody manages to get the panel running with it until it crashes again
<Keybuk> theory says we just run a root policy agent, and decide with policy/console kit to use that only if there's no foreground user with permission
<seb128> StevenK: ups, yep, didn't
<Keybuk> so you can resolve arguments like "who gets to decide what happens when the battery is critical"
<Keybuk> this covers just about everything except
<Keybuk> a) elmo
<Keybuk> b) boot
<tfheen> Keybuk: hm, ok.  (And you need to handle the case of needing user interaction for the user to be able to log in, but unless you have a very particular setup, pam-mount works for that.)
<mantiena> mvo: btw, second tab is named "Internet updates", it's right place for "Add CD/DVD" button ?
<Keybuk> the elmo case is covered by having non-HAL equivalents that we can run from udev
<fabbione> seb128: ok perfect... last thing.. do you know who is in charge of that hw db thingy in Applications -> System Tools ?
<Keybuk> and the boot case of mounting filesystems needed to start all that is also covered by stuff from udev
<StevenK> seb128: I am pondering just throwing it into universe sans a menu entry to test it.
<mvo> mantiena: the tab ordering changed
<Keybuk> this allows the stuff from udev to be simple, and not permit much configuration -- just to get the job done
<Keybuk> and the stuff in the user's session to be very flexible
<siretart> Keybuk: what if you have more than one console user logged it at the same time?
<Keybuk> the alternative would be the stuff from udev being very complex, requiring lots of configuration and interaction
<tfheen> siretart: handled by the root policy agent Scott mentioned above.
<Keybuk> siretart: consolekit
<cjwatson> heno: do you have an opinion on the issue of positioning in the F5 menu that I mentioned above (having the Braille item be next to the other visual impairment items)?
<Keybuk> that can make the decision who wins
<seb128> fabbione: I'll fix the menu item category, the tools has been written by ogra I think and pitti just took over the spec for increase hwdb participation
<fabbione> seb128: ok great thanks.
<seb128> np
<fabbione> ogra: ping?
<Keybuk> my usual example is that we have ifupdown and /etc/network/interfaces for the elmo and "/usr is a network filesystem" case
<ogra> fabbione, ?
<siretart> tfheen: this sounds strange: 2 users are logged in -> root policy, one user logs out -> the other one is at turn. huh?
<Keybuk> but we don't try and configure those for users, instead we give them network manager
<siretart> Keybuk: what's consolekit?
<siretart> 13:50:29 < Keybuk> that can make the decision who wins
<siretart> ok
<Keybuk> and we have things to mount from /etc/fstab in the boot sequence, but for users we use g-v-m
<fabbione> ogra: the hwdb client that's in feisty now.. this morning i got the nice notification.. please partecipate.. blabla.. but it crashes... is it known or should I ask pitti? (and what package is it?)
<ogra> fabbione, ah, yes, we have a bug about the menu placement ...
<Keybuk> siretart: consolekit is a proposed extension that arbitrates between multiple policy agents to decide which one wins
<Keybuk> replacing the current pam_foreground stuff
<heno> cjwatson: well, speech is currently 3, so you suggest 4 and push the rest down?
<fabbione> ogra: i am more worried about the crash to be honest :)
<siretart> Keybuk: neat. is this feisty or feisty+1?
<mantiena> mvo: btw, what you think about rename "Add CD/DVD" buitton to "Add removable media" or something. There are lots of removable media, which can be used for package storage, for example USB memory sticks, removable USB disks, etc
<fabbione> ogra: this is ppc tho..
<Keybuk> it's intended to support multiple users logged in at multiple seats across multiple base stations
<Keybuk> siretart: +1 or +2
<siretart> k
<Keybuk> consolekit can make decisions like "X's screen is locked, Y's isn't - Y wins"
<ogra> fabbione, its hwdb-client ... i'll check it on my ibook later ...
<Keybuk> or "X is on the primary seat, Y isn't - X wins"
<fabbione> ogra: ok thanks
<ogra> fabbione, any specific action that makes it crash ? 
<Keybuk> "X is on the base who's battery is going low, so wins"
<fabbione> ogra: just try to run it
<heno> cjwatson: I'm fine with that. It doesn't change anything for the visually impaired users, who are the ones who depend on docs for this
<Keybuk> "both X and Y are locked, root wins"
<Keybuk> "nobody logged in, root wins"
<Keybuk> etc.
<cjwatson> heno: yeah
<siretart> Keybuk: I'm currently on a sunray system, with ~15 users logged in at work hours, and ~1 in the morning and evening
<heno> cjwatson: so, I'm fine with that
<Keybuk> the "kit" obviously implies that this policy is customisable
<siretart> so things get intersting to configure :)
<Keybuk> *shrug*
<Keybuk> at the end of the day, someone needs to own events :p
<Keybuk> if the UPS is about to die, something needs to happen
<fabbione> ogra: i guess you have already 4 bugs about it
<Keybuk> and 15 different user policies apply
<ogra> fabbione, ok
<tepsipakki> siretart: sunray with LTSP?
<cjwatson> heno: hmm, one glitch is that at the moment if e.g. v3 is disabled then m1 will become F5+3 not F5+4
<siretart> tepsipakki: no, sunray with SRSS
<cjwatson> heno: I think I need to make those numbers consistent regardless of gaps in the orderingg
<mantiena> cjwatson: AFAIK you are main ubiquity develiper, so I wanna tell you about one usablity problem. Ubiquity doesn't fit in 800x600 resolution and t his is pretty important problem, because sometimes in VESA mode Ubuntus starts in 800x600
<cjwatson> ordering
<cjwatson> mantiena: known problem, yes
<siretart> tepsipakki: I don't see any way to make a sunray boot linux
<cjwatson> mantiena: patches welcome
<tepsipakki> siretart: yep, that's a pity
<ogra> siretart, there seems to be none ... else ltsp would support it already (i got one) 
<siretart> ogra: I think I told you that some time ago :)
<ogra> yeah
<mantiena> cjwatson: ok, so, it seems I should report a bug about 800x600 and attach a patch, right ?
<cjwatson> mantiena: no, you should not report a bug, because it already exists
<cjwatson> it's one of the oldest bugs against ubiquity
<mantiena> cjwatson: cool, thans, so, I just need to make one job instead of 2 ;) I like it ;)
<cjwatson> the patch is non-trivial
<cjwatson> the reason that it expands is probably the timezone widget, but that needs to be checked
<geser> seb128: will sync request filed today be processed before UVF?
<seb128> geser: sync filed today will be processed today
<mantiena> cjwatson: wven first screen now doesn't fit in 800x600
<cjwatson> mantiena: all the pages up to the summary page are inside a single GtkNotebook widget, so if one expands they all expand
<cjwatson> this is desirable - they should all be the same size
<mantiena> cjwatson: ok, thanhs for info, btw, it's bug #38442 ?
<Ubugtu> Malone bug 38442 in ubiquity "Doesn't support 640x480 resolution" [Medium,Confirmed]  https://launchpad.net/bugs/38442
<cjwatson> yes
<mantiena> cjwatson: 640x480 can be too hard for me ;) Maybe it would be better to make work at lest on 800x600 ?
<heno> cjwatson: perhaps we should go with letters instead of numbers, so we don't keep running into this ordering problem
<cjwatson> heno: numbers would be fine as long as gfxboot-theme-ubuntu keeps the numbering consistent even when items are excluded
<cjwatson> I can implement that
<cjwatson> perhaps it should also display the number
<heno> cjwatson: sure that would help
<TheMuso> cjwatson: I'm about to hed off to bed. Anything else you need me for, besides testing later? :)
<cjwatson> TheMuso: don't think so, thanks for your help
<doko> seb128: are you processing NEW as well?
<seb128> doko: binary NEW
<doko> slacker ;)
<TheMuso> cjwatson: Any time. I will sync a daily in the next day or so, assuming its in by then, and will test and give feedback.
<seb128> doko: what do you need from source NEW?
<doko> seb128: dict-*
<mantiena> cjwatson: sory for disturbing, but I remembered one more ubuquity usability bug - there are no way to select multibe keyboard layouts. This also is pretty important, because Ubuntu starts with 2 keyboard layouts as default for several lanugaes (like belorusian or Lithuanian ), but after  installation it starts with only one
* Hobbsee wonders why mantiena is not filing a bug under ubiquity for that.
<mantiena> fabbione: hi, could you fix bug #38931 ? it's trivial - only 2 charasters to add to xserver-xorg.config script :)
<Ubugtu> Malone bug 38931 in Baltix "add lt keymap to NONLATINMAPS variable in xserver-xorg.config script" [Medium,Unconfirmed]  https://launchpad.net/bugs/38931
<fabbione> mantiena: i don't do X anymore
<mantiena> Hobbsee: ok, I just asked cjwatson, maybe he will told, that he is agains such changes...
<mantiena> fabbione: so, who does ?
<fabbione> mantiena: the coommunity
<tepsipakki> fabbione: there is no X maintainer at the moment?
<mjg59> Correct
<cjwatson> mantiena: I don't plan to make it selectable, but console-setup.config should be changed in sync with bug 38931, in which case it will happen automatically in ubiquity
<Ubugtu> Malone bug 38931 in Baltix "add lt keymap to NONLATINMAPS variable in xserver-xorg.config script" [Medium,Unconfirmed]  https://launchpad.net/bugs/38931
<cjwatson> tepsipakki: we're hiring. Suggestions or applications welcome
<kylem> i believe we're working on the YTIL principle for X...
<cjwatson> http://www.ubuntu.com/employment
<mjg59> kylem: YTIL?
<kylem> you touched it last
<mjg59> Ah
<tepsipakki> cjwatson: yeah, I've seen that..
<cjwatson> suggestions can be sent to me, as I'm the hiring manager
<tepsipakki> ..but I don't qualify :)
<cjwatson> (for the X position)
<tepsipakki> kylem: I noticed that you did an ati-driver upload which had some DRI-related fix. There are still issues which make it hang, but I can search upstream if there are fixes available
<tepsipakki> too bad that X.org 7.2 is still not released
<_ion> x-input-hotplug  (7.2 has it, doesn't it?)
<Keybuk> it does
<Keybuk> afaik
<Keybuk> (but I'm probably wrong :p)
<mantiena> cjwatson: btw, it's known, that with new ubiquity there are no possibility to resize existing partition ?
<mjg59> tepsipakki: To all practical intents and purposes, it is released
<cjwatson> mantiena: already fixed
<CyberSnooP> Hi. Herd 3 Desktop CD is not booting correctly. It hangs during init (rough guess) and continues only when I terminate some process. Is there some information I should supply you with?
<tepsipakki> Keybuk: it's in 7.3
<CyberSnooP> (or should I shut up an go idle in #ubuntu+1)
<tepsipakki> Keybuk: according to http://wiki.x.org/wiki/ChangesForX11R73
<mantiena> cjwatson: fix landed after herd-3  ?
<Keybuk> CyberSnooP: the process you had to kill would be a useful start
<cjwatson> mantiena: yes
<CyberSnooP> Keybuk: Well, I'll have to go set up IRC on another computer so I can chat here while trying things. Would you be willing to spend a few minutes on helping me giving you the right info?
<Keybuk> sure
<CyberSnooP> I'm not exactly sure what I'm doing, but I did use SysRq + e (tErm) after the booting stalled for a few minutes.
<tepsipakki> mjg59: ok, they seem to be tidying up or something
<mjg59> tepsipakki: The docs need to be released
<tepsipakki> mjg59: docs.. who needs them ;)
<mantiena> cjwatson: thans
<CyberSnooP> Keybuk: Okay. I'm rebooting with the herd 3 CD now
<CyberSnooP> Keybuk: It seems I'm getting a kernel Oops, which might be the cause of the trouble
<Keybuk> -> #ubuntu-kernel then :)
<Keybuk> those guys will help you
<CyberSnooP> Okay, thanks so far :)
<seb128> tfheen: could you have a look to software-properties (source NEW)? It looks fine to me out of some copyright glitches (debian/copyright has the mention of the GPL under "Copyright" and softwareproperties/gtk/SimpleGladeApp.py looks like LGPL but there is no mention of the LGPL to debian/copyright and the text is not shipped with the package)
<seb128> and I'm not supposed to do source NEW :p
<seb128> mvo_: ^
<tfheen> seb128: sure.
<seb128> mvo_: softwareproperties/gtk/SimpleGladeApp.py seems to be under LGPL which is not mentioned to copyright nor shipped with the package
<seb128> tfheen: thank you
<mvo_> seb128: right, that looks like a oversight, let me fix it
<mvo_> seb128: can I reupload with the same version nubmer and you just reject the older upload?
<seb128> tfheen: ^
<tfheen> seb128: sure that works.
<tfheen> seb128: you then either need to reject it before he uploads or reject by queue id
<seb128> ok
<seb128> no need to write some mail about the rejection in that case? ;)
<cjwatson> not so much ;)
<mvo> seb128: uploaded
<mvo> seb128: I don't think so 
<seb128> mvo: ok, previous one rejected
<mvo>  seb128: thanks
<seb128> np
<seb128> package looks fine to me now
<seb128> tfheen: mind checking and approving it if it's fine to you? ;)
<tfheen> seb128: sure, doing now
<seb128> thank you
<giskard> hello seaLne 
<giskard> seb128, 
<giskard> :)
<seb128> hi giskard
<seb128> I'm away for ~1h, bbl
<tfheen> mvo: the docs seem to be under the GFDL..
<elmo> that's fine for us
<tfheen> elmo: yes, I know, but I'd like a copy of the GFDL in the orig.tar.gz
<tfheen> mvo: if you could please add that to the .tar.gz, that'd be appreciated.
<mvo> tfheen: thanks, I do this now
<tfheen> mvo: is this a split-out from some other package in main or should it go to universe?
<mvo> tfheen: its a split up from update-manager, it should go to main 
<tfheen> mvo: ok, accepted
<mvo> tfheen: thanks!
<tfheen> mvo: hmm, I think an override of admin instead of gnome would be more appropriate, though
<mvo> tfheen: yes, that sounds good
<iwj> Ugh, this cryptsetup problem has turned into a right can of worms.
<tfheen> iwj: the one I pointed you at or something else?
<iwj> Yes.  It turns out that I had made a false assumption and life is more complicated than I previously thought.
<tfheen> ah. :-/
<iwj> cryptsetup is a counterexample to the assumption which is why it broke.
* tfheen uploads a new casper and hopes this works.
<iwj> tfheen, siretart, hile: I think I have fixed the problems with cryptsetup now.  Sorry about the delay.  I would be grateful if you'd give the new versions a test.  Would you like some under-the-table i386 builds ?
<iwj> cjwatson: I've fixed the dependency from libdevmapper to dmsetup too.
<iwj> cjwatson: Which I think will sort out the initramfs generation order bug.
<tfheen> iwj: sure, that'd work.
<cjwatson> iwj: thanks
<siretart> iwj: I'd appreciate it, but I'm not sure if I'll manage to test them today :(
<siretart> it seems it was a good idea to bring up the cryptsetup case :)
<siretart> is it already promoted to main?
<iwj> Aargh, I made a trivial edit it after my last test and now of course it's FTBFS.
<iwj> siretart: No, it's still unreviewed.
<iwj> Perhaps I should review it although I haven't done anything really to it ...
<siretart> iwj: feel free to commit it to bzr and push your branch to launchpad. I committed the current cryptsetup package ready for use with bzr-builddeb
<hile> iwj, yes i can test. my setup is LUKS-LVM-ROOT so it will test quite many of the parts
<iwj> tfheen, siretart, hile: http://www.chiark.greenend.org.uk/~ian/d/cryptsetup/
<iwj> NB _no_ new cryptsetup package.
<iwj> Only new udev and devmapper.
<bddebian> Heya
<siretart> iwj: this means the complete cryptsetup integration stays outside the cryptsetup package?
<iwj> I haven't touched the cryptsetup package at all and I don't really know anything about the integration you're talking about.  What do you mean ?
<iwj> The udev/devmapper/rendezvous thing is all done by libdevmapper underneath cryptsetup's feet.
<siretart> iwj: care to share your code as well? (only the orig.tar.gz is there, no diff.gz)
<siretart> iwj: I assumed that cryptsetup would need to ship some udev rules calling cryptsetup
<hile> my draft async cryptsetup stuff has /etc/udev/rules.d/68-cryptsetup.rules:
<hile> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="crypto_*", RUN+="cryptsetup_helper"
<hile> and cryptsetup_helper checks if given device is in configured file, i.e. should it do anything for it, asks for pasphrase etc
<hile> still writing that wrapper script ..
<hile> but, this might not work, since udev scripts shouldn't be interactive
<Keybuk> udev will kill the script if the passphrase isn't received relatively quickly
<hile> ugh ;)
<iwj> siretart: code> Sorry, wrong rsync rune.  Try now.  You probably want to fetch the .debs again too.
<hile> at least this rule must not be installed on live filesystem
<iwj> siretart: Yes, for proper asynch support, yes.
<iwj> I haven't done that.
<iwj> All I've done is fix the bug that made it not work properly.
<hile> hmm can we even do async cryptsetup if udev kills the passphrase prompt 
<hile> or script, whatever
<hile> so directly calling the cryptsetup command from udev rule is not answer
<hile> interactive stuff is funny anyway...
<iwj> hile: You have to fetch the passphrase in advance and stash it somewhere I think.
<siretart> iwj: how do you know whether a passphrase is needed at all?
<siretart> and what to do if it happens to be wrong?
<hile> iwj, passphrase is only one option
<siretart> the keyfile option is non-interactive and not an issue here, I'd say
<hile> mmmmm yeah
<hile> i guess the pgp script options are no problem either
<siretart> iff they are non-interactive
<hile> yep, and the key file may be coming from a usb device which is not yet initialized ;)
<hile> hi this sounds rather funny
<siretart> is there some way to 'delay' an udev helper script?
<Keybuk> delay?
<siretart> Keybuk said before the helper script will be killed if it doesn't come to results "relatively quickly"
<iwj> Oh, bugger, some strange thing is still not working.
<hile> what I was thinking that  there should be a passphrase agent which waits for certain events or devices to happen and then asks the passphrase or does whatever is to do
<iwj> The fact that someone who makes a block device can't wait for the udev script to finish is a complete PITA.
<siretart> Keybuk: wouldn't it be great if the helper script could say udev "I'm sorry, but I'm not able to complete your request. please call me again in 2 seks, kthnxbye"
<iwj> I've got yet another deadlock.
<Keybuk> siretart: no, that makes udev too complex
<siretart> isn't it complex enough so this wouldn't matter anymore?
<Keybuk> no, udev is quite simple
<siretart> hm.
<hile> of course, most cases for cryptsetup don't really need anything funny
<siretart> then udev would need to trigger some service, which fetches the key (maybe) interactively and prepares the device
<Keybuk> right
<siretart> Keybuk: didn't you tell before this would all work already? ;)
<Keybuk> no
<Keybuk> nobody has touched cryptsetup, so there is still work to make *that* worked
<hile> so how should the notification be done anyway? what options there are?
<siretart> dbus?
<iwj> *sigh* I'm going backwards.
<_ion> iwj: Nice work with the dpkg triggers spec, btw.
<iwj> _ion: Thanks.  I'm glad I've done something right :-).  I'm having a bit of a bad day today.
<_ion> Oh. :-(
<siretart> iwj: Keybuk: do you agree that I quote you from todays irc log regarding udev, libdevmapper, cryptsetup and friends?
<siretart> err, 'may I quote you', even...
<Keybuk> which bits do you want to quote?
<Nafallo> "damn I screwed up da last upload, sory maties, ARGH!" ;-)
<siretart> I'm feeling well today, won't do it today anyways.. :/
<siretart> I found the chat very intersting, and it should be written up
<siretart> wait, this is a publicly logged channel anyway, never mind
<Keybuk> heh
<iwj> siretart: Sure.
<_ion> A transcript of the relevant lines of the discussion still would be nice.
<siretart> _ion: that's what I had in mind
<bddebian> pitti, Keybuk, or whomever, could you please remove dvd95 from the NEW queue?  I need to upload a better version (same version) but fixed.
<pitti> bddebian, Keybuk: doing
<bddebian> pitti: Thx
<pitti> bddebian: done
<bddebian> pitti: BTW, what's the process for the binaries for libti* getting through now?
<bddebian> pitti: Rockin', thank you sir
<pitti> bddebian: they should get binary NEWed as part of the routine archive admin days; today's is seb128's ;)
<iwj> OMG I have completely broken everything.
<Nafallo> iwj: that doesn't sound good... :-)
* Nafallo holds of upgrade until iwj says he fixed it again :-)
<_ion> The laws of physics still seem to work here.
<iwj> Nafallo: You should be OK unless you're using devmapper, cryptsetup, lvm, mdadm, evms, ...
<iwj> ... or udev.
<Nafallo> lol
<iwj> (Actually, that bit about udev is a lie.  If you're just using udev you'll be ok.)
<_ion> :-)
<Nafallo> lvm and devmapper then :-)
<ogra> only in combination with hardware it breaks :P
<cjwatson> seb128: what's the state of desktop-slab? does it just need main promotion?
<cjwatson> (as per the spec)
<bddebian> Wow, seb128 is an archive admin now too? w00t
<cjwatson> seb128: have the package management commands been updated to use g-a-i?
<gnomefreak> pitti: are you busy? i have a question about an error on an apport-retrace
<pitti> gnomefreak: I am busy, but just ask
<gnomefreak> im getting an assertionerror
<gnomefreak> i will pastebin it
<gnomefreak> pitti: heres the errors http://paste.ubuntu-nl.org/4590/
<gnomefreak> i cant use apport-retrace -d so i dropped the -d. your repo doesnt have up-to-date edgy debug packages for firefox
<pitti> gnomefreak: right, I mailed infinity and elmo about generating dbgsyms for -updates/-security a while ago
<gnomefreak> ah ok
<seb128> cjwatson: I thanks for the reminder, it needs an update, that should be quick I'll do it now
<seb128> cjwatson: after the update just main promotion is required
<pitti> gnomefreak: this rings a bell
<pitti> gnomefreak: however, this doesn't look like current feisty (it has python 2.5 now)
<gnomefreak> pitti: its a feisty apport in an edgy chroot cause of the bug on edgys apport
<pitti> gnomefreak: can you please upgrade to the latest apport/python-apport/python-problem-report and try again?
<pitti> ah, I see
<pitti> gnomefreak: can you please open a bug with the exception and attach the report you wanted to retrace?
<gnomefreak> ok
<cjwatson> dholbach: what's the state of feisty-telepathy for FF?
<cjwatson> seb128: thanks
<dholbach> cjwatson: we'll have no 'main' bits for Feisty. I'll consider further updates and ask for UVF if necessary. It's in 'maintenance-mode'.
<cjwatson> dholbach: so essentially deferred?
<cjwatson> or done everything we can?
<cjwatson> I suppose the spec didn't promise anything in main
<cjwatson> dholbach: I guess the question is, how much of "Things feasible for Feisty release" actually happened?
<cjwatson> whether in main or not
<dholbach> cjwatson: we introduced and tried gossip-telepathy, brought in new modules and the spec said "consider gossip-telepathy in main with select  connection-managers"
<dholbach> so inclusion in main deferred
<dholbach> i'll add a blurb about the state of ICQ
<iwj> Right, that's the cruddy but actually-working udev-devmapper.
<iwj> Did anyone design udev I wonder ?
<cjwatson> dholbach: wilde doesn't appear to be there
<dholbach> cjwatson: yes, that's ICQ - I'm updating the spec right now.
<cjwatson> ok
<cjwatson> I'm really trying to figure out whether it's sensible to consider that spec as having been achieved for FF
<dholbach> cjwatson: I'm happy with it having the status 'deferred'.
<Keybuk> iwj: no, it evolved
<Keybuk> the early versions of udev weren't even daemons; it was a shell script, and later binary, run from hotplug
<Keybuk> it was only recent that udevd appeared
<Keybuk> and even more recent that it got the current rules file syntax
<iwj> tfheen: 2.5.6-7ubuntu2> `* Make sure to call udevsettle in the initramfs script so devices have a chance of appearing.'
<iwj> That clashed with my proper udev-based fix for mdadm.
<iwj> `* Provide udev rules for md devices, to run mdadm -As.'
<tfheen> iwj: sorry.  (It should be harmless though)
<iwj> If I understand your intent, I think my package is the right fix for that.  Shall I just bump my version number and drop your change ?
<Keybuk> tfheen: gnargh!  why did you add that?
<iwj> Yes, it's harmless I think.
* Keybuk deliberately *removed* udevsettle from the initramfs
<iwj> Keybuk: Presumably because it didn't work at all before.
<tfheen> Keybuk: because else it fell over when booting a feisty box with / on raid?
<tfheen> and, well, booting is kinda important.
<Keybuk> tfheen: the fix for that was what ian's been doing
<tfheen> Keybuk: yes, but it wasn't there yet.
<Keybuk> "development release"
<tfheen> so I'm happy for iwj's fix to take precedence.
<iwj> Keybuk: I think it's a fair enough workaround.  OK, I'll go ahead and supersede it.
<Keybuk> ok
<Keybuk> would have been nice to have had at least a ping about it though
<iwj> I just wanted to check I wasn't treading on any toes, obviously.
<Keybuk> since there's a deliberate changelog saying that it went away
<tfheen> yeah, I could have done that.
<jharr> is this the right channel for help with building .debs?
<cjwatson> #ubuntu-motu's probably better
<jharr> cjwatson: thx
<givre> ogra: i made two mistakes in the fuse merge : 1. the udev rules number were wrong (forget to lower it when i removed the run stuff). 2. we didn't check that the control fs is mounted before unmounting it.
<givre> ogra: i propose a correction : http://paste.ubuntu-nl.org/4594/
<givre> the source package is still available here : http://flomertens.keo.in/merge/
* _ion really, really wishes http://revu.tauware.de/details.py?upid=4133 (compiz-extra) would get to Universe before the freeze.
<cjwatson> heno: there's one remaining item from braille-support: "Make Orca and/or speakup do the right thing when braille has been configured."
<cjwatson> heno: do you know the status of that?
<heno> cjwatson: I'e checked; it does the right thing by default
<heno> which is always nice
<cjwatson> heno: then it's done bar the testing
<cjwatson> heno: the brltty work was a bit more complicated than I expected; feel free to have a look and comment once it hits the archive, of course
<cjwatson> I expect it's not final
<heno> cjwatson: Thanks a bunch for doing this! 
<cjwatson> you're welcome
<heno> yep, ok
<heno> cjwatson: unfortunately bug 80892 is causing some problems with USB testing, for one person at least
<Ubugtu> Malone bug 80892 in linux-source-2.6.20 "USB braille display no longer starts with brltty" [Medium,Confirmed]  https://launchpad.net/bugs/80892
<heno> my current guess is that it's a kernel problem
<cjwatson> heno: oh, I forgot to add the warning if you're configuring a serial device. Perhaps you could add that later
<heno> cjwatson: yep, will do
<cjwatson> BenC: could you (or one of your team) look into bug 80892 for Henrik, please?
<Ubugtu> Malone bug 80892 in linux-source-2.6.20 "USB braille display no longer starts with brltty" [Medium,Confirmed]  https://launchpad.net/bugs/80892
<BenC> cjwatson: Sure thing
<cjwatson> thanks
<BenC> heno: I'm 50/50 on whether this is a kernel problem or not...easiest way is to see if booting edgy kernel fixes it
<heno> BenC: ok, I'll ask him to do that
<BenC> heno: Added comments to bug report
<BenC> unloading ehci_hcd may be helpful too
<heno> ah, ok. cool
<cjwatson> BenC: have a minute to talk about ubiquity-driver-updates?
<cjwatson> I promised to run you through the bits of casper you'd need to touch
<BenC> cjwatson: Yeah
<cjwatson> BenC: so you'll need to create a script in scripts/casper-premount/
<cjwatson> that doesn't exist at the moment since there are no such scripts, but the hooks to run casper-premount are there
<cjwatson> use stuff in scripts/casper-bottom/ as a template - you'll need the prereqs boilerplate (though there won't actually be any prerequisites)
<bluefoxicy> ooOOOooooooooo
<bluefoxicy> "The main emphasis in this branch is support for the Active Directory logon protocols used by Windows 2000 and above."
<bluefoxicy> Can we use Samba as an Active Directory server/domain controller now?  :D
<BenC> cjwatson: at casper-bottom, the squashfs live rootfs is already mounted and ready?
<cjwatson> BenC: yes
<cjwatson> BenC: which is why this needs to be done before casper-bottom, otherwise you won't be able to eject the CD
<BenC> cjwatson: Don't we need to eject the CD for this, and will that affect the system at that point?
<cjwatson> BenC: casper-premount runs before the live fs is mounted
<BenC> cjwatson: Ah, mixed up bottom/premount while I was reading
<BenC> cjwatson: So I should be able to copy any drivers to a local tmpfs in a known directory, and add a casper-bottom script to put those into the filesystem?
<cjwatson> BenC: right, /dev/.initramfs is there
<BenC> Ok
<cjwatson> so you can use that
<cjwatson> BenC: you'll need '/sbin/usplash_write "INPUTENTER Insert a driver CD and press Enter"; read </dev/console' or something along those lines to do the prompting
<cjwatson> erm, or possibly </dev/.initramfs/usplash_outfifo per usplash_write(8)
<BenC> Easy enough then
<cjwatson> BenC: casper is maintained in bzr, so bzr checkout sftp://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/ and just commit stuff there
<BenC> cjwatson: Ok
<BenC> cjwatson: I'll have something done tonight, and email it to you for review
<cjwatson> thanks
<keescook> BenC: do you know is ASLR works on Sparc?
<keescook> s/is/if
<BenC> keescook: ASLR?
<keescook> BenC: address space layout randomization (for PIE executables)
<BenC> keescook: I don't know, but at a guess, no
<keescook> BenC: okay, I'll dig around.  thanks!
<cjwatson> BenC: I'd be inclined to keep copies in something like /root/var/lib/casper/drivers/
<cjwatson> then the ubiquity hook can install from theere
<cjwatson> there
<BenC> cjwatson: You writing the ubiquity hook?
<BenC> cjwatson: And should we support floppy when asking for a driver disk?
<zul> BenC: floppys are going away though..
<cjwatson> BenC: I can do the ubiquity hook; it'll be pretty trivial
<cjwatson> BenC: CDs are all I care about for now
<BenC> using floppies is sort of counter intuitive to supporting bleeding edge hw drivers
<cjwatson> BenC: you'll need a casper-bottom script as well to take care of running depmod if any drivers were found, of course
<cjwatson> and the linux-restricted-modules-common modification
<BenC> lrm mod?
<cjwatson> it's in the spec
<BenC> Ok, guess I need to reread that
<cjwatson> we need to run depmod twice in order to take account of various different possibilities - once before the live session's udev starts, and once after l-r-m modules are linked
<cjwatson> I can't remember all the details, TBH, but I know we went over it at the time :)
* cjwatson trusts his past self
<BenC> yeah, I think we discussed it in pretty great detail
<cjwatson> BenC: do you need help with the update-grub integration for l-k-c-d?
<cjwatson> I have 20 minutes now
<BenC> Nah, I can handle that no problem
<BenC> I did the kdump portions, so I got familiar with the code
<mdke> seb128: it depends on resolving bug 76944. I need to grab Don to finish that patch
<Ubugtu> Malone bug 76944 in yelp "Improve yelp index layout" [Undecided,Confirmed]  https://launchpad.net/bugs/76944
<seb128> mdke: feature freeze is now
<seb128> mdke: like it has to be done for tomorrow
<mdke> seb128: ok. 
<mdke> seb128: so, we should commit the patch on that bug I think, and remove the sub-menu
<seb128> mdke: will you have a first version of the patch uploadable for tomorrow? we can fix it later without problem
<mdke> seb128: if we need to tweak the patch later in minor respects, will that be ok?
<seb128> mdke: right
<seb128> yep
<mdke> cool
<mdke> :)
<seb128> no problem to fix bugs during some weeks then
<seb128> is the patch on the bug to upload then? or do you want to update it for tomorrow?
<mdke> seb128: the fourth patch ("Updated patch.") is ok to upload
<seb128> k, I'll do that
<seb128> and update when you have a patch update
<lamont> keescook: wondering if you (or anyone) ever uses the build logs under people.u.c/~lamont/buildLogs, or if I can nuke them....
<keescook> lamont: I didn't know about 'em, so nope.  :)
<mdke> seb128: thanks very much indeed
<seb128> mdke: np
<seb128> lamont: launchpad mail about build errors with an url for the launchpad build log nowadays I think you can drop the logs from your people page
<lamont> keescook: nuking
<lamont> if pitti/whoever needs them, the admin team can recover them.
<Lure> since Riddell is not around, what do we need to do to fix this build depend? networkstatus (install depends) and networkstatus-dev (build-dep) are in universe, even though that source (kdepim) is in main: https://launchpad.net/+builds/+build/298526
<Lure> this blocks implementation of KubuntuFeistyNetworking spec
<mdke> seb128: will you do the gnome-panel change too or do you need any more info from me? presumably it's just dropping an Ubuntu patch?
<seb128> mdke: the change is "replace submenu by yelp launcher", right?
<mdke> seb128: yes, it should probably be named "Help and Support" if possible
<seb128> mdke: that's possible, will do, thank you
<mdke> great, thanks again
<seb128> np
<tobias_> Any idea what might have broken X after the latest update?
<BenC> cjwatson, Keybuk: can someone process linux-backports-drivers-2.6.20 through NEW please?
<cjwatson> doing
<BenC> thanks
<cjwatson> BenC: please fix the incorrect Design section in the spec
<cjwatson> "The new package will be built very much like linux-restricted-modules. However, instead of a separate package for each kernel flavour, the single driver-backport package will contain drivers compiled for all flavours on a particular architecture."
<cjwatson> BenC: that's not how the package is laid out (and I prefer the actual layout you've uploaded anyway)
<BenC> cjwatson: Ok
<cjwatson> BenC: it would be kind of nice if there were one module in there to test with
<cjwatson> I thought that was the plan for ubiquity-driver-updates
<BenC> cjwatson: Yeah, I need to find a suitable test case
<tobias_> Any idea what might have broken X in the recent updates to feisty?
<cjwatson> BenC: processed through source NEW
<BenC> cjwatson: let the confusion begin
<BenC> I should upload the new linux-meta too
<tobias_> BenC: Will that fix madwifi, too?
<BenC> tobias_: No, the lrm in feisty fixes madwifi already
<BenC> confirmed by two people
<tobias_> BenC: Not here.
<cjwatson> BenC: I don't think linux-meta should depend on backports, honestly
<BenC> tobias_: Then you either have a different bug, or not using latest lrm
<tobias_> BenC: I have all the new updates and still no wifi.
<BenC> cjwatson: Really? I thought we needed a way to force it in there...rather than have people ask and always get the same answer
<tobias_> BenC: It is my bugreport:-) So the others might have a different bug;-)
<cjwatson> BenC: if linux-meta depends on backports, then the stable release updates policy for backports has to be just the same as for the regular kernel, because everyone will have it installed
<cjwatson> BenC: which would mean there's no point in having it
<cjwatson> BenC: we might as well just shove all the updates into the regular kernel packages
<BenC> cjwatson: I thought the idea was to keep from having to recompile the entire kernel for new pci's new modules
<cjwatson> BenC: if it doesn't depend on it, then yes, users will have to be told about it, but that's a fairly easy item for support
<cjwatson> BenC: no, it's to reduce risk of updating drivers
<BenC> cjwatson: Ok, then I still need linux-meta additions so they don't have to manually install it for ABI bumps
<cjwatson> sure, linux-backports-modules metapackages would be fine
<cjwatson> a la linux-restricted-modules
<Lure> cjwatson: one quick question: networkstatus-dev binary is in universe, but we now need it as build-dep of knetworkmanager (main) -> how do we get it in main (since source package kdepim is in main already)?
<tobias_> Any ideas what might have broken X?
<cjwatson> Lure: promoted for the next publisher run
<Lure> cjwatson: thanks!
<cjwatson> not sure if it will have made the one that's running now, so you might have to wait about an hour and a half if I just missed it
<Lure> cjwatson: no problem, I can wait couple of hours
<Lure> cjwatson: if we seed/depend on networkstatus in kubuntu-meta, it will get promoted to main too, right?
* tobias_ sighs.
<cjwatson> promoting binaries from source already in main is a "just ask" matter, or sometimes "just wait" if we're up to date with anastacia processing
<cjwatson> Lure: I already did that
<cjwatson> it was listed - I assume networkstatus-dev depends on it
<Lure> cjwatson: ok, great - will then ask Riddell to update meta packages
<slomo> BenC: ping? did pata_via disappear again in the latest kernel and will we get it back at one point or shall i switch everything from /dev/sd* to /dev/hd* again? :)
<BenC> slomo: pata_via isn't coming back
<BenC> you should be using UUID's instead of hardcoded dev's anyway, to avoid problems on future upgrades
<slomo> BenC: i do... except for the root parameter for the kernel cmdline... it's root=801 now for sd* and should be something else again for hd*... or does this also work with uuids?
<BenC> slomo: Why not use UUID for cmdline too?
<BenC> root=UUID=XXXXX works
<BenC> if you are using initramfs
<slomo> BenC: ok, thanks :)
<BenC> cjwatson: linux-meta uploaded with backports-modules meta packages (nothing depends on them)
<cjwatson> BenC: great, thanks
<tormod> Has anyone started to merge xorg 7.2 packages, if only unofficially? I started on the ati driver and libdrm but I'll be baked in dependency hell before long.
<jdub> ooh, circular dependency issues with udev/mdadm/initramfs-tools/volumeid
<tepsipakki> how come my /dev/null has mode 0600?
<tepsipakki> after a dist-upgrade
<tepsipakki> and the xsession dies right away
<ogra> iwj, where do you think https://wiki.ubuntu.com/MainInclusionReportCryptsetup oversells the package ? it uses the standard template we use for al packages, i would only note things that are differing from the standard template (cdbs etc) apart from that i wasnt aware that we need to list single items that are already linked
<ogra> iwj, following the procedure we used to use in the past as pitti asked for it (paste the package name into the cve and secunia search pages) i found no security issues and still dont find any ?
<ogra> iwj, if you expect detailed reports like you request in your comments, we should update the main inclusion policy
<_ion> ...And the number of update-initramfses run during this dist-upgrade: 5
* cjwatson has been doing a lot of stuff today involving the initramfs, as has iwj. Sorry about that.
<lifeless> mmm triggers
<_ion> No need to be sorry, it's a sign of progress. :-)
<_ion> At least until triggers are implemented.
<keescook> seb128: that was fast!  thanks for the sync.  :)
<lfittl> could somebody with the necessary rights clean libwiimote out of NEW, I need to re-upload (wrong debian/copyright, argh)
<ajmitch> keescook: ah, you see bug 46205 as well? I could never really reproduce it
<Ubugtu> Malone bug 46205 in f-spot "[amd64]  F-Spot does not correctly generate thumbnails when generating a web gallery" [Medium,Confirmed]  https://launchpad.net/bugs/46205
<seb128> keescook: np ;) (quick reply was a coincidence, I don't get bug mails, I just decided to do another batch of syncs now ;)
<keescook> ajmitch: yeah, I can't export anything
* ajmitch probably needs to setup a gallery install again
<ajmitch> any details on the console beyond what's in the bug?
<keescook> Nope, that was almost exactly what I saw too.
<ajmitch> hm, ok
<ajmitch> thanks anyway :)
<keescook> the garbage between the quotes for "bad option name" was different for me, but I really didn't think that was important.  :)
<ajmitch> what's the syntax for changelogs closing bugs now?
<tepsipakki> LP: #NUM ?
<Fujitsu> I believe tepsipakki to be correct.
<tepsipakki> ajmitch: ^^
<ajmitch> ah, found the wiki page
<ajmitch> you're right, thanks
<tepsipakki> np
<tepsipakki> ok, I've confirmed bug #83878 with two machines, surely someone else should see it as well?
<Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83878
<pinskian> E6600 a decent server?
<exobuzz> is there a diffinitive answer to the question "Will x.org 7.2 make it into feisty" ? and if there is, what is it ?
<exobuzz> :-)
<mdz> tepsipakki: I've never seen anything like that, no
<ogra> there was a udev upload today though
<exobuzz> perhaps i mean definitive. :)
<tepsipakki> mdz: ok.. I don't get it, though.. they were ok before the reboot
<ogra> tepsipakki, check /etc/udev/rules.d/40-permissions.rules
<ogra> there should be a line: KERNEL=="null",                          MODE="0666"
<tepsipakki> ogra: that looks normal, untouched even
<Chipzz> exobuzz: I think it would be a pretty good guess to say no
<ogra> tepsipakki, well, given udev does the right thing it should be right then ...
<Chipzz> exobuzz: 1) there is no official X maintainer, it's community maintained 2) we're more than halfway through the release cycle, may be too late to get such a big change in
<ogra> wel, it could go in if it would be uploaded *NOW* i guess :)
<ogra> tomorrow is feature freeze ...
<ajmitch> so close.
<exobuzz> Chipzz: ok.. so.. if I package it up real quickly :)
<ogra> exobuzz, and get a *lot* ov usertesting done as well
<ogra> *of
<tepsipakki> .. in a day :)
<ogra> a night ;)
<tepsipakki> even better
<exobuzz> Chipzz: its an important update though, and perhaps a special case could be made. One thing people say about ubuntu, is that too much is "spec'd" out compared to what gets into a final release (and also about bugs)..
<ogra> oh, and dont forget the proper upgrade path :)
<exobuzz> so i agree user testing is important
* tepsipakki rolls up his sleeves
<Chipzz> exobuzz: I'm not an ubuntu developer, so I have no say in it. but it would lack serious user testing, and has the potential to break really badly. so really, no
<Chipzz> exobuzz: X is not something "you just package"
<Chipzz> X traditionally has a lot of distro patches, which need thorough knowledge of things you probably don't even want to know about
<tepsipakki> if debian had those, a merge "might" be possible, but not in this timeframe
<cjwatson> there is a significant amount of pending merge work from Debian to be done
<exobuzz> having said that I am not an idiot either, and run linux on 4 architectures
<exobuzz> :)
<cjwatson> unfortunately, without somebody full-time on X, it's been difficult
<cjwatson> we merged (well, synced, mostly) all the client-side stuff
<cjwatson> which is a lot easier in most respects
<ogra> tepsipakki, thanks for the xscreensaver patch btw ... its something thats always dropping down my todo list in favor of something more important
<exobuzz> what happened to daniel stone ?
<cjwatson> he left Canonical some time ago
<tepsipakki> ogra: oh that one.. heh
<exobuzz> thats a big loss.
<exobuzz> :(
<tepsipakki> is he really doing upstream X.org stuff working for Nokia?
<cjwatson> he appears to be
<tepsipakki> maybe it's slightly related to Maemo..
<cjwatson> but I have no particular insider information
<cjwatson> it's public knowledge that he's been working on the N800
<tepsipakki> in theory, could the xorg-stuff be merged even post feature-freeze?
<cjwatson> upstream version freeze is the relevant date (although they happen to be the same)
<cjwatson> in theory, sure, in practice, we'd be pretty cautious
<tepsipakki> with Debian that is
<cjwatson> I think it would be carefully-targeted work rather than mass changes
<exobuzz> who wrote "/etc/bash_completion" - worst job ever ;-)
<tepsipakki> the drivers could be done one at a time?
<Burgwork> tepsipakki: specifically, he is doing input hotplug
<exobuzz> oh. credits in the comments of course.
<tepsipakki> Burgwork: ok, that makes sense then
<cjwatson> tepsipakki: though I'm not sure, I thought the driver ABI had changed
<tepsipakki> cjwatson: but if we stick with current upstreams and only merged with debian?
<Chipzz> exobuzz: heh. bash_completion is the best thing since sliced bread :P
<exobuzz> Chipzz: most of the time :)
<tepsipakki> with zsh you get also butter
<exobuzz> annoying when it tries to be too smart. so i type "less test.doc" - which is a plain text file, and it tries to pipe it thoguht something else ;-)
#ubuntu-devel 2007-02-08
<cjwatson> tepsipakki: I don't think that would be too interesting in most cases; the merges that actually matter (IMO) are the new upstreams, in this case
<cjwatson> exobuzz: that's not bash_completion, it's lesspipe
<Chipzz> tepsipakki: no, with zsh you get the whole bakery :P
<exobuzz> cjwatson: aah. ok.. good because ive hunting for where i can change this behaviour :-)
<Chipzz> ie >20MB mem usage *per instance*
<_ion> 5148..6472 KiB on my box
<_ion> Oh, that was virtual. Resident: 2480..3128
<exobuzz> cjwatson: ok thanks. now ive made my own filter override. im happy :)
<ogra> tepsipakki, xscreensaver uploaded, thanks again
<tepsipakki> ogra: no problem ;)
<exobuzz> oh daniel stone is on the x.org board of directors
<exobuzz> didnt realise that
* cjwatson works out why mouseemu is broken on his Intel Mac
<cjwatson> it can't deal with something that's both a keyboard-type device *and* a mouse-type device
<exobuzz> cjwatson: that's linux on your intel mac ?
<exobuzz> cjwatson: via bootcamp, or efi ?
<exobuzz> (elilo)
<cjwatson> bootcamp
<cjwatson> yes, Ubuntu
<exobuzz> one problem with bootcamp..
<exobuzz> unplug your monitor and try booting
<cjwatson> I'll believe you
<exobuzz> i configured my machine, posted it to the hosting company, and then they told me it wasnt booting.
<exobuzz> turns out: "It is important to test that your Mac Mini will boot correctly without a screen. In particular, if you rely on the Apple "Boot Camp" firmware update (which provides a legacy BIOS, so that the machine can be booted like a conventional PC), then you may encounter trouble with this, because the VGA BIOS which the machine installs typically blocks trying to communicate with the monitor using DDC."
<exobuzz> very annoying
<tepsipakki> hmm, I diff'ed xorg-server upstream tarball and our orig.tar.gz, and it was like 800kB :I
<exobuzz> in the end, i got them to switch it to efi/elilo.. actually the hosting guys have it netbooting, so if i make it unbootable they can netboot to a recovery kernel/disk which is handy
<tepsipakki> the same version
<exobuzz> tepsipakki: maybe its a big readme :)
<tepsipakki> if only
<cjwatson> unfortunately current versions of Linux can't drive the framebuffer properly if you boot via EFI
<cjwatson> so II'm told, anyway
<exobuzz> cjwatson: i had a framebuffer kenel patch. but would have though its in main kernel by now (this was 2.6.16 or something)
<cjwatson> I think it worked for a while and then broke
<exobuzz> oh :(
<cjwatson> although honestly, I haven't tried it personally; I've been focusing on making the bootcamp case work well, since we need that for CD booting anyway
<kylem> i suspect you need a modesetting intelfb driver.
<exobuzz> i have 2 mac minis as hosting machines. they are cheap to run, where power is at a premium!
<cjwatson> kylem: this is ATI r500, so that would surprise me
<cjwatson> the only option right now is vesafb, crap though that looks
<cjwatson> er, vesa
<exobuzz> cjwatson: you can boot cd from efi, if it has a bootloader on it
<cjwatson> exobuzz: not unless you can create an HFS+ filesystem from Linux
<cjwatson> exobuzz: if it's a normal ISO9660 CD, you need BIOS compatibility to boot it
<exobuzz> cjwatson: efi can also boot to fat32
<cjwatson> exobuzz: I don't think it'd be terribly sane to make our CD images dual FAT32/ISO9660 ...
<cjwatson> exobuzz: at least HFS (and HFS+, if anyone ever does it) you can overlay on ISO9660 with very little extra space requirements
<tepsipakki> ok, so diffing 1.1.0 and 1.1.1 isn't wise
<exobuzz> cjwatson: so, to create an hfs fs from linux you can use dd ;-)
<exobuzz> "heres one i made earlier"
<cjwatson> exobuzz: I'm talking about the official Ubuntu CD images here, which we need to be able to create automatically from scratch using only Linux
<slomo> is a MIR also needed for a new package if it only contains code that already is in one or more other source packages in main?
<cjwatson> I'm aware there are options available if you can do it by hand with Mac OS X to assist
<exobuzz> you cant keep a empty partition image handy for making it ? i mean its once off right ?
<cjwatson> exobuzz: no, of course it is not once off
<kylem> cjwatson, ah, loss. maximum loss.
<cjwatson> oh and I don't have root either
<cjwatson> (on the box used to produce the CD image)
<exobuzz> cjwatson: but a certain fixed size boot partition would be enough, and then you copy into it what you need ? what am i missing ?
<exobuzz> cjwatson: of course, im not sure how to bless a hfs+ f/s from linux either..
<cjwatson> exobuzz: the fact that the boot loader changes regularly? you can't write to HFS+ meaningfully without being able to mount it, which requires root
<exobuzz> there is that
<cjwatson> the userspace HFS+ utilities are read-only to all intents and purposes
<mjg59> HFS+ support is basically uninteresting while the kernel doesn't deal with EFI terribly well
<exobuzz> ok so.. use bootcamp, but you should include one tip for people who want to use their machines as servers without monitor: "If you need to use the "Boot Camp" firmware, you will need to prepare a simple terminator to convince the machine that a (non-DDC) monitor is attached. All that's needed is to connect a 75 resistor between pins 2 and 7 of the (analogue) VGA connector. The easiest way to do this is to buy a male DB15
<exobuzz> connector (a "VGA plug") and appropriate resistor, and solder it between pins 2 and 7 on the connector. Fit a hood over the connector to prevent damage in handling. (You can get all of these parts from Maplin or any other electronics supplier. We can sometimes supply these terminators but we don't keep a stock.)" courtesy of www.mythic-beasts.com
<mjg59> exobuzz: W?
<exobuzz> mjg59: without that, bootcamp doesnt boot without monitor..
<mjg59> Oh, sorry, got the context now
<mjg59> Yes, that's unfortunate. It's also a tiny proportion of the userbase.
<exobuzz> its a very useful tip.. 
<mjg59> exobuzz: FWIW, I did a lot of the Intel Mac support for mythic beasts
<exobuzz> but i was that tiny proportion at that point..
<exobuzz> mjg59: yeh think they mentioned you to me..
<exobuzz> mjg59: well i guess you are the person they mentioned anyway
<exobuzz> mjg59: i think iwas their first intel mac customer :)
<mjg59> Heh
<mjg59> I had their first Intel Mac
<tormod> tepsipakki: did you try to apply the old ubuntu diff to the new xorg tree?
<mjg59> But seriously, EFI interacts very badly with IA32 and x86_64 right now
<exobuzz> they sent it to you right ?
<mjg59> No, I happened to be in the right cafe at the right time
<exobuzz> mjg59: aah
<mjg59> They're friends of friends
<exobuzz> mjg59: how so ? about ia32 ?
<tepsipakki> tormod: no, I'm just trying to figure out why the tarballs differed, but I had a wrong one
<mjg59> 2.6.20 has only just got the calling convention for EFI right
<exobuzz> mjg59: you know any of the oxlug lot then ?
<exobuzz> im running 2.6.17 on intel mac.. what shouldnt work right ?
<mjg59> There's still a certain degree of misery between EFI's memory map and IA32
<exobuzz> via efi
<mjg59> 2.6.17 is actually ok
<mjg59> A certain amount of stuff breaks in 2.6.18
<mjg59> Should be fixed by 2.6.19
<mjg59> Anyway, I should have test hardware again by next week
<tepsipakki> tormod: now that I got xorg-server-1.1.1 the checksums match ;)
<mjg59> But a surprising amount of x86 Linux thinks that there's going to be a bios
<exobuzz> so long as chris lightfoot knows that. since im running one of his built kernels 
<exobuzz> :)
<tormod> tepsipakki: I guess I wanted to ask: have you tried (not did you try) :)
<mjg59> Yeah, Chris knows what he's doing
<tepsipakki> tormod: no, I haven't yet.. need to figure out what is the correct order
* kylem knows more than he wants to admit about efi on ia64, should get around to installing linux on my macbook one of these days...
<exobuzz> so.. you have a lovely intel mac notebook.. it runs macos.. it runs windows.. and linux.. but.. ati's linux drivers still suck :(
<exobuzz> shame
<Viper550> Random little question, why does Ubuntu ship with vim-tiny instead of vim?
<kylem> which is why you don't buy one with ati graphics...
<LaserJock> Viper550: because it's tiny? :-)
<Viper550> lawl
<exobuzz> kylem: i had no idea about ati graphics until this pc, i had nvidia on my last laptop. iguess i assumed they would be as good as nvidia.. silly me...
<Viper550> we're having a little discussion about text editors in -offtopic if you wanna join us
<mjg59> exobuzz: ATI's drivers still needed legacy bios support, last time I checked
<exobuzz> mjg59: yeh.. no ati with efi.
<exobuzz> :)
<tormod> tepsipakki: I am trying to merge/build the newest ati driver. I would be very interested if you get the xorg-xserver done.
<elmo> they also suck, even with legacy BIOS
<exobuzz> so with this not booting due to checking for monitor ddc.. do you think the old trick for infiniate lives on that c64 game would work. the one where you lick your finger and run it over the joystick port.. wrong sex on the video output though. unless you got it really moist.
<exobuzz> :)
<exobuzz> tormod: the newest x.org ati driver ?
<tepsipakki> tormod: 6.6.3?
<tormod> exobuzz: yes, 6.6.3 ++ git
<exobuzz> tormod: ooh ;-) great
<tepsipakki> tormod: that would be great, I've had problems with it + DRI
<tepsipakki> seems that not that many xorg libraries have been updated
<tormod> exobuzz: don't hold your breath :) needs a newer xserver-xorg also
<cjwatson> we synced all the X libraries from Debian
<tepsipakki> tormod: really?
<cjwatson> except for libx11, which we merged
<tepsipakki> cjwatson: thank goodness for modular xorg :)
<tepsipakki> tormod: oh you mean the git-stuff?
<tormod> tepsipakki: I am not sure. Do you think I can run 6.6.3 on the old xorg-server?
<tepsipakki> tormod: well, debian has 6.6.3
<tepsipakki> see merges.ubuntu.com
<tormod> tepsipakki: I think I tried to install the debian 6.6.3
<tormod> but there are many important fixes post 6.6.3
<tormod> s/important/interesting
<exobuzz> would this newer version solve the aiglx+compiz "GLX_EXT_ texture_ from_pixmap" missing problem ?
<tepsipakki> yeah
<tepsipakki> exobuzz: you've seen that too?
<exobuzz> sure.. i cant run aiglx+compiz.
<mjg59> Works fine here.
<tepsipakki> me neither
<mjg59> Well, has other bugs
<exobuzz> maybe its owner certain cards
<tormod> the debian 6.6.3 complains: xserver-xorg-dev (>= 2:1.1.1)
<mjg59> But that one isn't one of htem
<exobuzz> i have x700
<tormod> exobuzz: I also have x700. my main target is bug #22985
<Ubugtu> Malone bug 22985 in xserver-xorg-video-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005 | card detected, but driver fails to use right output port" [High,Confirmed]  https://launchpad.net/bugs/22985
<tepsipakki> mjg59: with ati? I have a 8500 and it fails
<mjg59> tepsipakki: No, i855. But this is all server side, so should be consistent.
<mjg59> There was an upload yesterday. have you tested it?
<tepsipakki> mjg59: oh, ok
<sfllaw> ogra: Ping?
<tepsipakki> mjg59: didn't have a chance, since my desktop is b0rked now :)
<exobuzz> mjg59: oh that bug.. ive put up with that for ages. i just stick in the "MonitorLayout" bit.
<exobuzz> mjg59: i thought it would never get fixed :)
<exobuzz> sorry. i mean tormod. not mjg59 
<exobuzz> i unfortunately bought an acer laptop too
<tormod> exobuzz: I am not sure it ever will be :) But it is such a bad bug - newbie blocker deluxe
<exobuzz> looks nice.. but essentially broken.. there is another nice bug, that if you press the lid button, you get about 10 acpi lid events per second, which fills the acpid logs
<exobuzz> tormod: yes.. very hard with a black screen to do much
<tormod> oh debian6.6.3 built fine once I removed the epic 2: from debian/control
<tepsipakki> funny, the xorg mirrors have a hierarchy for 7.2, but not the main site
<tepsipakki> have to get those from individual/*
<exobuzz> tormod: i suppose installer could detect acer laptop, and ati card and add a MonitorLayout line to fix it if the bug is not fixed ?
<tormod> exobuzz: I added that patch to the bug report ages ago (!)
<exobuzz> tormod: and its included now ?
<cjwatson> exobuzz: (for the record, the installer has nothing to do with that stuff; it's all in the xserver-xorg maintainer scripts)
<tormod> exobuzz: no it's not. it's not important enough / patch is not elegant enough ?
<exobuzz> cjwatson: yeh .. i was being generic. i dont know which x.org package makes the initial config :-)
<tormod> it's in dexconf it can be done most easily
<exobuzz> tormod: elegant? well. its important.. that should be enough
<cjwatson> exobuzz: I care because I'm responsible for the installer but not for X configuration :-)
<exobuzz> cjwatson: ok.. "listen up.  - its nothing to do with cjwatson." ;-)
<tepsipakki> erm, for instance upstream libice would unpack to libICE-ver, but it should be changed so that the tarball md5sum is preserved.. how?-)
<exobuzz> cjwatson: if it was down to you, i know it would already be fixed :D
<cjwatson> oh, I wish
<cjwatson> tepsipakki: the location the upstream tarball unpacks to hasn't mattered since some incomprehensibly ancient version of dpkg-source
<exobuzz> tormod: i know this happens on all ferarri and travelmates with ati cards though right ? so we just use like dmidecode and check?
<tepsipakki> cjwatson: oh..
<exobuzz> tormod: i mean in addition to the gfx card check
<mjg59> Gah, has that still not been fixed?
<tormod> exobuzz: checking for that exact card should be enough. fixes 90% I guess, maybe breaks 3%, ok wild guessing.
<exobuzz> tormod: the few that already work, are not harmed as they can go and edit their x.org and remove it, if they are sure.. but its harder to edit with a blank screen, so i agree it should go in.
<mjg59> It's not a chipset thing
<mjg59> It's very much an Acer thing
<exobuzz> well i always hear the word acer with this problem
<tormod> actually a few laptops with that card don't need the MonitorLayout line, but I guess they survive with it as well.
<tormod> mjg59, interesting. is it just the bios?
<exobuzz> my monitorlayout is "Option      "MonitorLayout" "LVDS,NONE""
<mjg59> It's really something that should be fixed in the driver
<tormod> mjg59, sure but until then? 4+ ubuntu releases useless for a lot of users?
<mjg59> tormod: And the potential to break it for a load of others?
<exobuzz> mjg59: cant we then fix it specifically for the laptops we know are broken ?
<mjg59> Get me an affected laptop and I can try to fix it properly
<mjg59> It's hard to debug remotely
<mjg59> And I'm not enthusiastic about adding hacks for individual machines without an understanding of /why/ that's an issue
<exobuzz> mjg59: where abouts do you live ?
<tormod> mjg59, are there a load of others? of course I only hear about those who are already broken :)
<mjg59> exobuzz: Xambridge
<mjg59> tormod: There's plenty of X700 machines
<tepsipakki> libice done :)
<mjg59> exobuzz: Uh, Cambridge
<exobuzz> mjg59: HAH.. cambridge. pah!
* exobuzz from Oxford!
<tormod> mjg59, I can give you ssh access if that would help.
<ogra> sfllaw, pong (in a hurry)
<mjg59> tormod: Possibly, but not necessarily all that much
<exobuzz> mjg59: ok admitting its a hack, is it so bad to have a hack which only affects the few and fixes the problem, that have it broken for feisty ?
<mjg59> exobuzz: It really depends on whether it hits other people as well
<tormod> mjg59, I can set up a webcam on another computer, so you can see if there's light on the screen or not :)
<mjg59> exobuzz: And whether there's a realistic chance of us managing to implement the hack in a correct manner without having test hardware
<mjg59> It's really hard to get this right
<exobuzz> mjg59: well at least fixing for some would be something. i have to adfmit, ive only seen it mentioned with acer laptops
<mjg59> exobuzz: Right, from everything I've seen it's specific to Acers
<tormod> the bug reports mentions Samsung
<exobuzz> so lets fix the acers, and see if anyone else reports it ? ;-) the samsung bug is not related i think...
<exobuzz> looks like they had a bad x config
<exobuzz> on acer, X starts. only backlight is not switched on
<exobuzz> if you look carefully you can see x running
<exobuzz> almost :)
<tormod> and presario 2100, hp compaq 9010, HP nw8240, Toshiba Satellite M70
<exobuzz> really ?
<exobuzz> shit.
<tormod> exobuzz: I don't think so, I think the screen is totally off.
<mjg59> nw8240 is an entirely different issue
<exobuzz> tormod: on mine i can see it.. you have to look real hard..
<tormod> nw8240 black screen, MonitorLayout fixes it.
<tormod> yeah sorry that one started to work in Edgy
<mjg59> tormod: Uh. All the information I had on nw8240 was that the screen was heavily corrupted, but visible.
<tormod> well to help fix it properly I need to run latest git, and then I would need xorg 7.2 I guess
<exobuzz> so maybe then we should do all x700 mobility.. monitorlayhout on a mobility card isnt going to break anything, as ive never seen a laptop that doesnt have its own screen
<exobuzz> :-)
<tormod> tepsipakki: you are not going to sleep before you have them all (xorg) done right? :)
<math_b> Hi, I am typing this on a Toshiba Satellite M70, what bug are you talking about ?
<tepsipakki> tormod: of course not
<tepsipakki> it's just 02:30 here
<tepsipakki> ha, debian had libx11 in experimental
<tormod> tepsipakki: that's the spirit! kippis for that.
<tepsipakki> I wonder how and where to put these for testing, _if_ I ever manage to get them ready
<exobuzz> speaking about laptops: i want my wireless keys switched on.. https://launchpad.net/ubuntu/+source/hotkey-setup/+bug/57849
<Ubugtu> Malone bug 57849 in hotkey-setup "Add keycodes for wireless button on Acer Travelmate 8100" [Low,Needs info]  
<exobuzz> i added info... and patch...
<exobuzz> actually 3 patches as i got it wrong twice. i was having a bad qa and testing day :)
<tormod> tepsipakki, bit torrent :)
<tepsipakki> nah, has to be apt-gettable
<tepsipakki> time to worry about it tomorrow
<exobuzz> tepsipakki: you dont have some person webspace to upload them ?
<tepsipakki> I have yes
<tepsipakki> don't know if the quota is sufficient
<exobuzz> just go "its done" send them to someone here and they will go online somewhere ;-)
<tepsipakki> heh
<tormod> the debian ati 6.6.3 depends on xorg-server 1.1.1-1, I just have 1.1.1-0ubuntu12 but I'll try. wish me luck :)
<tepsipakki> so it would need a merge
<tepsipakki> or just relax the deps
<tepsipakki> (don't know if that is generally a good idea, though)
<tormod> ati 6.6.3 seems to work QED
<tepsipakki> nice
<tormod> now I'd like to merge any ubuntu patches left and a few git commits
<tepsipakki> phew, libx11 done
<tepsipakki> had to merge 1.0.3-4ubuntu1 and 1.1-2 with 1.1.1
<tepsipakki> hmm, need to include 1.0.3-5 as well
<tormod> if anyone wants to test, ati 6.6.3 i386 packages here: http://tormod.webhop.org/linux/ati/ 
<exobuzz> ooh.
<exobuzz> thakns
<tepsipakki> too bad that xorg upstream has outdated Changelogs on many libraries
<Burgwork> http://www.flickr.com/photos/christopherblizzard/377591178/ <-- they need LP to schedule for them
<elmo> haha
<elmo> that's how we did specifications at UDU
<kylem> hehe
<ajmitch> how appropriate, I'm just listening to 'the wall'
<jdub> Burgwork: an unconference is quite different to specification fascification
<Keybuk> elmo: Fedora like things that worked for Ubuntu
<Keybuk> http://www.flickr.com/photos/christopherblizzard/378569571/
<kylem> they also appear to like being tossers...
<pkl_> kylem: still up...
<Keybuk> yeah, it's not as if we'd have anything like "Better Fedora than Fedora" in our original governance plans, or anything
* lifeless chesires
<kylem> better fedora than fedora is pretty easy. it's called "delete yum and fire author into the sun"
<kylem> worst. package. management. ever.
<Keybuk> oh, I dunno, apt/dpkg are pretty bad
<lifeless> 'bsd ports'
<lifeless> 'gentoo'
<kylem> Keybuk, it doesn't take 4 hours to upgrade a single package on a slow machine with apt.
<lifeless> Keybuk: yum is special. 
<Keybuk> ok, that's fair
<lifeless> with a th
<lifeless> and a capital S
<pkl_> I've never had yum take 4 hours. 
<kylem> i'm exaggerating, but not by much.
<lifeless> I've had it take 4 hours
<lifeless> embedded machine
<pkl_> but you're asking for trouble using yum on an embedded machine.
<kylem> i think this was a p 166mhz with 64M of ram or something.
<pkl_> I've never used any package manager on an embedded machine.  They tend to have a specially constructed rootfs and that's it :-)
<LaserJock> I've had yum completely not work (on FC1) which then lead my boss to by a mac :/
<jdub> kylem: pot/kettle?
<kylem> jdub, what?
<jdub> Keybuk: more^Wbetter fedora than fedora ;)
<jdub> i think firing people into the sun might count as "tosser" (in more ways than one)
<pkl_> hey kyle isn't tossers a bit strong.  I think Fedora isn't a bad distribution, it's noticably improved in the last few years.  But, I hate playing politics.
<kylem> feh.
<kylem> it's pretty mild considering the filth that comes out of my mouth typically.
<pkl_> kylem: heh, I believe you.
<zul> kylem: thats an understatement :)
<tepsipakki> xorg 7.2 libs updated.. all 27 of them, except libxscrnsaver which is a new one (don't know if it is needed)
<tepsipakki> time for bed ->
<infinity> Keybuk: Next rebuild happens right after feature freeze.
<Keybuk> infinity: my INBOX was filling up with faileds :p
<Keybuk> so I wondered
<sladen> ooh, that was fun.  time for bed
<pitti> Good morning
<Hobbsee> heya pitti!
<pitti> hey Hobbsee!
<Hobbsee> :)
<tormod> tepsipakki: (still up?) found a place for your packages?
<ajmitch> morning pitti :)
<tepsipakki> tormod: I did sleep for a few hours ;)
<tepsipakki> now doing app/*
<pitti> hey ajmitch 
<dholbach> good morning
<bluefoxicy> hi2u
<tepsipakki> do ubuntu-devs have webspace in people.u.c?
<dholbach> tepsipakki: only canonical employees
<Hobbsee> tepsipakki: no, only canonical employees..
<Hobbsee> gah.
<tepsipakki> dholbach: ok
<Hobbsee> tepsipakki: looking for webspace?
<tepsipakki> hobbsee: yes.. doing xorg-7.2
<tepsipakki> I do have some, but quota is only 100MB and it's full
<tepsipakki> and I could put them on my own server, but uplink is only 0.5Mb/s :)
<Hobbsee> tepsipakki: i'd ask imbrandon or TheMuso.  TheMuso might actually be around.
<dholbach> tepsipakki: if it helps, you could store stuff in bzr on LP
<Hobbsee> tepsipakki: as a general guide, any ubuntu person who has dreamhost hosting is probably a good bet :P
<tepsipakki> alright, I'll see what to do when I'm ready
<tepsipakki> it all depends if it builds :)
<dholbach> tepsipakki: *crossing fingers*
<tepsipakki> heh
<pitti> dholbach: anything I can NEW for you for bughelper? :)
<dholbach> I'd notify ubuntu-devel@ and ask for people to help out with
<dholbach> pitti: :-D
<tepsipakki> dholbach: ok, maybe it's time to do that
<dholbach> pitti: it's in source NEW
<dholbach> tepsipakki: then I'd definitely store stuff in bzr on LP
<tepsipakki> dholbach: is there a HOWTO for a bzr-illiterate?
<dholbach> https://wiki.ubuntu.com/BzrMaintainerHowto
<dholbach> https://wiki.ubuntu.com/Bzr
<dholbach> http://bazaar-vcs.org/Documentation
<tepsipakki> ok, thanks!
<Treenaks> c
<hunger> Any estimation on when feisty will be fixed again? udev is completly borked here.
<tepsipakki> hunger: run udev restart
<hunger> tepsipakki: I did... which is why I am finally logged in:-)
<tepsipakki> heh
<tepsipakki> I'm sure it will be fixed soon
<hunger> tepsipakki: I hope so, too...
* hunger hopes that pam_mount will get fixed some time soon, too. I still can not get to most of my data:-(
<tfheen> hunger: just mount it byhand?
<hunger> tfheen: pam_mount keeps unmounting it, so it is really annoying... and I keep forgetting how to actually decrypt the key in the first place.
<tfheen> cryptsetup luksOpen /dev/whatever blah ; sudo mount /dev/mapper/blah /home (or something like that), then don't log out.
<tfheen> pam_mount doesn't unmount it unless you don't have any sessions running
<Lure> tepsipakki: if you need free webspace and understand a bit of german: http://www.funpic.de
<hunger> tfheen: The problem is the openssl command to decrypt the key with:-(
<Treenaks> hunger: openssl x509 -in file.key -out file.key ?
<hunger> tfheen: openssl enc -d -some-algorithm-I-keep-forgetting -in file -out file.out.
<tfheen> hunger: that's what you get for having keys derived from file rather than from a passphrase, I guess.
<hunger> Anyway: It is really annoying... especially as pam_mount keeps unmounting the whole thing all the time.
<hunger> tfheen: Yeap... being paranoid is inconvinient at times;-)
<Treenaks> hunger: but are you paranoid _enough_? :P
<tfheen> hunger: why would a file on disk be more secure than something derived from a passphrase?
<hunger> tfheen: Because a passphrase is shorter than a file on disk (and less random, too).
<mdke> ajmitch: what's the "disabling scrollkeeper usage in debian/rules" in the latest f-spot upload? is it something to do with the manual?
<hunger> tfheen: If you got a short passphrase, then you can turn hash that all you want, it is still a weak key.
<seb128> morning
<mdke> morning seb128 
<seb128> weird, libx86 to /usr/lib totally broke my feisty desktop
<seb128> no mouse
<seb128> GNOME not starting and freezing the box completly
<ajmitch> mdke: yeah, I was under the impression that it wasn't to be used - though I'll correct it if wrong
<seb128> ajmitch: what?
<hunger> seb128: Try restarting udev... helped here.
<ajmitch> seb128: I wonder if that's the cause of some of the udev issues
<ajmitch> seb128: I was talking to mdke about f-spot :)
<seb128> ah ok
<mdke> ajmitch: does the manual still work without it?
<hunger> seb128: But the move is a bad idea... I get lots of warnings due to missing libx86 during bootup.
<seb128> hunger: I copied libx86.so.1 to /lib, which fixed everything, I fail to understand why at the moment though
<seb128> that's a new lib and is supposed to be used by usplash
<hunger> seb128: /usr is not around when usplash is running... so storing it there is not a good idea.
<seb128> it should not break the mouse and make the box freeze
<hunger> seb128: That is udev I guess...
<seb128> hunger: that I know, I still fail to understand why it's breaking the system
<ajmitch> mdke: afaict it does
<seb128> hunger: it should break usplash only
<TheMuso> dholbach: The libgnome-speech3 binary does not need to depend on the espeak package. It depends on libespeak1, which is fine, but it doesn't use the espeak command at all.
<tfheen> hunger: English has about 1.3 bits of randomness per letter, sha1 gives you a 128 bit hash, so a 98-letter passphrase will give the maximum security you can get using that hash.
<hunger> seb128: Had that yesterday... all went fine after restarting udev.
<seb128> hunger: you already said that ;)
<tfheen> hunger: and it's trivial to have a passphrase with a higher randomness than english.
* pitti hugs seb128 for finishing bug-reporting-tool
<dholbach> TheMuso: ok, I'll change that - heno instructed me to do so
* seb128 hugs pitti
<hunger> tfheen: Yeap... but who has a 98letter password (== passphrase in pam_mount)?
<seb128> pitti: blocking the spec "implemented" for a menu item was slightly too much no?
<TheMuso> dholbach: Right. All you needed was libespeak-dev, which you did.
<mdke> ajmitch: ok, i'll give it a check later
<seb128> pitti: I mean that's a trivial bug fixing
<TheMuso> I confirmed that the /usr/bin/espeak command is not used by renaming it.
<seb128> anyway, fixed
<TheMuso> The gnome-speech driver interfaces directly with the shlib.
<pitti> seb128: well, it was a missing thing from the spec *shrug*, but itz done now anyway
<dholbach> TheMuso: done
<tfheen> hunger: read again what I wrote.  You could have a passphrase where you replaced chars which would give you a fairly big boost.
<tormod> tepsipakki: will you post to a ML once you have some packages out?
<seb128> pitti: it'll likely change again, I don't like the 4 items in a row, we probably need a seperator or a different order or something
<tepsipakki> tormod: I just sent to ubuntu-devel, but that's just a heads-up post
<pitti> seb128: that's fine, now that everything is there in principle
<TheMuso> dholbach: Ok.
* dholbach hugs TheMuso
<tfheen> hunger: and if you have this on a file, it's still no more secure than how you keep that file.. and even if it's encrypted you still have a passphrase for it, so you can't strengthen your chain that way, only weaken it.
<hunger> tfheen: how so? Even with a totally random password you can not expect more than 4bits of entroy per letter... so a 8char long password is 64bit of entropy.
<hunger> tfheen: my HDDs passphrase is *LONG*, that is not the week point:
<seb128> mjg59: https://launchpad.net/ubuntu/+source/libx86/+bug/83920
<Ubugtu> Malone bug 83920 in libx86 "[feisty]  libx86.so.1 moved to /usr/lib -- and completely hosed my system" [Undecided,Unconfirmed]  
<tfheen> hunger: if it's utterly random, with all printable chars you get way more than four bits per letter.
<tfheen> six or seven bits, I suspect.
<seb128> cjwatson: https://launchpad.net/ubuntu/+source/libx86/+bug/83920
<seb128> that happens on my desktop as well, if you need any debug info let me know
<hunger> tfheen: Nope... you can not enter all ascii chars in a password dialog.
<hunger> tfheen: If you have 64 different chars you can use then you are lucky:-)
<tfheen> hunger: upper and lower case A-Z gets you 52, numbers another 10, You'd easily find ten to twenty different punctation chars.
<tfheen> which takes you into "6-7 bits per letter" land.
<hunger> tfheen: Nope... in the 4-5 bits per letter land. With 4 being the safe bet;-)
<tfheen> hunger: how on earth are you counting randomness?
<pitti> tfheen: it's just that passphrases whose characters are really independent from each other are terribly hard to remember :) usually they will depend on each other (probability-wise)
<hunger> pitti: Yeap... so 4bits of entropy is actually pretty much the upper limit... 3bits or maybe only 2 is a way safer bet.
<tfheen> pitti: yes, that's obvious.
<pitti> tfheen: so that drastically reduces entropy then
<mdke> what is the status on the binary drivers spec? is it happening for feisty?
<pitti> mdke: not by default, since we won't do compiz by default
<mdke> pitti: and is it going to be made easier to install? We need to know for updating documentation
<hunger> tfheen: Anyway... I do not expect more than max. 32bits of entropy from a standard unix password and that is a pretty optimistic guess already.
<kwwii> anyone here have an amd-64 box that can verify something about the usplash for me?
<tfheen> hunger: you're throwing numbers out without any reasoning for them.
<hunger> tfheen: I prefer using those 32bits as an additional line of defense for my keys than having it as the only one:-)
<tfheen> kwwii: sure.
<kwwii> tfheen: does it show a progress bar?
<kwwii> and if yes, is it a solid color?
<tfheen> kwwii: let me reboot to take a look
<mdke> pitti: it's confusing because the accelerated-x spec is marked as "Accepted for feisty"
<kwwii> tfheen: thanks a lot, I wouldn't ask if it wasn't important ;-)
<pitti> mdke: it was after the UDS, but then we didn't know how bad compiz actually was :)
<mdke> pitti: so the spec is out of date?
* seb128 slaps pitti
<pitti> mdke: it's not, we just defered its implementation
<seb128> pitti: compiz is not that bad, composite doesn't work fine everywhere though
<mdke> right, so it's out of date
<pitti> mdke: the 'for feisty' bit is out of date, 'approved' isn't
<mdke> yes, that's what I'm getting at
<mdke> ok, so is the method for installing binary drivers going to be the same as it was for Edgy?
<seb128> (gdb) bt
<seb128> #0  0x08077eba in panel_make_unique_desktop_uri ()
<seb128> Cannot access memory at address 0xbfe98e7c
<seb128> grrrr
<seb128> I want a working dup for that crash :/
<seb128> that's 
<pitti> seb128: BenC has (hopefully) fixed this locally
<seb128> that's 3 crash dumps we get now and no one is useful
<seb128> pitti: ah, good
<pitti> this was a terrible timing, the new kernel went straight to herd-3 without prior testing :/
<seb128> yeah
<tfheen> herd 3 has been out for close to a week now, there's nothing stopping BenC from doing a new kernel upload, though
<pitti> tfheen: right, sorry, that wasn't intended to be a blame
<pitti> seb128: at the same time the new kernel will raise the core dump limit from 1 MB to 1 GB (as initially intended)
<seb128> the limit is 1M atm?
<pitti> yes, a bug
<dholbach> hey mvo
<mvo> hey dholbach! good morning glatzor
<mdke> pitti: any idea?
<tfheen> kwwii: it's nice-looking, but on shutdown it was solid, yes.
<ajmitch> hi mvo 
<pitti> mdke: I think so, unless cjwatson added something to the installer
<tfheen> kwwii: as in, it was nice-looking on bootup again.
<mdke> pitti: ok. I will mail the list to find out I guess
<mvo> hey ajmitch!
<glatzor> morning mvo!
<glatzor> morning dholbach
<glatzor> mvo: I improved the arch-build replacing the tar pipe by a bzr lightweight checkout 
<mvo> glatzor: I tried that before and for me it was a step backward. it did not include not-yet-commited changes
<dholbach> heya glatzor
<dholbach> glatzor: how about getting python-distutils-extras into main?
<mvo> glatzor: one of my main use-cases for arch-build is to test-build stuff
<glatzor> mvo: ok
<cjwatson> seb128: thanks, will fix
<mvo> glatzor: and if I would have to commit everything before, that would be a bit anyoing :)
<seb128> cjwatson: np, thank you
<glatzor> does bzr inventory cover newly added and not yet comitted files?
<mvo> glatzor: yes 
<mvo> both
<glatzor> mvo: I use arch-build to verify the consistency of the repo before pushing.
<cjwatson> mjg59: hope you don't mind another libx86 NMU
<sabdfl> hey guys, i have a question about the new dhclient.conf in feisty
<sabdfl> it has a line like this:
<sabdfl> send host-name "<hostname>";
<sabdfl> is the <hostname> bit a "special value" which will be replaced with the results of `hostname`?
<sabdfl> or is it just an example? in other words, should i leave my current config of 'send host-name "foo";' or switch to the new <hostname>?
<tfheen> sabdfl: from my DHCP logs, it seems like it replaced it.
<pitti> sabdfl: it's now a magic value
<sabdfl> by "replaced" you mean that is s/<hostname>/`hostname`/? super, thanks tfheen
<pitti> sabdfl: right
<sabdfl> and thanks pitti!
<pitti> sabdfl: that was a long-standing wishlist bug and seemed to have annoyed lots of people, so I threw that in right in time for FF :)
<pitti> sabdfl: if 'foo' is the correct hostname on that system, either works
<sabdfl> nice!
<sabdfl> i've resolved conflicts on that file tons of times
<cjwatson> pitti: thanks a lot for flush-syncs, BTW
<sabdfl> now i can just go with the default behaviour
<cjwatson> I created flush-backports along the same lines
<pitti> cjwatson: nice
<cjwatson> pitti: I meant to ask, any reason to use cp+rm rather than just mv?
<cjwatson> the syncs and backports directories are group-writable so mv should work
<pitti> cjwatson: just transactional behaviour, if anything went wrong, the set +e would have prevented the rm
<cjwatson> true, fair enough
<pitti> cjwatson: but I guess mv would do the same
* tfheen grumbles at something breaking X today.
<cjwatson> pitti: so, does mouseemu make you scream in terror for main? :)
<pitti> cjwatson: I didn't look at it yet :)
* \sh grumbles at not knowing if HP P800 Controller does work with 64bit lba and large partitions on linux...
<pitti> cjwatson: the good ol' sysctl doesn't work any more for macbooks, I figure?
<cjwatson> correct, it's powerpc only and a good deal of work to make anything else
<cjwatson> given that there's a userspace solution, I prefer that
<tfheen> cjwatson: so, your usplash upload broke X for me.
<cjwatson> tfheen: /usr on a separate partiion?
<cjwatson> partition
<tfheen> cjwatson: no
<tfheen> (using the proprietary nvidia driver)
<tepsipakki> tfheen: run udev restart
<cjwatson> hmm, then I dunno, you're probably better-placed to debug than I
<tfheen> tepsipakki: humm?  It works fine if I just remove "splash" from the kernel command line.  Why would this be related to udev?
<tepsipakki> tfheen: oh, ok
<cjwatson> tfheen: kyle reported success with nvidia, but I suspect he's using the free drivers
<tfheen> cjwatson: yes, the splash displays fine.  It's X that falls over.
<cjwatson> I think we're far enough before release that we should try to fix this and not back out the amd64 fix yet again
<tfheen> cjwatson: sure; prodding here to see if somebody else has the same problem.
<cjwatson> good to know that the splash works at least
<tfheen> I need some food before I start debugging this
<pitti> tfheen: a friend of mine mentioned the same to me yesterday
<pitti> with nosplash X worked fine
<torkel> tfheen: does it work if you disable gdm and run it manually from a root prompt afterwards?
<tfheen> torkel: no
<torkel> it=/etc/init.d/gdm start
<tfheen> I'll try with various vbetool pokes, I think.
<tepsipakki> this is going to be fun.. merging xorg-server and updating it to 1.2.0
<tepsipakki> what a humungous diff
<pitti> does anyone know how to update linux-meta for a new kernel ABI? this is kind of urgent
<cjwatson> pitti: what release?
<pitti> cjwatson: kyle uploaded one for edgy-security, but not for dapper-security (new kernel: 2.6.15-28.51)
<cjwatson> ok, doesn't seem to have changed
<cjwatson> pitti: change KERNEL_ABI in debian/rules
<pitti> cjwatson: there's a new ABI
<pitti> ah, ok
<pitti> cjwatson: thanks
<cjwatson> np
<Lure> tfheen: hunger was asking about X starting before, not sure if he is on amd64 though
<cjwatson> argh, STOP FILING BUGS ON HERD 2
<\sh> what happend to my karma?
<pitti> \sh: it overflowed and started at 0 again
<cjwatson> all karma was reduced by a couple of orders of magnitude
<pitti> 'go back to start. do not get K4000.'
<Treenaks> pitti: ah.. using smallint? :P
<\sh> pitti: largefile karma support not compiled into python? ,-)
<hunger> Lure: I am not. X works again after doing a udev restart.
<Lure> hunger: ok, just thought it may be related
* pitti runs apport-qt4 the first time
* tepsipakki is falling in love with quilt
<tepsipakki> but first lunch
<mjg59> cjwatson: Not at all
<tfheen> so, if I strace X, it starts.
<tfheen> like, if I connect to the X server after it has failed to start for ten minutes.
<Keybuk> hmm, why does firefox (edgy) "freeze" when I open a new tab?
<Keybuk> hmm, interesting
* Keybuk may have Linux spyware
<Keybuk> which would be very impressive
<Treenaks> Keybuk: wow..
<Keybuk> it's writing to a socket and timing out
<Treenaks> Keybuk: what kind of socket?
<ajmitch> probably an extension
<Keybuk> firefox-b 8092 scott   52u  IPv4             215220             TCP quest.netsplit.com:48459->a212-135-93-135.deploy.akamaitechnologies.net:www (ESTABLISHED)
* ajmitch had similar issues until he disabled a few extensions a couple of days ago
<tfheen> Keybuk: sure it's not the phising stuff or something?
<tfheen> or rather, anti-phising.
<Keybuk> could be
<Keybuk> if the server is down
<Treenaks> could it be checking for updates on your extensions?
<mjg59> Right, I wouldn't expect the average spyware company to be able to afford akamai
<Keybuk> right
<Keybuk> hmm, isn't the phishing stuff
<Keybuk> it still freezes
* Treenaks gives Keybuk tshark (or tethereal, if on edgy)
<Keybuk> *shrug*
<Zdra> hi, can someone tell me how to use the new apport bug reports ? it attach tones of files now instead of a single .apport file
<Keybuk> I wiped .mozilla
<Keybuk> and it's fine
<Zdra> how can I retrace a bt ?
<pitti> Zdra: that's something I'm just working on
<pitti> Zdra: I'll teach apport-retrace to take a bug number
<Zdra> oh, goooooooddd !!!!
<pitti> Zdra: for now you have to download the core dump and ProcMaps.txt manually and use apport-retrace's command line switches
<pitti>   -r CORE, --core-file=CORE
<pitti>                         Override report's CoreFile
<pitti>   -x EXE, --executable=EXE
<pitti>                         Override report's ExecutablePath
<pitti>   -m MAPS, --procmaps=MAPS
<pitti>                         Override report's ProcMaps
<pitti> ^ these
<Zdra> one thing I dislike with the new behavious is I receive tones of email when a new bug is reported
<pitti> Zdra: not any more
<Zdra> one email by new attachment
<pitti> Zdra: this has been fixed for a few days
<Zdra> oh
<Zdra> ok :D
<seb128> what is the right package for a bug concerning the fisrt CD boot screen (the one where you can pick the language to use, etc)?
<Keybuk> pitti: was talking to kyle yesterday ... apport could do things like attach lspci -vvnn for kernel/udev reports, attach /var/log/boot for udev reports, etc.  right?
<tfheen> seb128: gfxboot-theme-ubuntu, most likely
<pitti> seb128: gfxboot
<seb128> thank you
<pitti> Keybuk: apport (0.48) feisty; urgency=low
<pitti>   New feature: Infrastructure for reporting kernel Oopses:
<tfheen> or gfxboot, depending on the problem.
<pitti> Keybuk: ^ this does exactly that :)
<seb128> tfheen: https://bugs.launchpad.net/ubuntu/+bug/82961
<Ubugtu> Malone bug 82961 in Ubuntu "Slovenian boot options descriptions are too long" [Undecided,Unconfirmed]  
<tfheen> g-t-u
<Keybuk> pitti: right, but is there a way to have it automatic for set of packages
<seb128> ok, thanks
<Keybuk> e.g. report bug on firefox -> always lists extensions
<pitti> Keybuk: and for udev, you can ship a per-package hook in /usr/share/apport/udev.py
<pitti> Keybuk: right, listing extensions sounds like a good idea, too (firefox apport hook)
<Keybuk> not that I'm trying to give you more work or anything :p
<Keybuk> it's just So. Shiny.
<Fujitsu> Do any other distros have a tool like apport?
<pitti> Keybuk: the per-package hooks should be implemented by the package maintainers anyway, since they usually know best what info they want (I will help them, of course)
<iwj> pitti: Would you care to cast an eye over my comments in https://wiki.ubuntu.com/MainInclusionReportCryptsetup ?
<pitti> iwj: will do today
<iwj> ogra complained about it up ^ there at 2157Z yesterday.
<iwj> Maybe I'm just being overly fierce.
<cjwatson> seb128: dupe of bug 81458, indeed :)
<Ubugtu> Malone bug 81458 in gfxboot-theme-ubuntu "F-key row should wrap" [Wishlist,Confirmed]  https://launchpad.net/bugs/81458
<pitti> it was indeed quite picky, but cryptsetup is a hard beast
<seb128> cjwatson: right ;)
<tfheen> iwj: oh, btw, your new udev packages fixed pam_mount for me.
<iwj> tfheen: Oh, good.
<cjwatson> BTW, anyone who fancies taking over gfxboot-theme-ubuntu is welcome
<iwj> tfheen: That's better news than yesterday morning.
<cjwatson> I'd been secretly planning to give it to iwj, but then he seems to have taken on enormous piles of other stuff :-)
<iwj> cjwatson: *snort*
<cjwatson> Familiarity with postfix-notation languages (esp. Forth) is a bonus
<Keybuk> cjwatson: now there's a qualification of doom on a job description
<cjwatson> I liked it
<iwj> You liked gfxboot-theme-ubuntu ?  Or Forth ? :-)
<cjwatson> the job description
<Keybuk> if we combined the job with the PDP-11 Port Maintainer, we might find somoene :p
<tfheen> Keybuk: if we combined it with that, I have a candidate in mind..
<cjwatson> Keybuk: that sounds like a job for which you should be the hiring manager
<tfheen> Keybuk: toresbe, who loves old computers.  The older, the better. :-P  (He was the kid at DC3 tinkering with the PDP10 in the library next to one of the hack rooms)
<cjwatson> Keybuk: perhaps "PostScript" is a slightly less exotic example. I'm not sure which is more accurate
* cjwatson doesn't know PostScript well enough
<elmo> just for the record, any talk of PDP ports is a shoot offence, mmk?
<cjwatson> elmo: don't we have room in the datacentre?
<thom> elmo: come on, you know you want one in L3
<thom> i can imagine the "hi, please reset the tape in our pdp-11 and reset it" calls at 4am to the "intelligent" monkey
<Keybuk> cjwatson: I can categorically say that a PDP-11 port does not count as "New Developments", and is definitely "Maintenance and Upstream Work"
<Keybuk> thom: imagine carrying one of *those* on the tube
<thom> Keybuk: not so useful as an ipod, no
<mneptok> does anyone have tho Hollereth cards for xserver-xorg? i need to do a stock run.
<iwj> No-one else has a mode 600 /dev/null, I take it.
<iwj> (apropos of bug 83878)
<Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
<iwj> Oh, I see various people do.
<_ion> Yay, the recent postgresql security update in edgy broke postgresql. Error: "Table has type character varying, but query expects character varying."
<pitti> _ion: should already be fixed 
<pitti> _ion: http://www.ubuntu.com/usn/usn-417-2 -> still doesn't help?
<hile> any good ideas for the passphrase query problem while I was away?
<_ion> pitti: Oh, my bad, i assumed the 'apt-get update' the cron job did last night would be recent enough. I apt-get updated now and i see the new postgresql packages.
<hile> cryptsetup initramfs, of course sorry
<pitti> _ion: well, actually my bad, I released a broken version to -security :/
<pitti> _ion: fortunately upstream was very quick to release a fix
<hile> I think good short term solution would be to clean up all lvm and evms stuff from current cryptroot script, let it just block like  now for the cryptoroot device itself and forget udev
<iwj> hile: Right, you probably don't have time now to do the proper fix.
<iwj> In the longer run initramfs init should pass some environment variables through to udev so udev hooks can talk to the user.
<hile> or could we have something like upstart in initramfs already? instead of ordered scripts, and let udev inform this process that a dependency is now ok, i.e. device is there, which would trigger the query
<hile> similarly all current hooks could just be ordered with this
<iwj> hile: Right, but in any case some daemon needs to make a UI query.
<hile> yep
<hile> well, I'll start the cleanup now, I'll send patches soon
<ogra> iwj, i'm not concerned about you being picky (i think pickyness is a requirement for that job ;) ), but about switching established procedures without announce, it would be nice to coordinate with pitti and to announce if and how we need to write our MIRs differently :)
<_ion> Upstart in initramfs, interesting.
<iwj> ogra: Really it just seemed obvious to me that a MIR is supposed to be a report of some investigative activity and not just a cut-and-paste of a fixed text.
<ogra> iwj, yes, but i see no reason to do copy paste jobs of lists that are linked already ...
<iwj> But the list is a list of _things to check_ and after you've checked them you should have _results of your investigation_, surely ?
<ogra> if i have to do additional stuff for the security review please give a hint what i should do etc
<ogra> right
<iwj> ogra: security> I'll discuss this with pitti but my very first google search found a vulnerability.
<ogra> ok
<iwj> And I think the proposer should do enough of a search that that doesn't happen.
<hile> ion, my thought was that since the initramfs is moving to async mode, upstart would be better than strictly ordered scripts ;)
<pitti> ah, there's a vuln that isn't CVEed?
<ogra> i dont look at google at all for the security stuff but use the two secunia and CVE links
<iwj> Maybe we can replace udev with upstart :-).
<_ion> keybuk: Thoughts? 
<ogra> haha
<iwj> ogra: I don't mind what tool you use.
<Keybuk> why would you?
<ogra> iwj, well, but neither has that vuln.
<iwj> I mind that I did a search myself and found something that wasn't mentioned in the report.
<Keybuk> udev does what it does well enough (listening to uevents and dispatching them)
<pitti> FWIW, neither 'cryptsetup vulnerability' nor 'cryptsetup security' gives a prominent google hit
<_ion> keybuk: to133500 < hile> ion, my thought was that since the initramfs is moving to async mode, upstart would be better than strictly  ordered scripts ;)
<Keybuk> if you need upstart functionality, it's easy -- just call initctl emit some-event from a udev rule and deal with it in an upstart job
<Keybuk> using upstart in the initramfs is nothing new
<ogra> iwj, well,for me as non security guy, i only follow the advised procedures ... which is to use the two search forms for the two sites ...
<Keybuk> jbailey and I had that in mind from the beginning
<iwj> ogra: The vulnerability I'm thinking of is in (at least) CVE.
<hile> keybuk, cool, so now the only problem for cryptsetup is really controlling termnal input ;)
<ogra> and i also think it makes your work easier if everyone uses the same template and you can see changes from the default on a first glance ...
<pitti> iwj: so far it has been common practice that the reviewer (me so far) did a more exhaustive security analysis
<iwj> pitti: Hmm.
<pitti> iwj: from the reporters I mainly expect QA assessment/research, justification, and buildability proof
<ogra> iwj, waht i say is not that i'm opposing to do more, but i want a hint for it in the rocedure documentation
<ogra> you guys are the reviewers and need to tel me as developer what you need
<pitti> iwj: but I think adding a google search for vulns could certainly be part of the template
<ogra> i'm fine with providing any kind of info if required
<Hobbsee> ogra: you really are supposed to be telepathic.
<ogra> Hobbsee, now who do you think made you just grab that coffeecup ? ;)
<iwj> pitti: Well, we have really two options for this process: the reviewer can do the security spadework, or they can check the proposer's.  The latter is somewhat more work overall but is less for the reviewers.
<Hobbsee> ogra: :)
<pitti> iwj: ideally the proposer would do the initial search, and the reviewer would verify it and do a shallow code review
<Hobbsee> ogra: you forgot to preface with sudo.  sorry, cant do :P
<ogra> haha
<pitti> iwj: I don't really want proposers to do a code review
<iwj> pitti: Right.  So what happened here is that I verified the search and came up with `failed'.
<iwj> code review> Quite so.
<iwj> I think we have a problem with the MainInclusionReportTemplate which is that people seem to think that the right thing is to cut-and-paste it.  Wiki Templates ought to be edited.
<pitti> iwj: yup, fair enough in this case; however, the security review should just help us to decide whether we can cope with the package; we can't refuse all packages which ever had a single vuln
<iwj> pitti: Well, indeed so.
<ogra> iwj, i dont even cut and paste :)
<iwj> So the report should say `these vulnerabilities [link]  [link] ' which are noncritical especially for us.
<pitti> iwj: right, the recent reports have been a bit sloppy in that regard in many cases
<iwj> or some such.
<iwj> It might help to rewrite the template in the form of questions, or perhaps obviously false statements.
<iwj> After all, things can be in main even if the sentences in the report template are false.
<iwj> The right thing is then for the actual report to describe the actual situation and justify the inclusion.
<iwj> Note above where our proposer is saying that it is somehow `easier' if the report is identical to the template even if perhaps not entirely accurate ...
<ogra> well, i would find it easier as reviewer to have a quick overview on first sight ...
<iwj> ??
<iwj> ATM if I read one of these reports I have no idea whether any of it is even slightly true because the proposer (a) might have failed to check certain things and (b) evidently feels that it would be wrong to deviate from the template wording even when the template wording is not true !
<ogra> well, if you look at: Standard debhelper/cdbs/dbs packaging, standard patch system.
<ogra> i would only chaneg it if neither is true ...
<ogra> *change
<cjwatson> why would you not even remove the bits that don't apply?
<ogra> if you know that, you can very quickly see if the packaging is fine from my POV
<cjwatson> it should be read as "debhelper/cdbs/dbs (delete as applicable)"
<iwj> ogra: I can tell that you think the package is fine because you put it into the queue!
<cjwatson> it can't possibly be all of debhelper, cdbs, and dbs
<ogra> right
<cjwatson> ogra: the point of you filling out a template rather than the reviewer just doing it all is for you to communicate useful information to the reviewer
<iwj> How about if I were to write at the top of the template something to say that the template should be vigorously edited when writing a report ?
<ogra> it's not how i used it yet (and nobody complained about it yet), i'm fine with doing it differently
<cjwatson> iwj: that would be excellent
<ogra> iwj, sounds good
<Kano> hi, whats wrong with the ubuntu kernel source? when i want to compile it with pbuilder/etch it comes to a point with
<pitti> well, I grew the habit of reviewing the entire diff.gz anyway, thus I don't mind the packaging stuff so much
<Kano> dpkg-gencontrol: error: package linux-image-2.6.20-kdump not in control info
<Kano> make[2] : *** [debian/linux-image-2.6.20-kdump]  Error 255
<Kano> and then all is over...
<ogra> iwj, i just took a look over all the other MIRs in the queue and they are not much different to mine ... thats why i spoke up
<ogra> so a template change would be a good start, but a documentation how to do a proper MIR would even be better ... i'm fine being a guineapig if you want one ...
* ogra wonders if he actually wrote guineapig wrong or if xchat simply doesnt know it ...
<Hobbsee> ogra: two words.
<Hobbsee> ogra: ie, guinea pig
<ogra> ah !
<Hobbsee> iirc
<Hobbsee> :)
<iwj> ogra: Well, I thought that it was obvious that template pages should be edited rather than just used verbatim but I suppose I have seen similar `must follow the template exactly' elsewhere.
<ogra> right ... it knows guinea pig
<iwj> ogra: Can you take a look at what I've written in the top two paras of MainInclusionReportTemplate.  Does that explain more clearly what we're expecting ?
<ogra> iwj, sounds good to me ... should probably be bold or something 
* iwj makes the template a list of questions rather than a list of answers.
<ogra> good idea
<elkbuntu> ogra, please see PM
<mjg59> pitti: Any idea why people are claiming vbetool is crashing on login?
<mjg59> Is this just because the dump is being made at boot time, and then processed at login?
* ogra shakes his head about bug 83550 and starts looking for the cathode beam on his LCD
<Ubugtu> Malone bug 83550 in gnome-power-manager "impossible to de-activate screensaver " [Undecided,Unconfirmed]  https://launchpad.net/bugs/83550
<ogra> elkbuntu, can we d it after the distro meeting ?
<ogra> *do
<pitti> mjg59: I guess so
<mjg59> pitti: Can we blacklist vbetool?
<mjg59> It's expected to crash sometimes
<elkbuntu> ogra, when does that end?
<mjg59> ogra: Uh, most TFTs use a cathode tube for backlighting
<ogra> elkbuntu, ~17:00 UTC
<pitti> mjg59: hm, I wouldn't like to hardcode the package name into apport itself, how about adding /usr/share/apport/blacklist.d/ ?
<ogra> mjg59, oh, really ? 
<mjg59> pitti: Sure, that works
<mjg59> ogra: Yes
<pitti> mjg59: or even /etc
<ogra> mjg59, i thought there is a dot matrix and just a backlight 
<mjg59> ogra: The backlight is a cathode tube. Not a cathode *ray* tube.
<ogra> ah, k
<mjg59> Google cold cathode tube
<ogra> mjg59, thanks :)
<Keybuk> ogra: are you not planning to attend the meeting today?
<ogra> Keybuk, i am, report will be there before
<Keybuk> ogra: report needs to be there by the end of the day yesterday
<Keybuk> otherwise it's missing from the agenda sent out in about 20 mins
<ogra> meh
<Keybuk> you were in the room when we discussed this :p
<Keybuk> of course, you're not formally required to take part :)
<ogra> but i want to :)
<pitti> mjg59: added to TODO: - support /etc/apport/blacklist.d/ for check_ignored()
<mjg59> pitti: Thanks!
<Keybuk> right :p  end of day wednesday is the "send the weekly report" time
<Keybuk> Colin and I write the agenda in the morning on thursday you see
<pitti> mjg59: proposed format: file has one executable name per line
<Keybuk> as that gives time for everybody to read it and propose new agenda items
<mjg59> pitti: That works
<elkbuntu> ogra, i'll be counting sheep then.. lets set an actual time?
<Keybuk> people who don't get their reports in (Hi Tollef!) get the shame of running the meeting <g>
<tfheen> hi Scott :-)
<ogra> elkbuntu, when do you get up (in UTC time) ? 
<Keybuk> tfheen: no, you don't need to run the meeting
<ogra> do i ?
<Keybuk> no :p
<ogra> :)
<tfheen> Keybuk: could we have the fridge calendar updated with the new meeting times?  It claims we should have had one this morning.
<ogra> elkbuntu, i'm fine with every time after 17:00 UTC 
<pitti> Keybuk: strictly, the requirement is to send activity reports to you and CC: distro-team; does it work for you to just send them to d-t?
<Keybuk> pitti: yes
<ogra> tfheen, for me it says 17:00 local time
<Keybuk> tfheen: who runs the fridge calendar?
<ogra> unless my evo missed to sync
<pitti> tfheen: my evo import says 17:00 (CET)
<elkbuntu> ogra, 21:00, but i'll be unavailable tomorrow until 04:00... how about the following UTC evening?
<tfheen> Keybuk: fridge-devel@lists.u.c
<tfheen> so I guess I could mail them myself when my mail server starts working.
<cjwatson> Riddell: hey, if your enabling-additional-components changes are done, does that mean I can flip the installer switch?
<ogra> elkbuntu, fine as well, unless i manage to make it by mail until then :)
<elkbuntu> ogra, the chances dont seem good for that :
<ogra> :)
<tfheen> actually, it's the distro team calendar on google calendar which is broken.
<tfheen> or wrong.
<Keybuk> hmm?
<Keybuk> distro team calendar is right
<Riddell> cjwatson: yes please!
<cjwatson> sfllaw: no update from you either, apparently
<ogra> elkbuntu, really sorry, but pre feature freeze is a hard time for extra stuff
<Keybuk> tfheen: says 1600UTC
<pitti> Keybuk: but it's 1700 UTC, no?
<elkbuntu> ogra, i know, which is why for most of the week i avoided harassing too much
<ogra> thanks for that
<pitti> Keybuk: (not that I would mind 1600)
<Keybuk> no... it's 1600UTC
<pitti> Riddell: https://code.launchpad.net/~mh21/+branch/apport/gui-qt4
<Keybuk> "This week's team meeting is scheduled for 1600 UTC tomorrow, on #ubuntu-meeting as usual."
<pitti> Keybuk: ah, ok
<Riddell> pitti: goodness
<Keybuk> the schedule is alternating 1600/2100 UTC
<tfheen> Keybuk: grr, then evolution is just being silly here.
<pitti> Riddell: I tried it out this morning and found a grave bug, should be fixed now; I'll try it again soon
<ogra> tfheen, it pulls from the fridge ---> <Ubugtu> Schedule for Etc/UTC: 08 Feb 16:00: Ubuntu Development Team 
<tfheen> ogra: yes, as I said, it's evolution which is being silly.
<ogra> yep
<tfheen> seb128: can I tell e-d-s to pull down a calendar again, since it's clearly confused here.
<cjwatson> pitti/iwj: any chance of a migration-assistant MIR review today? I'm hoping to get the corresponding ubiquity branch merged for FF
<pitti> yes, of course
<ogra> pitti, iwj, the two sound related packages and python-ltsp would also be fine (both needed for specs)
<cjwatson> pitti: thanks
* tfheen radiates hate at hardware and goes to make some tea.
<Tonio_> seb128: ping ?
<Tonio_> seb128: was just looking at the kubuntu-default-settings bug and saw that some gnome users complains that the defaults for kde apps on gnome are somehow nasty (cursor problems etc...)
<Tonio_> seb128: I was wondering if making ubuntu-desktop depends on kubuntu-default-settings wouldn't make it easier for them.... although I know this is hard to figure out ;)
<seb128> Tonio_: pong
<seb128> Tonio_: no, ubuntu-desktop Depends on kubuntu-default-settings doesn't look a good idea
<seb128> Tonio_: there is plenty of GNOME users who don't run a KDE app and no KDE app installed by ubuntu-desktop, so no reason to force kubuntu-default-settings
<Tonio_> seb128: I knew this :) but it would be interesting if a gnome user installing a kde app gets invited somehow to install that package too
<Tonio_> seb128: I agree with you on that point, but for the ones who do it there is no way for them to know how to get a proper config
<seb128> make libkde Recommends kubuntu-default-settings
<seb128> or libqt-x11 or whatever package make use of those settings
<fabbione> mvo: ping?
<Tonio_> seb128: hum, could make sense indeed, will discuss with riddell on that point
<Tonio_> seb128: thanks
<seb128> np
<tkamppeter> pitti, ping
<pitti> tkamppeter: pong
<tkamppeter> pitti, I have uploaded a new foomatic-db which renames the PPD packages and directories to openprinting, see mail
<tkamppeter> pitt, I have also updated the SpliX driver package from 1.0.1b2 to 1.0.1.
* pitti adds that to the huge pile of stuff to do for today
<fabbione> Nafallo: ping?
<Nafallo> fabbione: pong
<pitti> yay for apport-retrace taking a LP bug number
<pitti> Zdra, seb128: ^
* seb128 hugs pitti
<seb128> excellent
<pitti> seb128: you can only use -s or -g with it (no direct updating of the bug yet), but it should help already
<seb128> yeah
<pitti> seb128: oh, --output/-o works as well, of course
<pitti> seb128: looks like this now: 'apport-retrace -o 83947-retraced.crash -c -d -C ~/.ddebs/ 83947' -> that's fine for you, or any idea for improvements?
<seb128> pitti: looks cool, I'll let you know if I've some problems with when I'll have used it on some bugs etc
<seb128> pitti: thank you ;)
<pitti> you're welcome
* givr1 still wonder why fuse i386 & amd64 binary didn't enter hit yet the archive...
<givr1> infinity: ^^ did you get time to look at it ?
<Chipzz> is there a bug-number or spec for the integration of encrypted / in the boot-process?
<ogra> Chipzz, i think there was a spec, but the main inclusion report for cryptsetup was rejected yesterday ... needs some work nobody has time for atm
<doko> tkamppeter: is the foomatic renaming really needed for feisty?
<Chipzz> ogra: I was just talking to someone who attempted to do this himself, maybe I could direct him here to coordinate or sth?
<ogra> Chipzz, it will need udev and upstart inetgration ...
<ogra> and some smaller fixes in the package
<fabbione> Nafallo: this mplayer bug is fishy.. turning -O4 to -O0 -ggdb make it works
<tfheen> Nafallo: which bug is this?
<fabbione> oh actually
<fabbione> tfheen: i just noticed that latest mplayer crashes on ppc
<exobuzz> sounds like gcc is fishy :-)
<fabbione> and the package needs to be redone.. 
<fabbione> exobuzz:no.. i did a bad test
<fabbione> Nafallo: you really want to split that shared library out of mplayer package
<ogra> fabbione, is your hwdb-client crash fixed with the latest package ? 
<fabbione> exobuzz: the bug might be just in the shared lib or one of the codecs..
<exobuzz> fabbione: oh..
<fabbione> ogra: checking right away
<fabbione> ogra: yeps.. it starts...
* fabbione runs
<ogra> yay
<fabbione> +it
<ogra> somehow the #DEBHELPER# line was missing from the postinst ...
<ogra> silly bug
<fabbione> ogra: it's all good.. thanks a lot
<ogra> thanks for testing :)
<fabbione> do we have a tcl/tk guy?
<fabbione> or with a bit of knowledge in that area?
<exobuzz> tcl *shudder*
<seb128> not me
* ogra used to start with tcl scripting back in the 90s ... but i havent touched it since
<fabbione> seb128: i *had* that feeling about you :P
<seb128> ;)
<fabbione> i am more looking for somebody to review a patch for SRU
* exobuzz did some eggdrop bot scripts in tcl.. and swore never to lok at that language again 
<ogra> not me then
<fabbione> even if it's already included in feisty and upstream
<seb128> fabbione: maybe give the bug number on the chan ;)
<seb128> that would be a start
<fabbione> seb128: there is no bug number yet. I got a patch from David Miller (the kernel guy) with the info. but there is no easy test case to prove the fix
<fabbione> it's an endianess / allignment bug
<exobuzz> what's the bug ? oh.
<fabbione> and it's rarely triggered when scrolling some japanese text encoded in UTF-8 in a specific moment
<seb128> do we want to backport that for edgy?
<ogra> exobuzz, you can wear sunglasses ... its not *that* evil with them ...
<fabbione> seb128: also in dapper...
<seb128> that doesn't look like a high priority fix
<exobuzz> ogra: :)
<seb128> well, dapper I can understand
<fabbione> seb128: no it's not a high priority, but it affects ppc too
<seb128> edgy I've some doubt it's useful
<fabbione> and we do support dapper/edgy.. so once you do one SRU, might as well do edgy in the same
<fabbione> oh cool.. there is a 3 lines test case...
<fabbione> yeah
<exobuzz> there are more important bugs which could be fixed though surely? like the one where ethernet doesnt really work on a certain sis900 moterhboard (fixed in kernel for edgy) ;-)
<exobuzz> i mean, if you are going to backport fixes to dapper.
<fabbione> exobuzz: talk to the kernel team for that
<exobuzz> well i mean, i dont care, since i upgraded .. but
<exobuzz> noone else reported it so, i guess noone else with dapper has that motherboard (or triggers the bug)..
<givre> ogra: do you have some time to look at a little correction in fuse package ?
<givre> ogra: debdiff -> http://flomertens.keo.in/merge/debdiff_ubuntu1-ubuntu2
<Kano> givre: btw. you NEED to update to fuse 2.6.3,because ntfs-3g does not run with it correctly.update ntfs-3g too...
<givre> Kano: afaik it was the fuse module that cause problems
<Kano> well i updated both for me
<Kano> no big deal to go from 2.6.2 to 2.6.3, same debian dir works
<Kano> similar for ntfs-3g
<Kano> (when you update the experimental deb)
<tkamppeter> doko, sorry, I have been at lunch. I have answered your e-mail now.
<Kano> but i still have problems mounting ntfs-3g with uuids
<Kano> ntfs works , UUID= only with patched mount, but the main thing is that mount -a works 
<Kano> mount -a does not work correctly with ntfs-3g
<Kano> when already mounted
<givre> Kano: no big deal, but who is going to sponsors me on that ;) , i'm not even a motu
<Kano> well i patch it for me ;)
<givre> Kano: strange, works ok for me
<pitti> ogra: do you need the pulse MIRs today? or is next week enough?
<Kano> givre: of course the latest versions would be nice,because ntfs-3g got some needed patches
<Kano> with older versions chkdsk may delete some new files
<givre> Kano: i'd like to push it, but we don't have even have fuse 2.6.* in the archive
<Kano> givre: which is really sad...
<givre> Kano: we uploaded 2.6.2 last week but binary for i386 & amd64 get lost somewhere...
<Kano> as it would fit perfectly to a 2.6.20 kernel
<Kano> just to directly to 2.6.3...
<pitti> cjwatson: m-a looks good, approved
<evand> pitti: thanks!
<Kano> and what about m-a in main?
<Kano> a tool that i always install...
<Kano> now i give a message to change sources.list
<Kano> not that good...
<pitti> evand: two little things: could you add the common-licenses pointer to debian/copyright and add a long description for the package?
<evand> pitti: Sure thing.
<fabbione> Nafallo: so it's definetely an optimization issue.. full code built with -O0 works
<fabbione> Nafallo: now the fun part is going to find out where it break
<tfheen> fabbione: try -fno-strict-aliasing
<cjwatson> Kano: are you sure you're talking about the same m-a as we are? migration-assistant
<cjwatson> pitti: thanks
<Kano> no, m-a is the official short name for module-assistant
<cjwatson> mvo: interesting, you marked enabling-additional-components Implemented before I made the installer change ...?
<cjwatson> Kano: well, pitti and I knew what we were talking about.
<fabbione> tfheen: ok.. in one of the next builds
<Kano> /usr/bin/m-a is in the module-assistant package
<cjwatson> *shrug*
<cjwatson> please take it elsewhere, we were trying to coordinate development which is what this channel is for
<tepsipakki> took awhile, but xorg-server-1.2.0 is now merged..
<doko> tkamppeter: splix and foomatic-db uploaded
<cjwatson> mvo_: but I've flicked the switch in the installer now
<ogra> givre, i discovered yesterday as well, but i'm not sure we want 45-fuse.rules ... did you ask someone from the udev fraction ?
<ogra> Keybuk, seems fuse in debian ships a differently numbered fuse rules file for udev, we have identical 45-fuse.rules and 80-fuse.rules now ... which one is the right one udev lies more ?
<ogra> *likes
* ogra happens to remember being told that external packages should use 80 and onwards as sequence numbers ... or something like that
<Keybuk> what does the file contain?
<Keybuk> /etc/udev/rules.d/README ? :)
<ogra> just the permissions for /dev/fuse
<Keybuk> then it should be 45
<ogra> ok
<givre> ogra: no it was just a mistake : 80 is rules that run stuff, 40 are just rules that set permissions
<ogra> ok, i tought they were identical
<Keybuk> (our numbering is set up so that *user* rules can always just be 50-*.rules)
<givre> ogra: in the first attempt, i set it to 80 because we run stuff
<ogra> Keybuk, thanks a lot
<Keybuk> if permissions are set in an 80-*.rules file, they'd override anything the user set
<ogra> right
<Keybuk> that's why if you do more than one thing (set the name, permissions, etc.) you should split it into multiple files
<ogra> i'll read the README next time :)
<givre> ogra: but now that all is done in /etc/modprobe.d, better to use 45
<givre> which is the one also use in edgy 
<ogra> pitti, as long as i get them to main i'm fine, thanks ... i just cant set the spec to implemented then but i'm fine doing that later
<ogra> givre, yep, i'm fine with that patch ... will test and upload tonight ...
<torkel> pitti: any idea when the new dapper kernels will hit the archive? linux-meta is available but not the actual kernels
<tkamppeter> doko, thanks. Now only the new foomatic-db-hpijs needs to be uploaded, so that all new printers supported by HPLIP 1.7.1 will really appear in the printer setup tools. See mail.
<pitti> torkel: it's due to bug 83976
<Ubugtu> Malone bug 83976 in soyuz "-security vs. -updates/-proposed version comparison needs to be removed" [Critical,In progress]  https://launchpad.net/bugs/83976
<givre> ogra: ok many thanks :)
<doko> tkamppeter: ok
<pitti> torkel: I was told that this bug should be fixed by tonight, so I can re-upload/re-publish tomorrow morning
<torkel> pitti: ok
<tkamppeter> doko, thanks.
<pitti> doko: all these dict-* sources look a bit painful: they duplicate the munch/unmunch code and a complicated debian/rules; wouldn't it be easier to have a common source package for all of those?
<Riddell> cjwatson: are you going to add commercial to the sources.list file too?
<doko> pitti: they are updated separately; so we would get updates for all 20 binary packages.
<bddebian> Heya
<pitti> *shrug*, will they be updated that often?
<doko> pitti: the "complicated" debian/rules is standard for building aspell dictionary packages
<pitti> . o O { /usr/share/cdbs/1/rules/aspell.mk }
* pitti ducks
<Keybuk> http://en.wikipedia.org/wiki/Ben_Collins_%28hacker%29
<Keybuk> heh
<Keybuk> now there's an article that needs some improvement
<kylem> lol.
<pitti> ogra: can you please see thin-client-manager to keep it in main?
<pitti> ogra: s/see/seed/
<cjwatson> Riddell: hadn't been planning to
<mvo_> cjwatson: sorry for the enabling-additional-compents thing. that seemed to be a misunderstanding then
<elmo> Keybuk: yeah, there's no mention of cows or mad bowling skillz
<Keybuk> or being a poker shark
<iwj> crw------- 1 root root 1, 3 2007-02-08 11:24 /dev/null
<iwj> Yay!  It's doing it to me too now.
<cjwatson> mvo_: never mind, done now
<_ion> iwj: It's more secure now!
<pitti> never loose important data again!
<Keybuk> iwj: yeah, that means that the event got lost
<iwj> Which event ?
<Keybuk> check for "event queue overflow" and make sure null is listed in /var/log/udev
<Keybuk> iwj: add /class/misc/null
<Riddell> cjwatson: what's the reason not to?
<cjwatson> Riddell: it just doesn't feel appropriate somehow
<cjwatson> Riddell: I thought the graphical tools to install from there did it themselves anyway
<Riddell> cjwatson: I think gnome-app-install does edit sources.list for you, but adept doesn't, hence my interest :)
<Amaranth> fix adept :P
<eriklo> congratulations
<Amaranth> ?
<Amaranth> wth was that?
<Riddell> Amaranth: or software-properties
<cjwatson> Riddell: it just feels too much like using undue influence
<cjwatson> I think the commercial stuff should definitely be an explicit choice
<seb128> BenC: any upload planned to fix apport? we keep getting crash bug with invalid coredump and no bt :/
<pitti> seb128: bah, that's just like in the old times :/
<BenC> seb128: I have an upload, but it's too soon to upload my apport fixes without some more testing
<cjwatson> tfheen: changelog-closes-bugs doesn't seem to actually work ...
<seb128> pitti: no, the worst we had since warty
<seb128> pitti: new apport make easy to send bugs by a click, people use it
<seb128> and for some reason bt are just "??" at the moment
<pitti> BenC: if you have an amd64 kernel around, I'll be happy to test it
<seb128> and the coredump are not valid
<pitti> seb128: right
<BenC> pitti: Ok, I'll get one built
<cjwatson> tfheen: I get "dpkg-genchanges: warning: unknown information field `Launchpad-Bugs-Fixed' in input data in parsed version of changelog", but it doesn't appear in the .changes
<BenC> pitti: Let me get this upload done, and we can do some testing, and another upload later tonight or tomorrow if things test ok
<pitti> BenC: I can build it myself, too
<seb128> pitti: I'm fine with rejecting all those bugs, it's just not easy to explain to people why we make them send megas over internet for nothing :/
<pitti> BenC: sure, I have plenty of MIR/NEW stuff to do ATM for FF :)
<BenC> pitti: By the time I can send you a patch that I am comfortable is working, I'll have a .deb too :)
<pitti> BenC: heh
<cjwatson> tfheen: I think dpkg-genchanges needs to be told about it, as well as the changelog parser
<tfheen> cjwatson: yes, as I noted in my weekly report there's a bug there.
<tfheen> cjwatson: I'll just fix it now.
<ogra> pitti, seeds changed, it needs a -meta rebuild as well so may take some time still
<ogra> mvo_, does python-apt have an equivalent to 'dpkg --print-architecture' ?
<cjwatson> tfheen: ah, I missed that in your report
<mvo_> ogra: apt_pkg.Config.Find("APT::Architecture")
<ogra> ah, thanks
<cjwatson> tfheen: ... wasn't in your report
<tfheen> cjwatson: at least I intended to write it, I think I remembered too. :-)
<tfheen> oh well
<tfheen> cjwatson: it'll be fixed RSN
<cjwatson> * changelog-closes-bugs: Distro side implemented, needs infrastructure
<cjwatson>   in Soyuz and Malone.
<cjwatson> thanks
<tfheen> just doing a test build now
<iwj> Keybuk: What arranges that the udevtrigger invoked by /etc/init.d/udev happens only after udev is properly started up and listening ?
<Keybuk> udevd doesn't fork() until it's properly started up and listening
<iwj> Ah.  Hmm, that means my reproduction of this mode 600 /dev/null is due to the way I tried to capture udev's debug output.
<\sh> wow...I just read that linspire and ubuntu are now one ... congrats to linspire 
<bddebian> Hah
* dholbach takes away \sh's crack pipe ;-)
<bddebian> haha
<\sh> dholbach: lwn :)
<\sh> http://lwn.net/Articles/221217/ Linspire switches to ubuntu :)
<dholbach> "are now one" stretches the truth a bit... don't you think? that's not even what LWN writes :)
<jdub> just means linspire finally got the sense to use *all* of the ubuntu packages instead of snorting a few here and there ;)
<\sh> dholbach: a bit exaggerated ,-)
<dholbach> jdub: hehe
<jdub> dude
<jdub> have you seen the front cover of linux format from late last year?
<dholbach> no?
<jdub> i just got it
<dholbach> oh... was that the black cover with HUGE ubuntu logo?
<jdub> it's hilarious
<jdub> nono, the fedora one
<jdub> with me in it
<dholbach> ah, no
<jdub> "I was ready to walk out, because it sounded like the stupidest thing ever." - Jeff Waugh on Ubuntu's origins
<jdub> right next to my mug
<dholbach> ?
<jdub> mug == face in empire lingo
<dholbach> can you scan that in?
<jdub> hrm, no
<jdub> oh
<jdub> but i have a cool camera now
<jdub> i wonder if i can take a non-arse shot
<dholbach> try! else I won't udnerstand what you're talking about ;-)
* dholbach hugs jdub
<thom> jdub: your obsession with arses could get very disturbing mated to an SLR
<Keybuk> jdub: it was a good article
<Keybuk> http://www.linuxformat.co.uk/minicovers/87.jpg
* Keybuk can't find a larger
<jdub> taking photo now
<jdub> i'll add it to the blog entry ;()
<jdub> ;)
<jdub> Keybuk: pretty good for my (almost) final act of evangelism ;)
* Keybuk still hasn't seen the upstart article in this month's Linux Magazine
<jdub> dholbach: http://www.flickr.com/photos/jdubflickr/383758924/
<dholbach> jdub: and what do they say on p48?
<Keybuk> jdub: nice background!
<jdub> dholbach: reload for link to complete interview (longer than in the magazine)
<jdub> Keybuk: i got a new green book :)
<cjwatson> jdub: interesting misspelling of mvo's name in there
<cjwatson> "Michael Faulks"
<jdub> yeah
<jdub> kinda wang
<jdub> at least that wasn't in the magazine
<jdub> well
<jdub> that whole section wasn't
<jdub> which isn't necessarily better for mvo ;)
<mvo> woah and I thought I have seen all crazy spelling already
<jdub> looks like he guessed an anglo-ish name based on my pronounciation
<cjwatson> great interview though
<mdz> tkamppeter: meeting in #ubuntu-meeting now
<thom> turning mako into "Mako-Hill" is pretty funny too
<Zic_> hello, the last package of linux-image-generic is broken, it can't install the linux-image-2.6.17-11-generic package ...
<Zic_> I think it's a problem with edgy-backport
<pitti> Zic_: known problem, it's due to a bug in LP; we are working hard on it
<Zic_> pitti: thanks :)
<Zic_> pitti: the cause is edgy-backport isn't it ?
<fabbione> Zic_: it's a bit more complicated than that
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Herd 3 released. | dapper/edgy-security kernels are uninstallable, we are working on it (https://launchpad.net/bugs/83976)
<pitti> Zic_: no, it's not
<Zic_> ok :) I'm waiting so :)
<shawarma> I just filed a sync request (Bug 84017).. is that sufficient to be in time for UVF?
<Ubugtu> Malone bug 84017 in rawstudio "Please sync 0.5-1 from Debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84017
<tfheen> cjwatson: fixed dpkg uploading
<cjwatson> thanks
<cjwatson> Riddell:   * Import translations for Cancel, Back, Forward etc. buttons from gtk+2.0
<cjwatson>     2.10.9-0ubuntu1 (LP: #43915).
<Riddell> ooh, lovely, thanks
<cjwatson> Riddell: FYI. It's hacky as hell but it works for GTK; I've done my best (without testing) to make it work for KDE
<ogra> cjwatson, well, half done means that we need to support half done for 18 months 
<ogra> and that we need working upgrades to a later full done variant etc
<cjwatson> ogra: this is a bit like saying that if we only finish half the merges from Debian then we need to roll them all back
<tfheen> X is modular, that's kinda the point.
<cjwatson> ogra: the entire point of modular X is that (barring driver ABI issues, which are obvious and will just break hard) it CAN be loosely coupled
<ogra> dont hook up on the rollback i mentioned ...
<cjwatson> I'm not concerned about working upgrades. The X packaging is for the most part really, really simple.
<ogra> mdz expressed what i meant, a proper commitment at least
<cjwatson> you'd have to work hard to make upgrades difficult at this point
<cjwatson> we've done all the hard bits
<ogra> right, but still all 70 or so pkgs upgraded is better than only half of them ... and if someone starts to do it i'd ask for a commitment for all of them ...
<tepsipakki> speaking of X, I have now a xorg-server package ready, building needs some newer libraries (libdrm-2.3 is where it failed)
<tepsipakki> also the libs and apps are ready
<pitti> tepsipakki: what about mesa? I heard that the merge would be pretty tricky
<tepsipakki> pitti: yeah.. that's what I'm looking at now
<tepsipakki> it was waaay back when they were merged
<tepsipakki> last time
<tepsipakki> and Debian has 6.5.2-2 in experimental
<tepsipakki> but now I'm trying with 6.5.1-0.5
<cjwatson> tepsipakki: have you been watching #ubuntu-meeting?
<tepsipakki> nope, what's there?
<cjwatson> tepsipakki: hmm, apparently not; would be worth reading the logs as we discussed X
<tepsipakki> oh, ok
<cjwatson> tepsipakki: I'll be posting stuff to -devel probably tomorrow now
<tepsipakki> I'll do that
<fabbione> tepsipakki: are you aware that you need to start from all the prototypes then libs then xserver and then drivers, right?
<cjwatson> mesa needs to be merged first, I think; at least before the server
<cjwatson> fabbione: we're not that far behind on prototypes and libraries; if the server builds at all I'd be happy
<fabbione> cjwatson: be careful of that.. some features that are on now, might switch off if not done properly
<tepsipakki> fabbione: it seems that proto hasn't changed much if at all
<fabbione> cjwatson: specially if people are not reading carefully all the build logd
<fabbione> logs even
<cjwatson> fabbione: *shrug* I'm sure we'll build xorg-server again
<iwj> tkamppeter: re bug 83924> Hmm.  I'm not sure it's "the same bug" but if we have it breaking on a system where the user is responsive we might be able to debug it.  Can you get the submitter to gather the info like I suggest in 83878 ?
<Ubugtu> Malone bug 83924 in hplip "[apport] [feisty]  hpssd crashed with IOError in daemonize()" [Medium,Unconfirmed]  https://launchpad.net/bugs/83924
<cjwatson> fabbione: I take your point but I think tepsipakki is taking account of some ordering anyway, from what I've seen
<fabbione> cjwatson: oh yeah.. i know that.. it's a matter of properties propagation from prototype to lib to server to driver..
<fabbione> paying a bit of extra care at the beginning will spare you tons of headacke later
<fabbione> tepsipakki: ^^
<tepsipakki> I started from the libs because they were easy and I something that could be done last night :)
<tepsipakki> fabbione: yes
<fabbione> tepsipakki: no you need to make sure to start from the prototypes
<fabbione> libs come right after that
<fabbione> also.. read carefully all the build logs
<tepsipakki> ok, thanks for that
<fabbione> at least once
<tepsipakki> I haven't built anything yet ;)
<fabbione> to make sure you get all the features enabled
<tepsipakki> just source packages
<cjwatson> tepsipakki: how much of this comes from Debian experimental?
<tepsipakki> cjwatson: not much
<cjwatson> tepsipakki: because we're in sync on all the prototypes and nearly all the libraries at the moment; is any of it *in* Debian experimental?
<cjwatson> if we can sync from them, it would be preferable, given our manpower limitations
<tepsipakki> actually, all the versions are from 7.2, nothing newer
<tepsipakki> there isn't much.. I'm afraid
<cjwatson> that's a great shame
<cjwatson> perhaps we can work with debian-x on this
<tepsipakki> perhaps
<tepsipakki> maybe I should put xorg-server somewhere soon
<tepsipakki> there were tons of patches, but luckily the tricky ones are already upstream
<fabbione> tepsipakki: the server comes last.. please go in order or you will end up in a mess :/
<tepsipakki> hehe
<tepsipakki> I wanted to do it when I was awake :)
<tepsipakki> it took maybe six hours
<tepsipakki> or more.. but I'll check the prototypes now
<pitti> tfheen: I guess from the meeting I have approval for packaging/adding apport-qt?
<pitti> tfheen: (will do this evening)
<tfheen> pitti: please.
<tfheen> BenC: but if it's not shipped as part of the upstream kernel, it should be a separate package.
<BenC> tfheen: We have a lot of stuff that is in our kernel that isn't shipped upstream :)
<BenC> this package isn't even in Debian, so can't even sync it
<tfheen> BenC: to me it sounded akin to putting some random source package in the kernel source.
<tepsipakki> ooh, experimental has libdrm-2.3.0-1
<BenC> NEW + MIR just for a small program to build a semi important kernel flavour is a lot of work
<tfheen> if it's small, both NEW and MIR are small things.
<BenC> the other problem is the name of the package
<BenC> dtc is taken in Debian by some other package entirely
<BenC> device-tree-compiler is sort of long, but probably best
<tkamppeter> iwj, I have asked the original poster of the HPLIP bug for the information.
<iwj> tkamppeter: Ta.
<tfheen> BenC: coolie.  Prod me or another archive admin when it's in.
<BenC> tfheen: Hopefully wont take long
<ogra> cjwatson, sbalneav and jammcq poke me more often about the cipher=none thing ...
<ogra> i thought i'd forward one for ten ... :)
<TheBearded1_> can anybody tell me if bash in ubuntu feisty is compiled with --enable-net-redirections?
<TheBearded1_> can anybody tell me if bash in ubuntu feisty is compiled with --enable-net-redirections?
<tfheen> TheBearded1_: it's not.
<gpocentek> tfheen: is there a way to modify the ubuntu live CD to use a custom xorg.conf, ie not reconfiguring the xserver-xorg package? It seems that only removing the casper script doesn't help...
<ubuntugeek> not sure if this is right place.. but we got alot of users with issues with the latest kernel update. http://ubuntuforums.org/showthread.php?t=356408 if anyone wants to check it out
<tfheen> gpocentek: removing the relevant bit of casper and putting an xorg.conf should work.
<gpocentek> tfheen: I've replaced the xorg.conf and removed 20xconfig, but xorg.conf is still modified. Is there something else I should remove?
<iwj> Keybuk: * Drop the "|| true"s from usplash_write calls, infinity says they're unnecessary' vs bug 83878
<Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
<Keybuk> iwj: ref?
<iwj> udev changelog, 079-0ubuntu22 Thu, 23 Mar 2006 17:44:13 +0000
<iwj> The problem is that usplash_write now links against libx86.
<iwj> Which is in /usr.
<tfheen> gpocentek: no, that should have been enough, I'd think.
<gpocentek> hm...
<Keybuk> right ... how does dropping the || true help?
<iwj> Dropping the ||true makes it break.
<iwj> Specifically, it means that if usplash_write fails, udev doesn't start.
<iwj> So before reverting that change I thought I'd talk to you.
<iwj> Also I think libx86 should perhaps be in /lib but I should talk to err Colin ?
<stgraber> iwj: I have that /dev/null and /dev/zero permission problem on my laptop, do you need any other information about that bug ? (I posted a comment with the datas you requested)
<iwj> stgraber: Ah, hi.  Do you have /usr on a separate partition ?
<stgraber> yes
<iwj> stgraber: Right, we know what the problem is and I'm working on it.
<iwj> The primary bug for this is 83878.
<gismo> hello all
<iwj> Ah, you're the reporter of 83924.
<stgraber> ok, good to hear :)
<iwj> So you've just answered my question.
<Keybuk> iwj: gimme 20 mins
<iwj> Keybuk: Sure.
<kylem> http://fedoraproject.org/wiki/Releases/FeatureCustomDistro?highlight=%28CategoryFedora7Features%29
<kylem> heh.
<gismo> little question: How can I get the list of installed files using python-apt ?
<iwj> cjwatson: See discussion in bug 83878 re libx86.  If /usr is a separate partition then usplash_write fails and causes udev not to start.
<Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
<iwj> Should we move libx86 to /lib ?
<mjg59> iwj: Yeah
<iwj> mjg59: Yeah we should move it ?
<mjg59> iwj: Yes
<iwj> Right, willdo.
<tepsipakki> iwj: thanks for working on that
<iwj> Thank Timo Aaltonon who debugged it.
<tepsipakki> ant of course Mathieu who provided the info
<tepsipakki> nope, not me ;)
<iwj> Sorry, yes, Matthieu I mean.
<iwj> Looking at the wrong bug.
<tepsipakki> fabbione: looks like all the x11proto-stuff is uptodate, although randr and input have newer versions but not for 7.2
<tepsipakki> sorry, I forgot x11proto-core (7.0.7->7.0.10)
<Keybuk> iwj: sorry, I can give you my full attention now
<iwj> Sure.
<iwj> I just wanted your permission to reinstate ||: after the call to usplash_write in /etc/init.d/udev.
<Keybuk> the usplash_write thing; we used to || true those calls on general principle
<Keybuk> but then usplash_write got fixed so we didn't need to
<Keybuk> someone broke usplash_write again?
<Keybuk> why does it link to libx86?
<mjg59> usplash_write really shouldn't
<Keybuk> I can understand usplash linking to that, not the IPC client for it
<mjg59> Hm. Maybe Colin added libx86 to the wrong bit of the makefile?
<Keybuk> (and if usplash links to it, it should be in /lib really)
<iwj> mjg59: Aha.
<mjg59> But it should be in /lib /anyway/
<mjg59> Given that usplash is
<iwj> Keybuk: I've just uploaded a libx86 with it in /lib so the users' problem is fixed now :-).
<Keybuk> yeah, solution would be
<Keybuk> 1) libx86 should be in /lib
<Keybuk> 2) usplash_write should not link to libx86  (only usplash should)
<Keybuk> then there's no need for the || true
<BenC> tfheen: device-tree-compiler uploaded...so probably hit NEW queue in a few minutes
<Keybuk> there's definitely a bunch of things, not just udev, that don't || true
<iwj> But ||: is good practice in this case.  /etc/init.d/udev should not bomb out for these kinds of reasons.
<Keybuk> tbh, I don't mind either way
<iwj> It's part of the responsibility when you say set -e, to add ||: when appropriate.
<Keybuk> I took it out because infinity nagged
<iwj> Well, infinity isn't here so if we can't find a good reason I'll revert it :-).
<Keybuk> revert that on the safe side as well
<Keybuk> you're right, there's no reason udev should ever fail because of usplash
<cjwatson> iwj: I already moved libx86
<iwj> cjwatson: Oh, our uploads will clash then.
<cjwatson> iwj: first thing this morning
<cjwatson> iwj: no, yours will be rejected ;-)
<iwj> That's a clash.
<cjwatson> fair enough
<cjwatson> my fix was -1.2
<iwj> Ah.  Mine was -1ubuntu1.
<iwj> So if it's 1.2 I don't need to worry about pushing the patch.  Good.
<cjwatson> yes, mjg59 OKed an NMU
<cjwatson> (-1ubuntu1 would have been wrong anyway, since the broken version was -1.1)
<cjwatson> oh
<cjwatson>   libx86-1 |     0.99-1 |        feisty | i386
<cjwatson> I wonder why that failed to build
<iwj> libx86 (0.99-1) unstable; urgency=low
<cjwatson>     libx86 |   0.99-1.2 |        feisty | source
<iwj> But evidently I've been working from an old mirror.
<iwj> Still on average it's faster to risk spend 10 minutes duplicating some trivial change occasionally than it is to check in LP each time.
<cjwatson> aha, it got wedged somewhere in Launchpad :-(
<Keybuk> the publisher, etc. is on; right?
<iwj> Ug.
<cjwatson> I've resurrected it
<mjg59> cjwatson: Did you NMU to Debian or Ubuntu?
<cjwatson> mjg59: Debian, and synced
<mjg59> (Just briefly confused)
<mjg59> cjwatson: Cool
<cjwatson> it's OK, I've rescued the build
<Keybuk> build lost down the back of the sofa?
<cjwatson> down the back of the /srv/launchpad.net/builddmaster, yes
<cjwatson> mjg59: just usplash should link to it, yes? or libusplash.so as well?
<mjg59> Oh
<mjg59> Probably actually just libusplash
<cjwatson> except oh god I'm horribly confused
<cjwatson> perhaps it should go in usplash_BACKEND_LIBS since that's where svgalib is
<mjg59> Yes
<cjwatson> except that gets substituted into a make target list
<cjwatson> I'm going to look at this tomorrow instead
<iwj> cjwatson: Shall I assign that task of 83878 to you ?
<BenC> tfheen, cjwatson: https://wiki.ubuntu.com/MainInclusionReportdevice-tree-compiler
<cjwatson> iwj: yes please
<BenC> cjwatson: Will you have time tomorrow morning (my morning) to go over testing casper changes?
<cjwatson> Keybuk: yes, publisher is on - madison-lite works off publisher output
<cjwatson> BenC: how about now?
<BenC> cjwatson: Sure, but I'll just be cut-and-pasting while I'm doing this kernel upload :)
<BenC> I need device-tree-compiler in before uploading the kernel
<keescook> BenC: in all the flying bits this week, did you happen to add the 2 apparmor patches?
<cjwatson> BenC: ok, tomorrow morning will be doable
<BenC> keescook: I thought I had already...I'll get it in next upload
<keescook> BenC: oh! I didn't check for it.  :)  did you happen to figure out what happened to ASLR in the -6?
<BenC> keescook: I thought it might have something to do with vdso, but I haven't tested it
<BenC> keescook: I thought it might be caused by paravirt being enabled, but that's x86 only...shouldn't bother amd64
<BenC> So I'm at a loss
<keescook> what are the vsdo issues?
<kylem> sorry to jump into your conversation, do you have VDSO compat on?
<BenC> vdso was disabled in -6 because the vmware VMI paravirt patches required it...in -7 that isn't true anymore, but aslr test program still fails
<BenC> kylem: For now, yes
<BenC> that's a topic for feisty+1 specs
<keescook> vdso compat has been on prior to -6?
<BenC> we may need to leave it until after next LTS, unless we find that dapper binaries work without vdso compat
<BenC> vdso compat has been on since it's introduction
<elmo> I thought vdso compat was for some insanely old copy of glibc
<BenC> which predates dapper I think
<keescook> okay, so that's not it either.  hmpf
<BenC> elmo: pre 2.3.3
<BenC> I haven't checked how old that is
<keescook> that's pre-breezy
<elmo> yeah, that's hoary and older
<BenC> worried about third-party apps though...
<BenC> who knows what they use
<elmo> with their own libc?
<elmo> they deserver to lose :-P
<elmo> (granted, that's not actually a realistic attitude, but still)
<BenC> or static bins :)
<elmo> if they're static would the VDSO come into play?
<BenC> good point, probably not
<BenC> cjwatson, tfheen: Guess it helps if I save the wiki page for that MIR...done now
<lucas_> I was wondering... what's the status of the debian-maintainer-field field ?
<Burgwork> lucas_: in what sense?
<lucas_> well, it was a spec for edgy, but it's still far from being implemented
<tfheen> lucas_: as in, there are still packages without it, you mean?
<lucas_> the topic was raised again on #debian-devel, and I think that it would really be ridiculous to release feisty without fixing this
<lucas_> tfheen: yes, even for binary packages
<BenC> tfheen: Did you catch my upload and MIR?
<lucas_> src packages are even worse
<tfheen> lucas_: We don't change the source packages in the usual case.
<lucas_> tfheen: I meant for packages with ubuntuX
* pitti uploads new apport with apport-qt love (and a new icon from troy_s, yay!)
<tkamppeter> pitti, corrected foomatic-db is ready for upload (biff)
<pitti> tkamppeter: looking...
<pitti> tkamppeter: uploaded
<Mirv> people are wondering about broken amd64 kernel updates in both dapper and edgy
<Mirv> not broken as such, but uninstallable
<BenC> Mirv: uninstallable how?
<tfheen> Mirv: we're working on fixing it.
<BenC> Mirv: oh, you mean the linux-meta thing...known and being fixed
<Mirv> BenC: in edgy, for me, there are ... okay :)
<Mirv> btw, how did they pass testing?-)
<BenC> it's not a matter of existing things not passing...it's a matter of the archive not being fully in sync
<BenC> some packages are missing, and they are working on getting them installed into the -security archive so deps are satisfied
<tkamppeter> pitti, thanks.
<LaserJock> lucas_: binary packages are changed when rebuilt, source packages are being worked on
<BenC> tfheen: Is there anything else I need to do for device-tree-compiler?
<tfheen> BenC: no, I'll get it in, don't worry.
<BenC> tfheen: Just want to make sure you aren't blocking on me...take your time and thanks
<tfheen> BenC: I'm not, but it's 20:52 here now so I think I'm done for today. :-)
<BenC> tfheen: Ok, kernel and lrm are uploaded, but I build-dep's ppc on that package, so it'll sit till it gets through, no problems
<mdke> seb128: did the yelp upload have a problem? i didn't see it on -changes
<tfheen> BenC: cheers.
<BenC> tfheen: later
<seb128> mdke: no, I just had enough to do without it since yesterday, I'll do it later
<mdke> seb128: that's fine
<seb128> mdke: do you have an updated patch?
<seb128> mdke: let me know if you have idea for the system menu changes, the 4 items in a row are not ideal
<mdke> seb128: No, I haven't done an updated patch yet (I'll do it via a debdiff when you've uploaded). I'll give it a think about the menu
<seb128> mdke: ok, cool
<sistpoty> kylem: got my reply regarding revu? (sent 2 minutes ago)
<kylem> not yet
<sistpoty> kylem: strange... I got a "[...]  host cabal.ca [134.117.69.58] : 554[...] " is this some graylisting?
<kylem> probably
<tfheen> 554 isn't greylisting, 55x is a permanent failure.
<tfheen> 5xx, even
<sistpoty> hm... strange, cause I didn't get a delivery failed yet
<cjwatson> 554 is "transaction failed"
<sistpoty> exim even says Relay access denied
<cjwatson> if it's on opening the connection, it's "what, you expect me to speak SMTP? you fool" or words to that effect
<kylem> what address did you send it to?
<sistpoty> kylem: I just hit reply ;) 
<cjwatson> can also be "no valid recipients"
<kylem> oh.
<kylem> arg.
<kylem> can you bounce the reply to kyle@mcmartin.ca
<sistpoty> kylem: anyway, you can login to revu with kylem@debian.org
<kylem> i bet it's forgotten how to MX for my laptop
<kylem> ok
<sistpoty> kylem: and you can (hopefully) recover your pw if you don't enter any
<Keybuk> http://www.snpp.com/guides/chalkboard.openings.html
<Keybuk> oh, wow
<Keybuk> if that's not an eternal source of release code names, I don't know what is!
<_ion> :-)
<_ion> It's interesting how ASCII has corrupted punctuation, one of the episodes had -- instead of  in the chalkboard text. :-)
<Keybuk> You know that law which states programs are gases, they expand to fill the available space
<Keybuk> someone shouldn't have told the evolution authors
<lifeless> !!! hahaha
<Keybuk> scott     8115  0.1  8.5 531300 176244 ?       Sl   Feb05   4:14 evolution --com
<Keybuk> .5GB !L"KLWQKRQKORKOQIO)_)$"($)"!()$)"$(+")(
<_ion> Hehe.
<Keybuk> in second place is firefox, with 480MB
<Keybuk> third place is rhythmbox with 250MB
<ajmitch> how do you get them to be so small?
<Treenaks> firefox only 480M!?
<Treenaks> ajmitch: I run xmms because my playlist is too large for rhythmbox.. it's just too slow
<seb128> Treenaks: how many songs do you have?
<Keybuk> yikes. the maximum recommended spec for feisty+1 atm is something like AMD Athlon 64 3200+, GeForce 6150, 512MB ram, 250GB SATA, 16X DVD, etc.
<Treenaks> seb128: about 20k
<seb128> Treenaks: and it's slow with that? weird
<seb128> slow to start you mean?
<seb128> or to use?
<Treenaks> seb128: slow to start
<seb128> ah ok
<Treenaks> and searching for artists/albums is slow
<seb128> don't close it ;)
<seb128> mdke: 
<seb128> patching file data/scrollkeeper.xml
<seb128> patching file data/toc.xml.in
<seb128> patch: **** malformed patch at line 49: +    <_title>General Guides</_title>
<seb128> with your yelp patch
<mdke> seb128: is that without the previous ubuntu patch?
<seb128> mdke: it's trying to apply "updated patch" to the package
<mdke> seb128: did you drop the previous ubuntu patch as discussed on the bug?
<seb128> mdke: I did apt-get source, cd dir, patch -p1 < patch
<seb128> mdke: and it doesn't write that the patch doesn't apply
<seb128> it writes that the patch is malformed
<mdke> seb128: ok. AFAIK, from what DonS said on the patch, you have to drop the previous Ubuntu patch first
<mdke> he did the patch on a vanilla Yelp I think
<seb128> mdke: I didn't apply any patch
<seb128> mdke: <seb128> mdke: I did apt-get source, cd dir, patch -p1 < patch
<mdke> oh, I see
<seb128> mdke: I tried to apply with -p1 to upstream non patched
<mdke> hmm
<mdke> seb128: can you try the "Update" patch? That was the one DonS sent before I edited it (although I don't think my edit is relevant to that error)
<seb128> mdke: "Update" attachment works fine
<seb128> "Updated patch" is malformed
<mdke> ok phew
<mdke> that's my fault then :(
<mdke> sorry about that
<seb128> k, do you have any change I should do over DonS' patch?
<seb128> np
<mdke> no, that's fine. I'll do the changes later using cdbs-edit-patch, surely even i can't make a mistake with that
<seb128> ok
<mdke> seb128: maybe a separator before About Gnome in the System menu?
<seb128> yeah, a separator somewhere would be nice
<seb128> or maybe moving the apport item before the existing one?
<mdke> yeah, that would work for me too
<seb128> mdke: I've uploaded yelp with the patch, the "Common Questions" links are broken and some people will probably bug about that, would be nice to fix that for next update ;)
<mdke> oh yeah, that was in my edit
<mdke> seb128: I'll fix it as soon as it hits the archive
<seb128> ok, thank you
<seb128> I'll upload an update tomorrow
<seb128> no hurry
<mdke> seb128: ok
<mdke> seb128: can I get the source already from Launchpad do you know?
<Keybuk> "The high intensity blue LED installed silent 110mm fan inside the heatsink maximizes cooling performance."
<Keybuk> I so read that as the LED maximizes cooling performance
<seb128> mdke: no need to wait, get the previous source, drop the patch 06 and copy the one from DonS to debian/patches, you can cdbs-edit-patch it then
<lifeless> Keybuk: so did I
<mdke> seb128: I'll probably break that. I'll try that though, ok.
<Lure> Keybuk: lol
<seb128> mdke: why? just download the patch to debian/patches and use cdbs-edit-patch
<mdke> seb128: ok. I just copy don's patch over the existing 06 patch?
<seb128> mdke: for example
<mdke> ok, I'll give it a shot
<shawarma> Any members of ubuntu-archive around? I've (before UVF) subscribed ubuntu-archive to a sync request, but it hasn't been done yet. Since we're in UVF, I should get an OK from motu-uvf first before ubuntu-archive should be subscribed, right? 
<zul> tfheen: ping...mind pushing xen-meta though?
<siretart> kylem: I've just seen your request for being a reviewer on revu. just checking the database, and I see you already being an admin?
<sistpoty> siretart: sorry, I haven't sent reply-to-all
<kylem> sistpoty added me
<siretart> all right, no problem
#ubuntu-devel 2007-02-09
<xnix> is this where i should ask a feisty question?, wasnt sure if feisty questions were right for just #ubuntu
<xnix> since its dev/beta
<bdmurray>  #ubuntu is more appropriate
<HrdwrBoB> #ubuntu+1
<bddebian> Heya
<Burgundavia> anybody got an rsync script?
<jsgotangco> Burgundavia: hello Mr. Burger
<Burgundavia> hey jsgotangco
<jsgotangco> whats up bud
<wasabi_> http://wiki.freespire.org/index.php/Linspire_Canonical_Partnership_FAQ  <--- what's all that about?
<jsgotangco> linspire will now be basing on ubuntu and ubuntu users the option to use cnr or something like that
<wasabi_> Yeah, mostly I wnat to know about the 2)
<wasabi_> 2) Canonical will utilize Linspire's CNR technology for aspects of Ubuntu's software delivery system.
<LaserJock> sounds like some sort of CNR plugin or something
<wasabi_> Is CNR .deb files?
<LaserJock> I doubt it
<Burgundavia> wasabi_: no, cnr is a frontend to apt/dpkg
<wasabi_> Oh. So it's just the thirdpartyapt thing I built and never finished?
<Burgundavia> likely the default ubuntu install we be able to be pointed at cnr.com
<Burgundavia> well, I don't think so
<Burgundavia> I just hope it will not displace the existing methods
<LaserJock> it works for rpms too I think
<jsgotangco> yuck
<wasabi_> Oh, so it's Just Another Repos?
<Burgundavia> basically
<wasabi_> Useless.
<Burgundavia> plus it is going to be another frontend to the ubuntu repos, from what I understand
<wasabi_> We need ThirdPartyAPt. ;)
<Burgundavia> plus a massive QA nightmare
<wasabi_> great.
<jsgotangco> nice way to start up a big business hype
<wasabi_> http://wiki.ubuntu.com/ThirdPartyApt
<wasabi_> Sounds like the end of linspire to me.
<wasabi_> and no real change in ubuntu
<Burgundavia> basically linspire is dead
<Burgundavia> I would expect them to last about another year or so and then just become Ubuntu
<Burgundavia> much like MEPIS is now basically dead
<jsgotangco> one disc to rule them all
<wasabi_> Yeah. Looks like a way to save face.
<Burgundavia> as the Ubuntu beast consumes another distro
<wasabi_> Eh. Ubuntu is just better. That's what happens when people can't compete on merit.
<wasabi_> No reason to look at it negatively.
<bhale> yeah, i never bought into the theory that some day ubuntu itself would be eclipsed by a plethora of derived distros
<Burgundavia> and it looks like Canonical has solved the QA problem
<Burgundavia> which was the one thing that could kill us
<wasabi_> Looks like it's just we're "integrating concepts of CNR into our existing tools'
<wasabi_> Which is what would basically happen with or without cnr.
<Burgundavia> LP was supposed to gain CNR stuff at some point
<Burgundavia> nor CNR, but CNR-like
<bhale> the one thing that wouldve killed us is SLED being built on Debian or Ubuntu instead of SuSE
<bhale> too bad for them they have a stinker of a base
<Burgundavia> you think so?
<wasabi_> Heh. Yeah.
<bhale> yes
<Burgundavia> hmm, zmd...
<wasabi_> Suse has managed market penetration.
<wasabi_> Yeah. Directory stuff.
<bhale> zmd has nothing to do with directory
<wasabi_> zmd = zen something something?
<bhale> and its a key reason why sled is crap
<Burgundavia> no, zmd is part of their "stinker of a base"
<wasabi_> oh.
<bhale> its a daemon for package dependency resolution
<Burgundavia> zmd is part of their package system
<bhale> written in mono
<wasabi_> oh.
<Burgundavia> and it is crap
<bhale> think that over for a second
<jsgotangco> ohh
<bhale> and get back to me :)
<wasabi_> a) why a daemon
<Burgundavia> even the Novell guys disown it
<wasabi_> b) i don't care if it's mono.... except it's bigger and won't fit on small things.... but why a daemon?
<bhale> its always hung
<bhale> sometimes more fatally than others
<bhale> and surrounding ui is horrific
<Burgundavia> rpm has some nasty issues with killing dbs as well
<bhale> for all the wanking they will give you about their usability lab
<wasabi_> federico made a good pgo post about our software upgrade screen though. =0
<Burgundavia> like the famous one where Jeff Johnson told the person they were an idiot for trying to run it with a read only /usr
<bhale> "dude you totally missed the point, package menagement is not a real use case"
<bhale> ....ok dude
<Burgundavia> even Novell employees parents run Ubuntu
<Burgundavia> I loved that
<wasabi_> It's important that those things matter zero when it comes to the bottom line.
<wasabi_> RedHat and Novell have customers. Paying customers.
<Burgundavia> so does canonical
<wasabi_> Uh. Huh. What, 4?
<bhale> haha
<wasabi_> Don't take that the wrong way. I'm in this channel for a reason. ;)
<Burgundavia> they wouldn't have at least 4 or 5 paid support staff if they didn't have customers
<wasabi_> 4 or 5. Heh.
* Hobbsee wonders how much they actually talked ot the ubuntu devs before doing this.
<wasabi_> Hobbsee: Doesnt look like anything has been "done"
<Burgundavia> Hobbsee: before doing what? the cnr deal?
<Hobbsee> Burgundavia: yeah
<Burgundavia> I am certain at least mdz knew about it before it was signed
<bhale> linspire has been based on ubuntu for years
<bhale> they stole daniels X fu from warty
<Burgundavia> they have been borrowing bits for years
<Hobbsee> Burgundavia: true
<Burgundavia> back when we actually had an X worth talking about
<wasabi_> It's not called "stole"
<Burgundavia> funny how mark wanted a shiny X with no X maintainer
<bhale> i give it a slightly harsher term when said package was never meant to be released onto the world
<bhale> Burgundavia: what is wrong with our X?
<wasabi_> What ever happened to teh X auto config stuff?
<Burgundavia> bhale: it is old
<wasabi_> Like config-less?
<Burgundavia> we are lacking 7.2
<Burgundavia> 7.2 has about half the config-less stuff, 7.3 will have the rest
<wasabi_> Neato. ;)
<wasabi_> I want display hotplug.
<Burgundavia> that is 7.3
<bhale> 7.2 Release 
<bhale> December 11, 2006 
<Burgundavia> 7.2.1 will have input hotplug
<bhale> hm.
<ajmitch> and display hotplug requires driver support
<wasabi_> Specifically the ability to randomlly add a new local display, which is in fact a proxy to a remote display.
<Burgundavia> X guys haven't quite figured out the whole "releasing" bit
<Burgundavia> bhale: if you follow the Xorg mailing list, server 1.2, which is 7.2, has been released
<Burgundavia> I don't know what the final bits that are needed for the 7.2 release
<Hobbsee> tfheen: ping @ libmtp2?
<\sh> moins
<tepsipakki> I'll post a progress report about xorg-7.2 to u-d when I get to work
<tepsipakki> I've built all the libs up to mesa, which needs to be merged next :I
* tepsipakki grumbles why mesa doesn't use a patch-system
<pitti> Good morning
<tepsipakki> morning pitti
<pitti> hey Mr. X :)
<tepsipakki> heh :)
<tepsipakki> just before you joined I wrote about it
<tepsipakki> but more on u-d when I get to work ->
<tfheen> cjwatson: shouldn't the usplash task on 83878 be closed?
<TheMuso> cjwatson: You may be interested in this bug. https://launchpad.net/bugs/84139 it seems udev related, and I think you guys know more about udev than I do. :)
<Ubugtu> Malone bug 84139 in brltty "Arduino detected as braille device" [Undecided,Unconfirmed]  
<dholbach> good morning
* pitti raises his 'archive day' flag
<ajmitch> is that the one with a big target on it?
<pitti> workload-wise, yes :)
<LaserJock> pitti: so you aren't doing MIR approvals anymore?
<pitti> carlos: FYI, I'll release the dapper -base langpacks to -updates now
<carlos> pitti: cool
<pitti> LaserJock: I'll still do some today
<carlos> pitti: the database already has the right timestamp
<pitti> LaserJock: do you have a particular urgent one in mind?
<carlos> so once we finish with Feisty testing updates will be relative to that one
<pitti> carlos: I'll release the edgy-proposed ones to -updates as well, they got a fair amount of testing now
<LaserJock> pitti: I actually have about 15 for Edubuntu that I want to do, but the aren't ready :/
<pitti> 15? holy s***
<mdke> morning dholbach_ 
<LaserJock> pitti: do I need to do a separate MIR for each dep that needs promoted?
<dholbach_> hey mdke
<pitti> LaserJock: unless they are all alike, yes
<mdke> dholbach_: can you do an ubuntu-docs upload today? I'm just checking it builds ok
<pitti> LaserJock: doko had a special case yesterday: about 15 dict-$LANG source packages which looked all alike, just for different languages; for those one report was sufficient
<LaserJock> pitti: we have a 2nd cd now for Edubuntu
<dholbach> mdke: sure, give me a ping once you succeeded
<pitti> LaserJock: also, just to make sure, you know that MIRs are per source pacakge, not binary?
<LaserJock> right
<LaserJock> total I want to get like 20-30 in
<LaserJock> but I know I can't get it done for Feisty
<LaserJock> the problem is that a fair amount of the ones I want pull in 5+ in deps
<mdke> dholbach: ready to go :)
<dholbach> mdke: rock on
<LaserJock> pitti: what's the general feeling about packages that seem to be pretty bug free and secure, but aren't being actively maintained anymore?
<mdke> dholbach: do you know why ekiga depends on yelp? it's a bit weird that it's the only Gnome app that does that
<dholbach> mdke: ugh - I didn't know that - it probably shouldn't
<mdke> I opened a bug on it a while back, but didn't get a reply
<mdke> small fix I guess
<pitti> dholbach: does UVF apply to universe already, too?
<pitti> dholbach: i. e. what to do with universe sync requests that bring in new upstream versions?
<Fujitsu> Shouldn't syncs filed pre-UVF be exempt from the freeze?
<LaserJock> pitti: Universe UVF was same as Main, Universe FF was shifted to 22nd
<LaserJock> but it would be nice if stuff already in the queue got processed, IMO
<pitti> LaserJock: ok, so I'll set them to NEEDSINFO and wait for approval of who?
<pitti> LaserJock: ok, can do, it's not that many anyway
<ajmitch> pitti: approval will be by someone in motu-uvf
<pitti> ah, ok
<dholbach> mdke: done
<mdke> rock
<mdke> thanks dholbach 
<dholbach> mdke: i'll drop yelp as a depends in one of the next uploads
<mdke> for ekiga I hope, not ubuntu-docs :)
<dholbach> i'd be happy if somebody else updated ekiga :)
<dholbach> :)
<Sp4rKy> hi
<Sp4rKy> i need some information about gdm in the live
<Sp4rKy> when i start the live, gdm login me with the user "ubuntu" in the auto-login way
<Sp4rKy> but, in the squashfs, the etc/gdm/*conf set auto-login to false
<tfheen> Sp4rKy: look at the casper package.
<Sp4rKy> ok :)
<Sp4rKy> hmm, i don't find where casper set auto login
<tfheen> look in the scripts in /usr/share/initramfs-tools/scripts/casper-bottom
<Sp4rKy> hehe
<Sp4rKy> thx a lot :)
<Sp4rKy> is there some good doc about casper ? (other than man of course :p)
<cjwatson> tfheen: not unless it's been fixed. see the second paragraph of the description
<cjwatson> TheMuso: followed up to the bug, thanks
<tkamppeter> Is there any problem with the archives? pitti and doko have uploaded new foomatic-db and foomatic-db-hpijs packages and they did not appear on the server yet.
<pitti> tkamppeter: I'm just NEWing it as we speak
<tkamppeter> Can it be that the processing queue is very long due to the upcoming UVF?
<pitti> tkamppeter: I had 86 entries in NEW when I started, I'm down to 70
<pitti> tkamppeter: s/upcoming//
<tkamppeter> UVF and FF are active now? I do not see anything about that in the Topic.
<pitti> tkamppeter: https://wiki.ubuntu.com/FeistyReleaseSchedule
<pitti> tkamppeter: and it was mentioned several times in yesterday's meeting, too
* ..[topic/#ubuntu-devel:tfheen] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | FF + UVF in effect  | dapper/edgy-security kernels are uninstallable, we are working on it (https://5D5Dlaunchpad.net/bugs/83976)
<tkamppeter> Yes, I have seen, but the missing info in the topic made the impression to me that it got delayed.
<tfheen> tkamppeter: why on earth would it be delayed?
<tkamppeter> tfheen, thanks for updating the Topic.
<tfheen> especially given that I explicitly told people that it was in effect at the end of yesterday's meeting.
<cjwatson> tkamppeter: The major freezes don't get delayed. Sometimes (very rarely) the releases at the end of them get delayed slightly, but we don't delay the major freezes because (a) there's basically never a good reason to and (b) it just makes it more likely that the release at the end of them will slip
<Fujitsu> Am I to presume the 5D5D in front of launchpad.net in the URL in the topic was accidentally inserted?
<tfheen> and We Release On Time.
<Treenaks> tfheen: *cough*dapper*cough* ;)
* ..[topic/#ubuntu-devel:tfheen] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | FF + UVF in effect  | dapper/edgy-security kernels are uninstallable, we are working on it (https://launchpad.net/bugs/83976)
<tfheen> Treenaks: pft, that was delayed long before release.
<tfheen> Fujitsu: thanks, fixed.
<Treenaks> true
<Fujitsu> Treenaks, heheh.
<visit0r> hello, is this known (edgy upgrade fails as of today): Depends: linux-image-2.6.17-11-386 but it is not installable
<cjwatson> visit0r: /topic
<Fujitsu> Can't we delay Feisty by a couple of months on the day before the current release date?
<tfheen> Fujitsu: no.
<Fujitsu> Aw... How boring.
<cjwatson> Treenaks: obviously /me != sabdfl, but I don't think we'll do that again - the consequences were too painful
<Fujitsu> No excitement.
<Treenaks> cjwatson: yeah.. I've heard lots of people complain about Edgy..
<LaserJock> Fujitsu: maybe we should do it earlier :-)
<Treenaks> cjwatson: (especially compared to dapper's polishedness :))
<tfheen> Treenaks: edgy was a four-month cycle.  It was insanity.
<LaserJock> Fujitsu: like April 1
<Fujitsu> Edgy was shocking.
<Treenaks> tfheen: I know, I agree :)
<Fujitsu> LaserJock: Sounds good :P
<LaserJock> I vote for monthly snapshot releases ;-)
<Fujitsu> I wonder how things would have turned out if we had made Edgy and Feisty 5-month cycles.
<tfheen> LaserJock: we have bi- and thri-weekly ones.
<LaserJock> tfheen: well, I was thinking s/snapshot/stable/ but it's 2:00am here
<Fujitsu> So, LaserJock... written the 30 or so MIRs yet? :P
<LaserJock> ummm
<LaserJock> trying to figure out what has a chance of making it
<LaserJock> Fujitsu: something about 5 year old apps and unmantained packages ;-)
<Fujitsu> Which is/are in the former category?
<LaserJock> well, I found a cool "Learn Chinese" app called hanzim
<LaserJock> and then drgeo
<tkamppeter> Thanks cjwatson, much better organization than with Mandriva.
<cjwatson> you can only really do this if you start out being strict about time-based releases
<cjwatson> it's incredibly difficult to convert an established organisation to it
<cjwatson> GNOME did, but that's highly unusual
<tfheen> and it was a huge pain, AIUI.  At least at first.
<pitti> tepsipakki: just read your latest 7.2 reply, you rock :)
<seb128> Treenaks: to be honest edgy was not that good, feisty will probably be better
<tepsipakki> pitti: oh, thanks
<Fujitsu> seb128: I can't really see how Feisty couldn't be better. We've got a lot of QA time, and Edgy was terrible.
<tepsipakki> some of the drivers are syncable from unstable
<pitti> tepsipakki: if you can get a general X.org UVF exception from tfheen and the rest of the upgrade plan is settled and backed up by distro team leaders, we can do the syncs in a big batch; just send me a list
<tepsipakki> pitti: well, maybe they should be tested IRL as well :)
<pitti> tepsipakki: i. e. don't bother with filing 30 sync requests, if they either get completely denied or accepted
<tepsipakki> ah, right
<tepsipakki> mesa is the blocker now
<pitti> good luck!
<tepsipakki> without that I can't test xorg-server, which was a lot of work to put together
<tepsipakki> the mesa diff is like 1MB :I
<tepsipakki> sorry, 2.5MB
<Fujitsu> tepsipakki, sounds good, especially without a patch system.
<tepsipakki> yes
<tepsipakki> :)
<tepsipakki> it's tempting to make it use quilt
<tfheen> tepsipakki: have you talked with the Debian people about making it use quilt or something?
<tepsipakki> tfheen: not yet, I could do that
<tfheen> tepsipakki: I'd like to not end up using one patch system and they another.
<tepsipakki> it could just import the xsfbs-stuff from the x-packages
<tepsipakki> ok, I'll contact them to get moving
<pitti> carlos: would it be possible and reasonably easy for Rosetta to not include new languages into update tarballs?
<carlos> pitti: new languages since distrorelease?
<pitti> carlos: right
<carlos> pitti: new languages since distro release?
<carlos> hmmm
<pitti> carlos: right again :)
<carlos> I could figure a way to do it
<carlos> pitti: does it include -base package updates?
<pitti> carlos: I could filter them out on rookery as well, but it'd be pretty hackish
<pitti> carlos: yes; as soon as we release a distro, we don't want NEW language packs
<pitti> carlos: in fact, it particularly affects -base updates
<carlos> pitti: I wonder whether is not technically possible to add new languages...
<pitti> carlos: since langpack-o-matic already ignores new languages for the 'delta' updates
<pitti> carlos: it is technically possible, but NEW packagages in stable releases are generally frowned upon
<carlos> pitti: one of the idea of moving to belocales was to be able to add new languages quite easy, isn't it?
<pitti> carlos: well, maybe this should be discussed by TB
<carlos> TB?
<pitti> tech board
<carlos> oh, right
<tepsipakki> hmm, pkg-mesa-devel equals Marcelo Magallon
<carlos> ok, in the mean time, I will see how to add that feature
<pitti> carlos: don't bother if it's too complicated
<pitti> carlos: would just be nice
<carlos> It's just a matter of find the right query ;-)
<carlos> like, give me the list of languages that got all pofiles after X date
<carlos> pitti: could you file a bug asking for it?
<pitti> carlos: sure
<carlos> thanks
<pitti> carlos: bug 84167
<Ubugtu> Malone bug 84167 in rosetta "Please do not export new languages after distro release for langpack-o-matic" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84167
<carlos> pitti: thank you
<tfheen> ogra: if you're planning on shipping school* for feisty, you should work on getting them fixed and back into your seeds.
<Fujitsu> tfheen: That's really non-trivial, especially due to Zope 3 being inoperable :(
<tfheen> Fujitsu: that means it can't be shipped for feisty in which case demoting it sounds like a plan.
<ajmitch> Fujitsu: did you test out zope3 with a snapshot of the offending package?
<Fujitsu> Probably. It's uninstallable in Edgy as well.
<tepsipakki> oooh, mesa-6.5.2 _does_ have a patch-system.. and none other than quilt :)
<tepsipakki> glad I checked before sending the email
<tepsipakki> that version is in experimental, so I skipped it first
<pitti> tepsipakki: yay :)
<tepsipakki> that makes merging _so_ much easier
<pitti> tepsipakki: Debian is in freeze, so experimental is often what we actually want
<tepsipakki> yeah
<tepsipakki> there were also some drivers, like i810
<elkbuntu> ogra, ping?
<pitti> hi asac
<asac> hello
<Tonio_> seb128: I saw you removed my beagled fix for kde
<seb128> Tonio_: hi
<seb128> Tonio_: right, I removed your breakage :p
<Tonio_> seb128: we don't want to patch to get the same autostart than kde for a good reason
<seb128> Tonio_: what good reason? that's an xdg spec ...
<Tonio_> seb128: the breakage isn't due to the patch :) the current package also ftbfs
<seb128> and there is flags to use something only for KDE or GNOME
<Tonio_> seb128: yes but do you want people that sue both gnome and kde to have everything autostarting everytime they boot a DE ?
<seb128> Tonio_: oh, I didn't look to the build, shipping the autostart twice is the breakage
<Tonio_> seb128: yes but that means to patch 50 apps for us... ;)
<seb128> Tonio_: and?
<Tonio_> seb128: are you sure ?
<Tonio_> seb128: I tried to build locally before uploading and it worked ;)
<seb128> still doesn't mean that shipping and autostart to /etc and one to /usr is right
<seb128> what worked?
<seb128> GNOME does look to /etc/xdg/autostart and /usr/share/autostart
<Tonio_> seb128: my package :)
<seb128> I'm not sure to understand where you want to go
<seb128> I'm just saying that shipping a duplicate autostart is wrong
<bhale> i dont see why Tonio_ added back the kde autostart files
<pitti> Riddell: apport-qt is in the archive; I only tested it under gnome, and there are allegedly some UI bugs due to that; I'd appreciate some feedback about it
<bhale> to beagle
<bhale> does it not respect the ones beagle creates now?
<bhale> upstream
<Riddell> thanks pitti, I'll try and look at it today
<pitti> Riddell: ping me, then I'll walk you through
* Lure gets apport-qt ;-)
<Tonio_> Riddell: what should we do on that point concerning kde ?
<ajmitch> bhale: looks like there could be more issues with mono 1.2.3
<Tonio_> well concerning the build failed, that's not packaging issue, the previous package also fails now
<bhale> ajmitch: exciting
<Tonio_> seb128: but okay we have to define what to do on that point, I'll discuss this with Riddell
<seb128> Tonio_: ok
<Riddell> Tonio_: if putting it in /usr/share/autostart means it would start twice in gnome, that's not something we can really do
<tfheen> mjg59: is it on purpose that usplash-dev doesn't depend on usplash and that usplash ships the .so symlink?
<ajmitch> bhale: quite
<Tonio_> seb128: but I already know his feeling on that point as I already proposed to do what you want :)
<seb128> Tonio_: if you don't want to use /etc/xdg and need specific .desktop for KDE I suggest creating an /usr/share/kde/autostart or something like that
<mjg59> tfheen: Probably not
<Tonio_> seb128: riddell is right, I didn't know gnome looked at both.... that means 2 starts for you right ?
<Riddell> Tonio_, seb128: but it needs a gnome person to put lots of OnlyShowIn=GNOME; for their autostart files that we wouldn't want in other desktops (which is what I did for KDE)
<Riddell> unless they're already there?
<seb128> Tonio_: I've not tried if beagle is clever enough to run only one instance, but yes, GNOME looks to /etc/xdg/autostart and /usr/share/autostart
<seb128> Riddell: we don't have that many autostarts ;) 
<seb128> /etc/xdg/autostart/beagled.desktop:OnlyShowIn=GNOME;
<seb128> /etc/xdg/autostart/gnome-power-manager.desktop:OnlyShowIn=GNOME;XFCE;
<seb128> /etc/xdg/autostart/gnome-volume-manager.desktop:OnlyShowIn=GNOME;XFCE;
<seb128> /etc/xdg/autostart/nm-applet.desktop:OnlyShowIn=GNOME;
<seb128> /etc/xdg/autostart/update-notifier.desktop:OnlyShowIn=GNOME;XFCE;
<seb128> Riddell: and they use it
<Riddell> oh, perfect
<Riddell> then someone needs to look at patching KDE for the patch, /me bats eyelids at Tonio_ 
<Tonio_> seb128: then patching kde looks a good option, you're right
<Tonio_> Riddell: yup, will do that then :)
<Tonio_> seb128: sorry for the inconvenience, is I had known gnome lookedat both.... I wouldn't do that that way :)
<seb128> Tonio_: np, that was a quick change to do and revert and created no problem
<Tonio_> seb128: yup, did you let the change concerning beagle-settings ? the patch didn't apply without it ;)
<Tonio_> aka, bad file patched, need to patch the .in.in file
<seb128> Tonio_: hum, no, I just dropped the copy from debian/rules
<Tonio_> seb128: good, thanks, that's okay then ;)
<seb128> np
<tfheen> mjg59: 'k; would you mind if I made the soname of usplash actually be libusplash.so.0 and not libusplash.so too?
<jwendell> dholbach, good morning
<dholbach> hey jwendell - how's it going?
<mjg59> tfheen: Go for it
<jwendell> dholbach, fine
<jwendell> dholbach, can you help me?
<dholbach> jwendell: I can try
<tfheen> mjg59: cheers.
<jwendell> dholbach, in a debian build, where is defined $(DEB_BUILD_OPTIONS) ?
* Hobbsee waves to all
<jwendell> dholbach, i have found in rules file something like that:
<jwendell> ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
<jwendell>   confflags += --enable-debug
<jwendell> else
<jwendell>   confflags += --disable-debug
<dholbach> jwendell: you can set it as an environment variable
<jwendell> ah
<jwendell> dholbach, thanks
<dholbach> jwendell: noopt nostring nocheck debug  are values that I know of
<tfheen> s/nostring/nostrip/
<dholbach> lalala, yes :)
<tfheen> mjg59: also, what's up with the crazy version number?  Any reason to not just use 0.5, 0.6, etc?
<mjg59> The numbering is entirely arbitrary
<cjwatson> tfheen: I think usplash-dev shouldn't depend on usplash - build-deps shouldn't really pull in stuff that modifies the initramfs
<cjwatson> tfheen: if it were repackaged that way, it should be libusplash0, usplash, usplash-dev (or libusplash-dev)
<Tonio_> seb128: fyi https://launchpad.net/ubuntu/+source/beagle/0.2.16-0ubuntu3 ftbfs too...
<tfheen> cjwatson: hmm
<tfheen> cjwatson: I guess I could change that too
<jwendell> dholbach, i'm getting this error while running 'debuild' for the second time: any idea how to fix it?
<jwendell> Patch 031_x264_link_against_pic.diff does not remove cleanly (refresh it or enforce with -f)
<jwendell> make: ** [clean]  Erro 1
<jwendell> debuild: fatal error at line 1228:
<jwendell> fakeroot debian/rules clean failed
<bhale> Tonio_: seb128 this is a classic problem, novell releases new mono compilers without testing against any of their own apps
<bhale> Fix a syntax error in the OOo filter that only catches on Mono 1.2.3.  Fixes
<bhale> bgo #398303
<bhale> this is in svn
<bhale> i cant work on it atm
<dholbach> jwendell: can you put the package online somewhere so I can have a look?
<jwendell> dholbach, it's ffmpeg. I'm just rebuilding it with many codecs support
<jwendell> dholbach, i did an apt-get source, added some changelog entry, set env var $(DEB_BUILD_OPTIONS) and ran debuild
<jwendell> dholbach, in the first time it builds correctly, or if i run debuild -nc
<jwendell> dholbach, but just 'debuild' it fails on  debian/rules clean 
<dholbach> jwendell: maybe the clean target is broken if it builds the 1st time, but not the 2nd time
<dholbach> jwendell: I think that slomo and siretart know best about that package
<jwendell> dholbach, or there is something wrong with that patch in special...
<jwendell>  Patch 031_x264_link_against_pic.diff does not remove cleanly (refresh it or enforce with -f)
<dholbach> jwendell: I don't know the package - I'd need to download and check myself
<jwendell> dholbach, np, don't worry
<cjwatson> tfheen: change what?
<siretart> jwendell: look at it right now
<tfheen> cjwatson: make it into a proper library package.
<jwendell> siretart, what did you do?
<siretart> IIRC I applied a patch from jdong
<cjwatson> tfheen: ah, right
<cjwatson> tfheen: dunno whether it's worth it since themes don't link to libusplash anyway
<siretart> jwendell: I cannot reproduce your problem
<tfheen> cjwatson: true, but other pieces of software does, or could.
<tfheen> (casper, uswsusp)
<jwendell> siretart, before run debuild, i did this:
<jwendell> export DEB_BUILD_OPTIONS=risky
<jwendell> siretart, new package is on repository already?
<siretart> I'm talking about libx264-dev_0.cvs20070117-0ubuntu3
<siretart> jwendell: and that version doesn't check any DEB_BUILD_OPTIONs
<jwendell> siretart, i'm already using this package
<jwendell> siretart, i'm talking about ffmpeg
<siretart> jwendell: oh. I thought you were talking about x264
<jwendell> siretart, dholbach, according with changelog, jdong is the guy i need to talk:
<jwendell> Make DEB_BUILD_OPTIONS=risky enable more codecs (closes: Ubuntu #76354)
<siretart> jwendell: I'd guess so, yes
<dholbach> jwendell: good luck with that!
<jwendell> hehe
<siretart> he does irc from time to time..
<dholbach> pitti: nice apport icon :)
<Hobbsee> infinity: any plans to fix bug 24741?  it appears to be assigned to you
<Ubugtu> Malone bug 24741 in samba "samba account_policy_get fails on install" [Medium,Needs info]  https://launchpad.net/bugs/24741
<pitti> BenC: FYI, d-tree-compiler is out of binary new now
<tepsipakki> hmm, I wonder if the lesstif build-dep on mesa was dropped because lesstif is in universe?
<Riddell> mvo: did you get my e-mail about the packaging fix needed for kubuntu upgrade tool?
<mvo> Riddell: yes, I have a plan for this, I will answer in a bit
<Riddell> groovy
<Hobbsee> pitti: for sync requests filed before UVF - why are you marking these as needing a UVF exception?
<pitti> Hobbsee: because we are in UVF since yesterday
<Hobbsee> pitti: which is why i ack'd the basket sync last night (before your yesterday)
<Hobbsee> with still a few hours to go before the freeze
<pitti> well, but we cannot process syncs 24/7...
<Hobbsee> of course
<pitti> (queue was empty at Wednesday)
<Hobbsee> hence my question is "for those filed before the freeze date, shouldnt you be doing them, before UVF?"
<tfheen> Hobbsee: if we had infinite resources, we would.
<pitti> not really, AFAICS
<Hobbsee> seeing as there would be a fair few in the ~12 hours, or whatever it was, presumably
<pitti> Hobbsee: it only affected two or three syncs 
<Hobbsee> pitti: just one that i wanted :P
<pitti> Hobbsee: just get ack from motu-uvf :)
<Hobbsee> tfheen: of course.  hence the comment times
<tfheen> pitti: I'm not really fuzzed about sneaking them in under the wire for the ones filed yesterday, but your call.
<pitti> right, neither am I, I'm just strict about main packages
<Hobbsee> pitti: if they're as bad as the whole sru process, or anywhere near it, then it'll be feisty by the time it got into the archive
<pitti> Hobbsee: what was the one you need?
<Hobbsee> pitti: basket - it's a major kde app
* Hobbsee thinks 2.5 months for a SRU to get thru - and it's not even through yet, is just bloody rediculous.
<Hobbsee> and utterly unacceptable
<Riddell> Hobbsee: basket is universe, it can be approved by motu-sru team
<Hobbsee> </rant>
<tfheen> Hobbsee: I'm sure the universe-sru team accepts new members. :-)
<pitti> Hobbsee: I'm not talking about an SRU
<Hobbsee> tfheen: i'm not sure that it's the members that are the problem - it seems the process
<Hobbsee> pitti: i know.  i'm comparing, and not doing it well.
<pitti> Hobbsee: but motu-uvf -- i. e. just get their approval, that's quick
* Hobbsee wonders how many that requires.
<pitti>  /msg Hobbsee I'll sync it in 'oops' mode now, don't tell anyone
<Riddell> two
<Hobbsee> pitti: thanks mate :)
* Hobbsee hugs pitti 
<Hobbsee> Riddell: ahh
<sts> infinity: hey!
<sts> infinity: how is it going with mysql-server?
<cjwatson> pitti,Riddell: are the bits required to start up apport-qt in place yet?
<cjwatson> pitti,Riddell: I get a crash dump output here, but nothing responds to itt
<pitti> cjwatson: apport-qt is in the archive
<cjwatson> yeah, I've installed it already
<pitti> cjwatson: but calling it will be adept-notifier's job
<pitti> cjwatson: similar to update-notifier
<cjwatson> calling it does not seem to do anything
<pitti> cjwatson: thus, if you start /usr/share/apport/apport-qt, you should see the crash
<pitti> it's just this glue that is missing
<pitti> cjwatson: hm
<pitti> cjwatson: /usr/share/apport/apport-checkreports exits with 0?
<cjwatson> my crash was from ubiquity, so I need to run it with sudo, but even so
<cjwatson> exits 1
<pitti> cjwatson: hm, did you open it before calling apport-qt?
<pitti> if so, you need to touch it
<cjwatson> ah, ok, if I run it as root, it works
<pitti> ah, great
<cjwatson> is that necessary with apport-gtk? I didn't realise it ran with elevated permissions
<sts> infinity: ping?
<cjwatson> but I suppose it has to in order to get at crash dumps from stuff running as root
<pitti> cjwatson: yes, it is, otherwise you cannot access the reports
<pitti> right
<pitti> cjwatson: and making the reports world-readable potentially exposes sensitive information
<cjwatson> surely they are exposed by virtue of the fact that you can run apport on them :)
<cjwatson> exposed via Launchpad ...
<pitti> cjwatson: right, that's why we say 'if you did not do anything confidential, you can send a report' 
<pitti> although I'm fully aware that this is pretty weak
<pitti> the original solution to that was a crash db with restricted access
<cjwatson> I meant that some other user might have done something confidential but then you get to send a report and thereby find out what it was
<cjwatson> another option would be to attempt to store crash dumps with dropped privileges (via SUDO_UID) but I don't know whether that's possible
<pitti> cjwatson: you mean you get him to send it? right
<pitti> cjwatson: yes, it would, we can access the process' environment
<cjwatson> what I'm wondering is how ubiquity crash dumps get reported, really
<cjwatson> I know they do, I'm just wondering how :)
<cjwatson> does update-notifier run apport-gtk as root?
<pitti> cjwatson: gksudo doesn't ask for a password on the live system
<pitti> cjwatson: it does, through gksudo
<cjwatson> ok
<Riddell> pitti: so how do I run this thing?  /usr/share/apport/apport-qt just exits
<Riddell> do I have to crash something first?
<pitti> Riddell: yes, you have
<pitti> Riddell: 'bash', and then 'kill -SEGV $$'
<pitti> Riddell: or just kill -SEGV whatever else you want :)
<pitti> Riddell: alternatively, you can call it with '-f -p konqueror' to file a package bug
<pitti> Riddell: or with -f -P <pid> to file a bug for a running program
<pitti> Riddell: (--help)
<Riddell> pitti: that all seems to work except that the bug report doesn't have a body
<pitti> Riddell: 'body'?
<pitti> Riddell: btw, the UI is still missing a lot of the GTK one's functionality
<pitti> mainly due to the lack of an expander etc.
<Riddell> we use buttons
<Riddell> ooh, it works, it attaches all the files
<pitti> Riddell: right, that's the new magic
<pitti> Riddell: so, Michael will continue to work on it for the finer aspects, but I urged him to get it principally working for FF :)
<seb128> pitti: mvo?
<pitti> seb128: no, Michael Hofmann, a friend of mine
<seb128> ah ok
<seb128> pitti: your friends use KDE? no cookie for you :p
<pitti> seb128: no, he uses gnome
<seb128> ah
* seb128 hugs pitti then
<ogra> cjwatson, did anything in the metapackages change i'm not aware of ? my edubuntu-meta suddenly adds ubuntu1 to the version
<pitti> seb128: he just needs to program Qt/C++ at work
<Riddell> pitti: does the gtk one not catch crashes immediately or does it only wait on update-notifier to find them?
<pitti> seb128: and he just likes apport and my new abstract UI design, so he wanted to write a Qt port :)
<seb128> you rock ;)
* Riddell throws seb128 into the snow
<seb128> heh
<seb128> ok, fair enough :p
<seb128> and I like playing in the snow anyway ;)
<pitti> Riddell: update-notifier has an inotify watch on /var/crash; u-n then checks apport-checkreports if there are actually reports for the current user and if so, calls apport-gtk
<seb128> pitti: do you know if the new linux upload fixes apport?
<pitti> Riddell: or, if apport-checkreports --system is true, calls gksudo apport-gtk
<pitti> seb128: not sure, didn't try yet
<ogra> tfheen, i'd love to get school* in but that would mean i'd need to port it to the zope we ship. a task which apprently a multi headed upstream team did manage yet ...
<pitti> seb128: I saw the changelog for the size limit
<pitti> seb128: but not for the stdin flushing
<seb128> ok
<tfheen> ogra: ok, so you're fine with demoting them for now?
<seb128> pitti: if it doesn't I think we should turn apport off by some way until that's fixed
<ogra> tfheen, not before i discussed it with them ... do they break anything ? 
<pitti> seb128: right
<pitti> seb128: I newed new kernels and lrm, so they should actually be in the archive and testable now
<pitti> seb128: just no -meta yet
<seb128> ok, let me try
<tfheen> ogra: they clutter the uninstallability reports and if it's not installable, it's not supportable.
<pitti> seb128: can we both test them now?
<seb128> trying
<seb128> and mvo broke apt :p
<Riddell> pitti: sounds not too hard
<seb128> elmo: Problem with MergeList /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_feisty_main_i18n_Translation-fr
<seb128> elmo: sorry, autocompletion
<ogra> tfheen, right, but i dont want to spend days waiting for them to enter main again, please leave them in for now, i'll demote them completely if i know enough from upstream
<ogra> (oor get the fixed ones in)
<pitti> Riddell: right, and you can essentially use the existing u-n code
<pitti> Riddell: it's in a separate .c file
<pitti> Riddell: the thing we need to port is the tray icon, the rest should be fine
<pitti> Riddell: i. e.:
<pitti> Riddell: if notifier is running while a crash happens, it calls the apport UI immediately
<Keybuk> why does vim always write a file called 4913 into the working directory?
<pitti> Riddell: if the notifier starts and there are already pending crash reports, it just displays a tray icon
<pitti> Riddell: likewise for system crash reports, so that people do not unexpectedly get a gksudo slammed into their face
<tepsipakki> right, mesa wasn't that bad afterall
<pitti> Keybuk: not for me...
<Keybuk> pitti: strace it :p
<Keybuk> bet you it does
<kwwii> Keybuk: doesn't here either
<pitti> $ strace -o /tmp/x vim test.txt
<pitti> [ typing stuff] 
<pitti> [saving}
<pitti> $ grep 4913 /tmp/x
<pitti> $
<pitti> *shrug*
<pitti> Keybuk: grep -r the code for id -un == scott ?
<Keybuk> pitti: do it as root
<Keybuk> quest scott# grep 4913 /tmp/x
<Keybuk> lstat("4913", 0x7fffbda19470)           = -1 ENOENT (No such file or directory)
<Keybuk> open("4913", O_WRONLY|O_CREAT|O_EXCL, 0100644) = 4
<Keybuk> stat("4913", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
<Keybuk> unlink("4913")    
<pitti> Keybuk: nope
<mjg59> Keybuk: Can't reproduce here either
<mjg59> Got a vimrc anywhere?
<kwwii> lol, it is a vim virus
<pitti> Keybuk: it's not April 1 yet...
<Keybuk> pitti: how did you run it as root?
<Keybuk> ah
<Keybuk> the file has to already exist
<Keybuk> try echo > test.txt
<Keybuk> then strace -o /tmp/x vim test.txt
<Keybuk> (writing something into the file)
<mjg59> Keybuk: Nope
<seb128> $ grep 4913 /tmp/x
<seb128> lstat64("4913", 0xbfb4ea90)             = -1 ENOENT (No such file or directory)
<seb128> open("4913", O_WRONLY|O_CREAT|O_EXCL, 0100644) = 4
<seb128> stat64("4913", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
<seb128> unlink("4913")    
<seb128> 
<mjg59> Oh, hm.
<mjg59> Wait, I've got vim-tiny rather than vim
<seb128> does it on my feisty desktop
<Keybuk> I have vim-bloaty
<pitti> Keybuk: just sudo vim test.txt
<Keybuk> pitti: ?
<mjg59> Keybuk: vim-full?
<Keybuk> yeah
<mjg59> vim doesn't seem to do it either
<seb128> I've vim-tiny
<pitti> Keybuk: vim, vim-common, vim-gnome, vim-gui-common, vim-runtime, vim-tiny
<Keybuk> actually, just vim
<cjwatson> ogra: that was a semantic change in dch
<pitti> Keybuk: and I use the standard text vim (no gnome stuff)
<ogra> hmm
<Keybuk> ii  vim            7.0-035+1ubuntu5 Vi IMproved - enhanced vi editor
<Keybuk> ii  vim-common     7.0-035+1ubuntu5 Vi IMproved - Common files
<Keybuk> ii  vim-gnome      7.0-035+1ubuntu5 Vi IMproved - enhanced vi editor - with GNOM
<Keybuk> ii  vim-gui-common 7.0-035+1ubuntu5 Vi IMproved - Common GUI files
<Keybuk> ii  vim-runtime    7.0-035+1ubuntu5 Vi IMproved - Runtime files
<Keybuk> ii  vim-tiny       7.0-035+1ubuntu5 Vi IMproved - enhanced vi editor - compact v
<mjg59> No, I still can't reproduce it
<cjwatson> ogra: I think you should override it for now by hand to not use ubuntu1, and we can figure out how to deal with it properly lateer
<cjwatson> later
<Keybuk> quest scott% update-alternatives --display vim
<Keybuk> vim - status is auto.
<Keybuk>  link currently points to /usr/bin/vim.gnome
<Keybuk> /usr/bin/vim.basic - priority 30
<Keybuk> /usr/bin/vim.tiny - priority 10
<pitti> Keybuk: I have 7.0-164+1ubuntu3
<Keybuk> /usr/bin/vim.gnome - priority 40
<Keybuk> Current `best' version is /usr/bin/vim.gnome.
<ogra> cjwatson, ok
<mjg59> Maybe it's a vim-gnome thing, then?
<Keybuk> pitti: that does it for me too
<pitti> Keybuk: likewise
<seb128> vim -> /usr/bin/vim.gnome
<seb128> on my box
<pitti> Keybuk: vi -> vim.gnome
<pitti> Keybuk: much less likely, but I'm on amd64
<pitti> you and seb on i386?
<Keybuk> pitti: both my amd64 and i386 boxes do it
<Keybuk> as do both my edgy and feisty boxes
<seb128> I'm on i386
<Keybuk> src/fileio.c:3303 onwards
<Keybuk> it seems to be how vim decides whether it can write a backup copy
<pitti> hah
<pitti> Keybuk: why it doesn't just try? that's strange
<Keybuk> yeah
<Keybuk> and why doesn't it pick a frickin swap/temporary filename?
<Keybuk> Feb  9 13:47:30 wing-commander init: /etc/event.d/4913: unable to read: No such 
<Keybuk> file or directory
<Keybuk> is how I've been noticing it
<Keybuk> many people have seen that
<pitti> I wonder whether Bram used complex statistical methods to determine that 4913 was the least likely number ever for a file name :-P
<pitti> locate 4913 doesn't have any hits here, FWIW
<dholbach> does anybody else have problems with network-manager on wired machines?
<cjwatson> Keybuk: wow, that's crazy
<simira> dholbach: herd3? I'll check
<tfheen> dholbach: what kind of problem?
<dholbach> tfheen: it says "no wireless devices found", which is fine
<dholbach> tfheen: it just doesn't handle eth0
<tfheen> dholbach: and restarting it doesn't help?
<dholbach> tfheen: no :-/
<dholbach> sudo ifconfig eth0 up && sudo dhclient      works
<tfheen> dholbach: hmm.  Is this after a suspend/resume or just on boot?
<dholbach> no suspend/resume - it's my desktop machine
<dholbach> after boot
<dholbach> (after bringing up eth0 manually, nm still doesn't see it)
<tfheen> hmm
<simira> dholbach: ok, so testing on a laptop is not really useful
<ivoks> dholbach: b44?
<dholbach> i got this since I reboote with the new kernel - but I don't know how this could be related
<dholbach> ivoks: b44?
<ivoks> dholbach: broadcom ethernet?
<dholbach> ivoks: no - once it booted, I'll look up what chip it is
<ivoks> dholbach: this happend couple of times to me too, but i had to rmmod b44 and modprobe it again
<dholbach> ivoks: which kernel was that?
<ivoks> dholbach: dapper's
<dholbach> ah
<Riddell> pitti: apport-qt seems to work well apart from problems me and colin have reported, shall I add it to the seeds?
<pitti> Riddell: which problems in particular?
<pitti> Riddell: (apart from the missing adept-notifier glue, of course)
<Riddell> pitti: bug 84196 and bug 84202
<Ubugtu> Malone bug 84196 in apport "apport-qt crashes while processing crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84196
<Ubugtu> Malone bug 84202 in apport "qt restart button broken" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84202
<pitti> Riddell: ah, I see; thanks
<Keybuk> pitti: it does unlink it before it closes it
<elkbuntu> ogra, still around?
<cjwatson> Riddell: I just added apport-qt detection to ubiquity, but that isn't so good if adept_notifier hasn't been changed yet
<Keybuk> heh
<cjwatson> Riddell: should I back that out for now?
<Keybuk> you could have fun with vim
<Keybuk> create files called 4913, 5036, ...
<Riddell> cjwatson: yeah, for now, I doubt adept stuff will get in this week
<pitti> cjwatson: maybe yes, until we actually get that working
<Keybuk> following the loop at the end of the size of int, until no possible files exist
<Keybuk> then try and write a file
<Keybuk> vim will lock up in an infinite loop :p
<simira> pitti: where is apport-reports filed?
<pitti> simira: apport-reports?
<cjwatson> Riddell: ok
<pitti> Keybuk: I still don't get why vim doesn't just try to use <filename>.bak with O_CREAT|O_EXCL or so...
<pitti> Keybuk: ah, O_EXCL is not really portable, I figure
<Keybuk> I guess because there might be a backup already there
<dholbach> ivoks: skge
<ivoks> :/
<dholbach> the module was loaded, but it seems the kernel does not automatically enable it (???) - could that be?
* Keybuk wonders whether you can have 4,294,967,296 files in a single directory
<simira> pitti: apport is the thing that makes bug report out of crashes, right?
* dholbach reboots with the old kernel
<Keybuk> (it's also somewhat interesting that if you start at 4913, and add 123 each time, you exhaust the entire 32-bit integer number space before you reach 4913 again)
<pitti> simira: right
<simira> pitti: it closed, because it couldn't send the report to launchpad (I wasn't connected to The Internet), and now I want to find the report again...
<dholbach> hmmm, -6 works
<pitti> simira: ah; touch /var/crash/*
<simira> pitti: thanksalot!
<tepsipakki> hah, seems that Debian XSF is uploading xorg-7.2 to experimental since yesterday
<pitti> tepsipakki: are you in touch with them to avoid duplicate work?
<cjwatson> Keybuk: any odd number in place of 123 has that property, due to any odd number and 2^32 being relatively prime
<tepsipakki> pitti: I will be
<pitti> cool
<tepsipakki> most of the libraries seem to be uploaded to experimental already, but they were easy so no effort lost there
<jsgotangco> greetings earthlings
* Hobbsee is a GREEN ALIEN, THANKYOU!!!  YOU WILL ADDRESS ME AS SUCH!
<pitti> jsgotangco: Qapla'
<Hobbsee> ahem.  hey jsgotangco!
<jsgotangco> heh
<bddebian> Heya
<pitti> cjwatson: oh, do you already use pacakge hooks in ubiquity?
<pitti> cjwatson: I just noticed that I currently use /usr/share/apport as hook directory, but that is already taken by apport itself; I fixed bzr head to use /usr/share/apport/package-hooks/
<Keybuk> cjwatson: oh, of course
<zakame> pardon a dumb q, but do we have a working xen on feisty?  all I can find in the available docs are for edgy atm
<Nafallo> zakame: zul said no to me last evening
<zakame> Nafallo: ah... thanks
<zul> zakame: yeah we do...
<zakame> zul: er?
<Nafallo> zul: haha. I checked /lastlog xen in -kernel and you told me no :-P
* zakame is ignorant of it, except the Half-Life kind :)
<Amaranth> it's in universe, no?
<Amaranth> build-deps on the regular kernel source, patches it, and rolls a xen kernel, right?
<Nafallo> Amaranth: not to my understanding
* Nafallo lets zul answer :-)
<Amaranth> i thought that was the plan decided in november
<zul> zakame: the packages are in universe
<zul> its 2.6.19 though
<zul> ill write the instructions in the wiki tonight
<zakame> zul: rocking! :D
* zakame is on baby steps with it, at least knows someone to blame :P
<zul> meh..
<BenC> pitti: Thanks
<Nafallo> haha
<dholbach> tfheen, ivoks: it really seems to be a kernel problem - thanks for bearing with me
<tfheen> dholbach: oh, np.
<pitti> BenC: should the new kernel fix the stdin flushing for core dump? I didn't find that in the changelog?
<BenC> pitti: No, I need to build you a test kernel still...been fighting to get all of the kernels building with dtc and lrm and such
<BenC> soon as that passes, I'll get back to apport fixes for you
<pitti> BenC: ah, ok, just curious; thanks!
<pitti> seb128: ^ so maybe I should just disable core dumps for now?
<seb128> pitti: yes please do
<seb128> we are flooded of useless bugs for a week now
<BenC> cjwatson: whenever you get a few minutes, I'm ready for casper testing tips
<BenC> pitti: I need device-tree-compiler in main...I filed a MIR for it
<pitti> BenC: doing now
<BenC> pitti: Thanks!
<pitti> BenC: hm, it's not in the queue? nevermind, I'll add it
<pitti> BenC: promoted
<cjwatson> pitti: oh, ok, wanna change that in ubiquity when you're ready to upload the corresponding version of apport, and I'll upload it?
<cjwatson> pitti: I don't think Breaks or anything is necessary in this case
<pitti> cjwatson: I agree
<pitti> cjwatson: ah, you want me to do the change in ubiquity bzr? sure
<cjwatson> pitti: yeah, if you could
<pitti> cjwatson: I wanted to upload a new apport today to fix some bugs
<dholbach> tfheen: hum, maybe not a kernel problem :-/
<pitti> cjwatson: breaking that over the weekend is not terribly bad, WDYT?
<cjwatson> BenC: have two more phone calls this afternoon, starting shortly - maybe about an hour?
<cjwatson> pitti: I can upload tonight, it's not a problem
<pitti> ah, great; I'll commit the change
<cjwatson> there's nothing complex in ubiquity head
<lfittl> hmm, hard disk encryption using debian-installer or ubiquity will not be possible with feisty, right?
<pitti> $ bzr pull
<pitti> Using saved location: /media/root/home/cjwatson/src/ubuntu/ubiquity/kde-merge
<pitti> bah, bzr shuold be a bit more clever with this
* pitti can't quite remember which things are checkouts and which proper branches
<dholbach> tfheen: I reassigned the bug to nm: bug 84218
<Ubugtu> Malone bug 84218 in network-manager "skge eth0 does not get enabled automatically on boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84218
<dholbach> if there's anything I can do about it, let me know
<tfheen> dholbach: what does /etc/network/interfaces look like?
<dholbach> tfheen: it just has the 'lo' device
<dholbach> tfheen: it works with -6-generic
<dholbach> but I can attach it, if you like
<tfheen> dholbach: please.
<tfheen> dholbach: I'm tempted to say it's a kernel bug if it works with an older kernel
<pkl_> tfheen: we've had that discussion on #ubuntu-kernel :-)
<dholbach> tfheen: they say that if the device is shown by    ifconfig -a    the kernel has done its deed
<tfheen> dholbach: well, I guess.  This is after you have logged in or before?
<dholbach> it just doesn't get configured and the nm UI doesn't seem to know that eth0 exists
<pkl_> the device is being recognised, but, it is not being automatically configured.
<tfheen> hm
<tfheen> dholbach: please attach the relevant bit of daemon.log too
<dholbach> that's why I attached the  lshal  logs - maybe hal and the new kernel are not happy with each other
<tfheen> it's probably a race condition somewhere.
<dholbach> tfheen: dameon.log with the new kernel, right? or for both kernels?
<tfheen> at least the new would be good, thanks.
<dholbach> ok
<cjwatson> lfittl: certainly not with ubiquity; I don't think so for d-i, sorrry
<cjwatson> but I need to check the current state
<pitti> cjwatson: ubiquity apport change committed
<lfittl> cjwatson, ok, and what are the chances for feisty+1, at least debian-installer should be possible, as debian has that working already
<cjwatson> pitti: thanks
<cjwatson> lfittl: it needs cryptsetup to be brought to the point where we're happy with it in main, really
<cjwatson> lfittl: the last main inclusion attempt for it was rejected - see http://wiki.ubuntu.com/UbuntuMainInclusionQueue somewhere
<lfittl> cjwatson, ok, thanks
<dholbach> . o O { reboot-o-mania }
<BenC> cjwatson: Sure, just ping me when you get time
<dholbach> tfheen: done
<tfheen> cheers
<pitti> BenC: could you have a 5-second look at bug 83600? is it reasonable to fix this in the kernel itself?
<Ubugtu> Malone bug 83600 in linux-source-2.6.20 "Apport fails to pipe core dump" [Undecided,Confirmed]  https://launchpad.net/bugs/83600
<BenC> pitti: Checking...
<kylem> pitti, makes most sense to put it in the kernel.
<BenC> pitti: I think apport needs to check the sanity of the core stuff...I can work around it, but it just makes sense to me that apport assure it is running in a sane environment if possible
<pitti> BenC: i. e. apport's init script shuold just disable core_uses_pid?
<BenC> Yeah, but then you have to contend with when sysctl init script runs
<BenC> I suspect apport comes up after that
<BenC> At the same time, core_uses_pid doesn't make any sense for pipes
<pitti> right, that's why I'm asking you
<pitti> if some init script enables c_u_pid later, I can't do something about it
<BenC> but then neither does the % replacement, and the kernel still allows that with pipes
<BenC> pitti: I'll work around it be disabling it, and printing a one-time warning about it
<BenC> s/be/by/
<pitti> BenC: hm, s/disabling/ignoring it for pipes/?
<BenC> it will only print the warning first time it happens
<BenC> pitti: well, I wont change the sysctl value, I'll just ignore it for pattern expansion
<pitti> right
<pitti> BenC: great, thanks
* AlinuxOS salutes pitti ;)
<pitti> hey AlinuxOS 
<AlinuxOS> pitti, ;)
<Adri2000> tfheen: only "LP: #bug" will work for ClosingBugsFromChangelog?
<pitti> hm, I use 'Closes: LP#84196', but my .changes file doesn't have the magic Launchpad-.. line
<pitti> ah, LP: #123
<pitti> ah, works fine
<mantiena> hi all
<mantiena> pitti: hi, do you have some time to talk about gnome-mount backporting to edgy ?
<pitti> mantiena: TBH not right now, I'm in deep firefighting mode (see topic)
<mantiena> pitti: you are fixing edgy-security kernels problems ?
<pitti> mantiena: rather, beating them onto the mirrors
<mantiena> pitti: please, tell me when you will have time to talk
<pitti> hm, Monday next week? 0700 to 1830 UTC
<keescook> seb128: for gnome bug 378454, did Meeks just ask me to commit?  I'd need access for that.  :)
<Ubugtu> Gnome bug 378454 in general "crash to ORBit_handle_request function" [Critical,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=378454
<seb128> keescook: yeah, I can commit for you if you want
<pitti> hey keescook 
<keescook> seb128: sure yeah
<keescook> hiya pitti
<seb128> keescook: we can also try to get you a SVN account if you want
<keescook> seb128: sure, why not.  :)  I'm always up for more svn accounts.  :)
<siretart> seb128: I've read you are doing archive administration now as well? could you please give back gxine_0.5.11-1ubuntu2 on sparc?
<seb128> siretart: hi, I do archive admin (syncs, backports, NEW, ...), not buildd admin ... ;)
<siretart> seb128: oh. sorry then. whom to poke?
<seb128> np
<Adri2000> simira: Tollef
<cjwatson> siretart: a member of the launchpad-buildd-admins team
<Adri2000> sorry, siretart ^
<seb128> siretart: you can usually try to ping tfheen if he's around
<siretart> k
<ogra> seb128, is it a wanted fact that TimedLoginDelay in gdm isnt able to take values below 30 ?
<seb128> ogra: no, and that would be new, I used something like 8 seconds when I played with it some weeks ago and that was working
<ogra> hmm
<seb128> open a bug, I'll have a look later
<ogra> i have a kiosk setup for ltsp running here
<ogra> with 
<ogra> AutomaticLoginEnable=true
<ogra> AutomaticLogin=kiosk
<ogra> TimedLoginEnable=true
<ogra> TimedLogin=kiosk
<ogra> TimedLoginDelay=10
<mantiena> pitti: can you allocate few minutes for me today ?
<ogra> the initial login is fine, but killing the session, the second login always takes 30 secs
<pitti> mantiena: mail pls
<seb128> ogra: ah, ok, weird ... open a bug please so we keep track of it
<Adri2000> seb128: can you tell me where is my mozplugger upload? uploaded 15 min ago and still no accepted mail...
<seb128> Adri2000: what version was that?
<Adri2000> 1.7.3-6ubuntu2
<Adri2000> Successfully uploaded mozplugger_1.7.3-6ubuntu2_source.changes to upload.ubuntu.com.
<ogra> seb128, bug 84239
<Ubugtu> Malone bug 84239 in gdm "TimedLoginDelay seems to fail to take smaller values then 30" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84239
<ogra> eek ... 
* ogra hates his typos
<seb128> ogra: danke
<ogra> :)
<Adri2000> seb128: I've just received the mail
<seb128> Adri2000: ok, good
<kylem> pitti, ping? do i have to worry about this?
<kylem> Rejected:
<kylem> UploadError escaped upload.process: File linux-source-2.6.17_2.6.17.1-11.35.dsc
<kylem> as mentioned in the changes file was not found.
<pitti> kylem: no, you don't
<kylem> thanks.
<pitti> kylem: cprov and I have monkey-shoved the security updates through soyuz
<pitti> kylem: due to the bug mentioned in the topic
<kylem> ok.
<pitti> kylem: after breaking apt-get dist-upgrade in stables, it's high time to break people's kernels on a Friday evening
* pitti grins
* pitti sheds a tear and disables apport in this upload
<pochu> pitti: could you take a look at bug 84231?
<Ubugtu> Malone bug 84231 in apport "Feisty - Report problem have a problem" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84231
<pitti> pochu: that's a dup of bug 83974
<Ubugtu> Malone bug 83974 in apport "[feisty]  apport-gtk is opening a wrong URL" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83974
<pitti> pochu: really curious
<pochu> pitti: ok, marking it :)
<pochu> thaks
<pochu> thanks*
<pochu> pitti: this one says that he is using firefox 3
<pochu> pitti: maybe that is useful
<pitti> hm, might be
<pitti> pochu: but in the other bug the submitter uses the standard browser
<pochu> pitti: would be useful to launch apport from the terminal?
<pitti> pochu: not really, that's apport-gtk, and does not have debug output
<pochu> oh
<pitti> pochu: hm, I don't have the slightest idea about this, I'll add some debugging to the UI
<pochu> pitti: ok, do you think 2 reports are enough to confirm this? I say it because I can't reproduce it :)
<pitti> pochu: definitively enough; I can't reproduce it either, though
<pochu> ok
<ogra> seb128, is there a way to disable "fullscreen on f11" ? seems its not set in any metacity gconf keys
<pochu> pitti: medium or low?
<pochu> I think low :)
<pitti> pochu: hm, maybe there's something wrong with that guy's 'prefered applications' gconf keys?
* pitti asks
<pochu> pitti: maybe :)
<seb128> ogra: what app?
<ogra> seb128, firefox 
<pitti> pochu: I consider it high prio
<pochu> pitti: I'll ask them to try to reproduce this in a Feisty clean install
<pochu> pitti: ok
<ogra> i'm running: devilspie& metacity& firefox
<ogra> from .xsession
<pitti> pochu: this doesn't sound like deliberate breakage
<ogra> seb128, but it was there with ff and metacity alone as well .. looks hardcoded to me 
<pochu> pitti: maybe the gconf, as you said
<seb128> ogra: there is a "full screen" key to the keybindings capplet
<seb128> you can change it
<seb128> otherwise that's often a an accelerator for a menu item
<mantiena> pitti: to which your email address I should write about  backporting gnome-mount to edgy ?
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | FF + UVF in effect
<ogra> seb128, i know .... but its not set to f11
<mantiena> martin.pitt@ubuntu.com ?
<ogra> seb128, if i set it to "disabled" f11 still works
<seb128> ogra: firefox, view, full screen has F11 written
* pitti finally releases the Kernel USN From Hell
<seb128> ogra: then your app declare it as a menu accelerator
<ogra> seb128, aaaah , thanks !!!!
<seb128> for GNOME apps you can changes them
<seb128> for firefox dunno
<ogra> i didnt think about ff doing its own thing :)
<seb128> use epiphany :p
<ogra> well
<ogra> depends how many deps that pulls in
<ogra> its a kiosk setup for low level thin clients
<seb128> the epiphany remark was rather a joke, I know you try keeping depends low
<ogra> i would even go withut wm if ff would be able to get the screen geometry right
<seb128> anyway, blame firefox ;)
<ogra> yeah
<ogra> :)
<cjwatson> can't see anything for that in about:config, but asac might know
<ogra> i think you can set it somehow with a prefs.js setting ... not sure they are all in about:config
<ogra> there are some ff howtos for kiosk ...
<cjwatson> pitti: when should I upload that version of ubiquity?
<pitti> cjwatson: whenever you want, apport is uploaded
<cjwatson> pitti: you missed the symlinks, btw - fixing
<pitti> symlinks?
<pitti> cjwatson: hm, sorry
<cjwatson> pitti: are those still needed? I have symlinks for ubiquity-frontend-{gtk,kde}.py
<pitti> cjwatson: oh, indeed they are
<pitti> cjwatson: I'm terribly sorry, must have missed it in the grep
<cjwatson> no worries, easy to fix
<pitti> 'k, stables are happy again, gotta run now
<cjwatson> just thought I'd mention in case you need to change them in the future
<pitti> have a nice weekend everyone!
<pitti> cjwatson: right, will remember
<cjwatson> have fun
<pochu> bye pitti :)
<mantiena> pitti: bye
<mvo> cjwatson: do you know of a way to generate the multi-line description for a debconf note dynamically 
<mvo> cjwatson: ucf is (ab)using debconf to ask questions, but for displaying the diff it falls back to a terminal. that can be rather confusing when the gnome-debconf frontend is used. I was wondering if I could make it generate a note instead and show that
<cjwatson> mvo: yeah, see the documentation of the 'escape' capability in debconf-devel(7)
<seb128> tfheen: you forgot to make libusplash0 Replaces usplash
<cjwatson> hmm, I'm not convinced that pitti did actually upload apport_0.52
<seb128> cjwatson: feisty-changes had it mentioned already
<seb128> or you mean 0.52 is not 0.52 code actually?
<cjwatson> oh, ok, I'm just stupid then
<cjwatson> no, it's ok, I was just stupidly thinking that locate(1) output would be current, which is obviously not true
<seb128> k
<asac> ogra: only some key settings are available through prefs mechanism in ffox (if that is what you asked about) ... look http://www.mozilla.org/unix/customizing.html#keys
<ogra> asac, yep, already read that one ...
<asac> :)
<ogra> apparently i could tweak platformHTMLBindings.xml and add an empty keybinding for VK_F11 ...
<asac> don't know what your primary goal is :)
<ogra> disable f11
<asac> of course ... but why?
<ogra> for an kiosk mode
<ogra> in ltsp i install a minimal kiosk system thin clients can netboot ... 
<asac> now I get it :)
<ogra> it contains only the kernel, X, gdm metacity and firefox booting from a readonly nfs export and mounting allwriteable pieces to a tmpfs
<ogra> on boot t starts gdm and runs an autologin that executes ~/.xsession ... which contains metacity, devilspie and ff ... devilspie forces the ff wint to fullscreen now if a user presses f11 twice he gets into windowed mode
<asac> just curious ... only local mounts writable or remote ones too?
<ogra> only tmpfs mounts writeable
<ogra> i.e. the data is gone after reboot ...
<ogra> the kiosk accounts home dir for example is a tmpfs ...
<hile> fyi, 1st boot  with  cleaned up cryptsetup script (no lvm or evmps stuff) - the cleanup was really trivial anyway
<ogra> hile, did you csee the main inclusion report ? 
<mvo> cjwatson: rock!  that was the mising bit I needed!
<hile> still should clean up hook side, but  I didn't promise to do that ;)
* asac is out
<hile> og, yeah
<ogra> hile, feel free to abuse me as upload bith if you have a proper patch ...
<ogra> *upload bitch indeed
<cjwatson> mvo: you need Depends: debconf (>= 1.4.72)
<hile> ack
<hile> took me like 5min to do this cleanup, I've been just busy with studio stuff ;)
<mvo> cjwatson: thanks, updated
<ogra> heh
<hile> got a new mixer ... but that's quite off-topic ;)
<vdepizzol> Hello. I'm creating a ubuntu-Brazil website layout. Would it be useful for ubuntu.com? http://img174.imageshack.us/img174/1219/ubuntuhomejn0.png
<_ion> I thought ubuntu.com already had one. :-)
<sfllaw> tfheen: Bug 83818 and bug 84241 are getting lots of hits.  It looks like gnome-panel is crashing awfully often, and apport isn't getting useful info.
<Ubugtu> Malone bug 83818 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV" [Medium,Needs info]  https://launchpad.net/bugs/83818
<Ubugtu> Malone bug 84241 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84241
<tfheen> sfllaw: I'd guess it's the size limitation in the kernel hitting us; ask pitti about it.
<tepsipakki> XSF will upload xorg-server-1.2.0 to experimental later tonight :)
<sfllaw> tfheen: Still, it looks like gnome-panel got a lot of bugs filed against it recently...
<sfllaw> pitti: ^^^ ?
<tfheen> sfllaw: pitti's not here.
<mvo_> cjwatson: if you have a moment, could you please check http://librarian.launchpad.net/6383644/ucf_2.0017ubuntu1.debdiff for any potential problem? if it loosk good I will submit it to debian
<mvo_> other shell wizards are welcome to have a look too of course :)
<cjwatson> mvo_: | debconf-2.0 is unfortunately wrong now because cdebconf doesn't support the escape capability yet
<cjwatson> mvo_: the Description should be "Differences in ${FILE}" with an extra subst, or similar
<mvo_> cjwatson: I see. do you think this could be a major hurdle for accepting the patch? I would like to get it at lest into ubntu because the current way is not UI friendly
<mvo_> cjwatson: good point, I fix the ${FILE} thing now
<cjwatson> mvo_: you should unset the capb escape (db_capb, no arguments) when you're finished with it, and only bracket the db_subst with the db_capb change, not the whole thin
<cjwatson> g
<cjwatson> mvo_: does ucf use db_capb backup?
<cjwatson> because note that db_capb replaces the current client capability list, it doesn't add to it
<roico> hi... is universe freezed too? or packages can still be added there?
<cjwatson> mvo_: you definitely need to quote the $(...) in the db_subst command
<mvo_> cjwatson: db_capb is only called in my patch, nowhere else
<cjwatson> mvo_: ok, but the db_capb changes I suggested should be made anyway
<cjwatson> mvo_: don't use echo -e, that's a bashism and wrong here anyway; use printf %s "$DIFF" | debconf-escape -e
<cjwatson> otherwise you'll double-escape things
<Adri2000> roico: no, universe is not frozen, except for new upstream releases
<mvo_> thanks a lot! good that I asked you :)
* mvo_ goes and fixes the mentioned issues
<cjwatson> mvo_: you don't need to do fset seen false; reset does that for you
<cjwatson> mvo_: same quoting goes for all the DIFF=$(...), should be DIFF="$(...)"
<roico> Adri2000, what do you mean "new upstream releases"?
<Adri2000> new versions
<cjwatson> (basically, in shell, you should never type $ without putting quotes around it, unless you know that it's one of the cases where you shouldn't
<cjwatson> )
<cjwatson> mvo_: the error message if show_diff doesn't get passed an argument seems a bit wrong
<cjwatson> mvo_: the rest looks fine
<cjwatson> mvo_: I'd test with a diff that involves backslashes, tabs, and literal stuff like \\t\\\t\n\\n
<cjwatson> make sure it all gets preserved properly
<mvo_> *nod*
<mvo_> cjwatson: rock, thanks! that was a great help
<cjwatson> good luck, hope it works :)
<cjwatson> one of these days I'll fix base-passwd to use debconf, but that's harder because it needs to be more structured
<mvo> cjwatson: everything seems to work, I will will see if manoj likes the diff now :)
#ubuntu-devel 2007-02-10
<_ion> I posted a debdiff to bug #84284.
<Ubugtu> Malone bug 84284 in usplash "Fiesty: libusplash0 failed to unpack" [Undecided,Confirmed]  https://launchpad.net/bugs/84284
<pochu> fiesty :)
<pochu> let's make a fiesta :)
<zakame> ++pochu :)
<pochu> if anybody doesn't know... fiesta is party in spanish... so I love feisty...fiesty! :)
<Fujitsu> Aha, so it's a partyish, young deer.
<pochu> indeed ;)
<simple_x> Quisiera saber si existe alguna explicacin fcil para instalar en mi ubuntu el xgl y compiz en una tarjeta de vdeo Intel GMA 900
<bhale> simple_x: preguntas en espanol a #ubuntu-es
<FantasticFoo> sorry if this doesn't directly have to do with the development of feisty, but, i do have a programming-related question: if i have a newer version of a certain library installed in /usr, and an older version of a certain library in /usr/local, how do i compile a program from source against the old version in /usr/local ? apparently the configure script doesn't have any options specific to this library
<FantasticFoo> how do i edit the source to link to the proper lib
<Nafallo> FantasticFoo: #ubuntu question. sorry, this is not a supportchannel, as stated in the topic.
<FantasticFoo> oh ok, sorry. its just that its so active and its a hard question to answer, so my question gets shoved up on conversation out of side real fast
<FantasticFoo> site*
<FantasticFoo> well later dudes
* mpt wonders whether it would make sense to split #ubuntu into #ubuntu1, #ubuntu2, #ubuntu3, etc
<stdin> and have #ubuntu redirect to one of them?
<mpt> stdin, yes
<stdin> sounds like a good idea, it's often manic in there
<Chipzz> no imho
<Chipzz> what we need is not #ubuntu1, #ubuntu2 etc
<Chipzz> what we need is #ubuntu-newbie, #ubuntu-advanced
<mpt> that could work
<stdin> and what will be the default for xchat ?
<Chipzz> ubuntu-newbie, obviously
<Chipzz> an advanced user would *KNOW* how to join another channel
<stdin> hmm, yeah
<dholbach> good morning
<jenda> hello
<jenda> ho is in charge of the Examples directory for Feisty?
* tsmithe isn't acquanted with ho :P
<jenda> How can the Marketing Team infiltrate? :)
<jenda> *who
<tsmithe> *acquainted
<dholbach> jenda: if you file a bug on the package, heno and I will look at it
<jenda> dholbach: ok, cool, thx
<dholbach> jenda: (I merely did the packaging and uploading)
<jenda> is there a simple way of checking the current contents, withotu having to install feisty?
<dholbach> I doubt it changed from edgy to feisty
<dholbach> no, it didn't: https://launchpad.net/ubuntu/+source/example-content
<jenda> ok
<jenda> thx
<tepsipakki> sheesh, what to do with xbase-clients.. debian has a "traditional" package which bundles all of them together, whereas in ubuntu they are in separate packages and xbase-clients is a meta-packages which depends on them
<tepsipakki> -s
<Chipzz> tepsipakki: I'ld keep the seperate packages
<Chipzz> I like the seperate packages *a lot* :)
<tepsipakki> chipzz: do you have xbase-clients installed?-)
<slomo> BenC: is it a known problem that the via ide driver is broken, even with 2.6.20-7?
<tepsipakki> Chipzz: if you have ubuntu-desktop installed, you have xbase-clients as well via a dependency
<Chipzz> tepsipakki: I do not on one box, and I don't want it there either
<Chipzz> it's a mythtv box, custom install, and I definitely do not want all of xbase-clients installed there
<Chipzz> tepsipakki: also, having the possibility of having only xauth installed is a *MAJOR* blessing
<Chipzz> (xauth is necessary for ssh remote X)
<Chipzz> and no I don't have ubuntu-desktop installed on my desktop either
<Chipzz> since it depends on openoffice, it's the very first thing that gets nuked of my system after a fresh install
<Chipzz> (no I don't like openoffice one bit :P)
<tepsipakki> well, I don't know if it's worth the delta
<Chipzz> the ssh remote X case is a very strong case IMO
<Chipzz> and xbase-clients depends on a lot of stuff, half of which you'll never even use, and all of these dependencies pull in a lot of libraries
<Chipzz> so not having xbase-clients split up can really bloat your system
<tepsipakki> xbase-clients contains (quickly counting) over 70 packages, so maintaining them separately is a big pain in the arse
<tepsipakki> I wonder why it's ok for debian ;)
<Chipzz> I'll file a bug requesting a split if you merge it anyway :P
<tepsipakki> I don't have a say in this
<tepsipakki> since I'm not the maintainer :P
<tepsipakki> but the current split was done before debian had 7.0+
<tepsipakki> -+
<Chipzz> I can think of 2 reasons not to split it up: 1) it already is split up, the work is done, and the delta will be mostly in the control file anyway 2) most of the utilities in xbase-clients don't tend to change a lot anyway
<Chipzz> well some do, xrandr maybe
<Chipzz> point being, I suspect it's easier to apply the upstream diff than the debian diff
<tepsipakki> on 70 packages?
<Chipzz> heh?
<Chipzz> I'm not sure if all of these utilities are bundled upstream
<Chipzz> in case they are: you only have one diff
<Chipzz> in case the aren't: debian is doing something weird to upstream packaging anyway
<tepsipakki> they are separate, that's the point
<tepsipakki> debian bundles them together in xbase-clients
<Chipzz> then debian is doing something weird to package them all together in one package
<tepsipakki> so maintaining them separately would be pain
<tepsipakki> just like ubuntu is with xkbutils and xfonts-utils
<tepsipakki> nothing "weird" in it
<Chipzz> sure there is?
<tepsipakki> there is a bug report about splitting xauth from xbase-clients
<Chipzz> upstream ships seperate tarballs, debian builds one package from these seperate tarballs >> debian is doing something strange
<Chipzz> xauth is not the only package for which it makes sense to ship seperately
<Chipzz> from a quick glance at the list:
<tepsipakki> so you say we should split xkbutils, xfonts-utils..
<tepsipakki> anyway, maybe it could be worked out with XSF
<Chipzz> xdpyinfo, xhost, xinit, xrandr, xsetmode, xset, xmodmap, xdriinfo...
<Chipzz> especially xhost, xinit, xrandr, xset and xmodmap from that list
<tepsipakki> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151613
<Ubugtu> Debian bug 151613 in xbase-clients "xbase-clients: xauth (for ssh) should be its own package" [Important,Open]  
<Chipzz> anyway, why don't you mail the debian maintainer and ask if he thinks it makes sense to split it up?
<tepsipakki> well I think they know about that bug :)
<Chipzz> I meant debian syncing with ubuntu
<Chipzz> all the way
<tepsipakki> hah
<Chipzz> not just xauth
<tepsipakki> doesn't seem likely
<tepsipakki> I can ask, sure
<tepsipakki> maybe it will happen, post-etch
<Chipzz> the new X is in experimental anyway?
<tepsipakki> not all of it
<tepsipakki> yet
<tepsipakki> but the tricky parts yes
<tepsipakki> hah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199675
<Ubugtu> Debian bug 199675 in xbase-clients "Can desktop utilities be split off xbase-clients package?" [Wishlist,Open]  
<Chipzz> the one-big-xbase-clients thing may be a remnant of pre-modular-X anyway
<tepsipakki> for the record, I have nothing against having all those separate, but keeping the delta means more work
<tepsipakki> and it is true that most of them don't get updates that often
<Chipzz> I'ld say most of them are more frozen over than hell would be when gates releases windows as open source :P
<tepsipakki> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332521
<Ubugtu> Debian bug 332521 in xbase-clients "Split xbase-clients" [Wishlist,Open]  
<Chipzz> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332521#msg19 >> that's what I was referring to
<Ubugtu> Debian bug 332521 in xbase-clients "Split xbase-clients" [Wishlist,Open]  
<tepsipakki> yes, I see the point
<Chipzz> I totally agree
<Chipzz> that's just horrible
<Chipzz> I have another setup ("embedded" kind of thing) where I only install xset and xinit for example
<Chipzz> a setup with netbooting clients with / mounted on nfs
<tfheen> it's not like there's a significant overhead by having them all in one package, though
<tepsipakki> maybe I'll just update what we have now and don't bother with debian xbase-clients at all
<tepsipakki> and I'll ask them politely what their plans are
<Chipzz> tfheen: well, probably not for a desktop, but in a setup where you're building a system from scratch, yes
<tepsipakki> the suggestion in 332521 would mean that there would be six bundles, but it could be done with all separate and use meta-packages
<Chipzz> uhu
<Chipzz> xbase-clients doesn't make any sense at all but as a transitional package anyway
<Chipzz> and I don't see what possible good use xclock can serve on an ubuntu desktop
<tfheen> Chipzz: if you're so tight on space, you want to strip docs and such anyway, and then you have filtering and removing other bits then becomes trivial.
<Chipzz> except maybe for testing if remote X works
<Chipzz> tfheen: xbase-clients is 4.5MB, with 50MB dependencies
<Chipzz> for an embedded system, that is starting to be a big deal
<tfheen> *shrug*; use a custom package then.
<tfheen> in one sentence, you're talking about ubuntu desktops, in the next you're talking about embedded systems.  Our interest lies in the former, not the latter.
<tepsipakki> don't forget servers ;)
<tepsipakki> (sure, space constraints aren't usually an issue there)
<Chipzz> tfheen: maybe I'm seeing this wrong, but ubuntu is in your opinion not meant as base to build things on?
<tfheen> Chipzz: the reason why Ubuntu is successful is because it does not try to be everything to everybody.
<tfheen> So yes, it is a base to build things on, but it is not the best base for all kinds of systems, no.
<Chipzz> ok, I can agree with that. but does that mean that we have to make stuff harder on the people doing so for the mere sake of convenience in packaging?
<Chipzz> I think that's a really crappy reason to do so
* Chipzz afk for a bit - shower
<cjwatson> tepsipakki: yeah, please keep that particular delta for now
<cjwatson> I realise it's an awkwardness
<tepsipakki> it would be a mess to change now
* cjwatson resurrects a shedload of old buildd uploads
<cjwatson> should help with various random bits of uninstallabilityt
<cjwatson> -t
<cjwatson> notably it should make ubuntu-minimal (via aptitude) installable again on powerpc
<cjwatson> I suspect all the ones from November last year will have absolutely no effect because there seems to have been a mass give-back since then
<cjwatson> but never mind, might as well get them all analysed and out of the way
<cjwatson> worst case it's 3600-odd binary rejects that never get mailed to anyone :-)
<Keybuk> it's slightly scary when your ISP drops all pretense at being a customer-facing organisation
<Keybuk> and changes their website to talk about "managed solutions" "key customers" and "competencies"
<_ion> Heh
<_ion> Did they get bought?
<Keybuk> yeah
<Keybuk> a few years back, when I used to work for ISPs, the big thing was being bought my Telcos
<Keybuk> all the ISPs got bought out, and rebranded, etc.
<Keybuk> then it calmed down again
<Keybuk> now the big thing is getting bought my media groups, who offer everything from phone, to Internet, to TV, etc.
<Keybuk> Easynet (my ISP) was one of the biggest Telco/ISP combos
<Keybuk> and then it got bought by BSkyB
<Keybuk> so now it looks like they're positioning the Easynet brand as the business-facing one
<Keybuk> and using "Sky Broadband" as the customer-facing one
<null__> hello
<null__> the new kernel seems borken with intel wireless driver
<null__> cant connect any more 
<Hobbsee> null__: please see the /topic
<bddebian> Heya
<hile> siretart: sent a couple tiny patches for cryptsetup 
<hile> not really doing The Right Thing, but at least those seem to work ;)
<siretart> hile: yay. I've seen your emails. I see that I try them out in an qemu environment
<Draconicus> Howdy.
<Draconicus> I know this isn't supposed to be a support channel, but this is a channel that's not overrun with newbies and I have a question that's not exactly software-related anyway...
<Draconicus> Who can pass on a message to whoever manages Ubuntu support on IRC?
<Draconicus> Or better yet give me a name?
<Treenaks> Draconicus: have you checked the wiki? :)
<Draconicus> You're a funny man, Treenaks.
<Adri2000> I think he was serious
<crimsun> Draconicus: jono bacon is the "community dude"
<Draconicus> crimsun: Good to know.
<Draconicus> Man... sometimes I don't know who can be more pompous, the developers (no offense to the ones who aren't), or the support reps. XP
<Draconicus> Though it's a lot worse with some other distros.
<crimsun> are you implying that developers here should be offended?
<Draconicus> Not really... I dont' know anymore...
<Draconicus> GAH... OCD... Must resist.
<Draconicus> Take care.
<swampmallard> can anyone tell me what version of gcc is used to compile the Edgy Eft X libs?
<navbern> you could use 4.1
<navbern> you could use 4.1.x
<Amaranth> swampmallard: whatever one is installed by gcc?
<swampmallard> I'm asking because I'm trying to compile a meteorological simulation package in Edgy, and I'm getting linker errors related to libX11.a 
<swampmallard> I thought it might have been because libX11.a was compiled with a different version of gcc than what I'm using now.
<swampmallard> Thank you!
<BeBraw> has anyone noticed that blender (both 2.42a and cvs) has begun to kill window manager after launching it since gdm update?
<BeBraw> i am on edgy eft
<tepsipakki> Chipzz: http://lists.debian.org/debian-x/2007/02/msg01172.html
<jdong> BenC: ping
<jdong> BenC: I can confirm bug 82680 on my laptop too in feisty
<Ubugtu> Malone bug 82680 in linux-source-2.6.20 "[feisty]  regression: ti mmc card reader not working (worked flawlessly in edgy)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82680
<BeBraw> can someone confirm that recent ubuntu update (edgy) broke the fglrx driver?
<BeBraw> here's my crash log, http://pastebin.ca/349402
<tepsipakki> bebraw: you need to update your linux-restricted-modules as well
<BeBraw> ouchie. thanks for the hint :)
<tepsipakki> keep the metapackages installed
<BeBraw> hmm. according to synaptic restricted modules for 2.6.17.7-11.1 have been installed
<chris^> Hi
<chris^> I think the 2.6.17-11 Kernel is broken for W-Lan (Prism2) users... all prism2-notebooks I've updatet are broken (no wlan anymore)
<chris^> http://ubuntuforums.org/showthread.php?t=358085&highlight=wlan
<tepsipakki> BeBraw: well, it complains about missing module
<BeBraw> tepsipakki: the problems started after i installed the suggested updates given by ubuntu
<chris^> hmmm, I unloaded the prism2 modul, and loaded it againn
<chris^> it says it has found a device
<chris^> but there is no eth1...
<BeBraw> tepsipakki: thanks for help though. i think i will find a workaround for this sooner or later :)
<tepsipakki> BeBraw: have you tried #ubuntu?
<BeBraw> i shall do that
<mdke> chris^: did you file a bug?
<mdke> sounds important
<chris^> no
<chris^> where can i do that?
<torkel> chris^: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+filebug
<mdke> if it is a regression in a stable release, it might be worth posting to a mailing list too 
#ubuntu-devel 2007-02-11
<karim_> hi
<karim_> when I try to build xine-ui from source package I have no /usr/bin/xine binary. 
<HAL9003> hi guys
* Hobbsee waves
* mneptok rumbles ominously
<HAL9003> is there a list somewhere, how the runlevels are designed on ubuntu?
* Fujitsu puts up his umbrella.
<Hobbsee> no!  not more rain!
<tepsipakki> HAL9003: /etc/init.d/README
<HAL9003> that links to _Debian_ sources
<tepsipakki> so?
<HAL9003> so i need to ask debian people how ubuntu works?
<tepsipakki> that links to debian documentation, yes
<Chipzz> HAL9003: no, you need to bother reading the docs ;P
<Hobbsee> HAL9003: ubuntu is based on debian.  a lot of things work the same way
<tepsipakki> Chipzz: did you get the link I pasted here?
<Chipzz> tepsipakki: yeah I did
<Chipzz> bit of a shame IMO :/
<tepsipakki> how so?
<tepsipakki> X Window System Version 7.2.0
<tepsipakki> Release Date: 22 January 2007
<tepsipakki> X Protocol Version 11, Revision 0, Release 7.2
<tepsipakki> right on!
<Fujitsu> tepsipakki, is that the server starting?
<Hobbsee> tepsipakki: woo!!!
<tepsipakki> Fujitsu: yes
<Fujitsu> Wow!
<Fujitsu> Very good :D
<Fujitsu> How many of the X packages have you updated?
<tepsipakki> I don't have any driver-stuff yet, but rest
<Fujitsu> Still, not a bad effort thus far.
<tepsipakki> 157 packages
<tepsipakki> binaries
<tepsipakki> but some of them are straight from debian
<tepsipakki> hmm, hpssd still crashes here.. but it isn't xorg's fault
<tepsipakki> less than 50MB of debs
<holycow> allright so i can't be any help in the regular channel
<holycow> does ubuntu have a team testing the upgrade path between releases or between multiple releases?
<holycow> how is that handled?
<tepsipakki> ooh, I can run two glxgears instances on ati. the old one crashed
<Fujitsu> Upgrades are only supported from one release to the next, or between LTS versions.
<Fujitsu> And there is going to be some kind of testing of Edgy->Feisty, I believe.
<holycow> Fujitsu, they fail VERY badly between dapper and edgy it seems
<holycow> i haven't had a single successful dist-upgrade
* Hobbsee grrr
<Hobbsee> xserver locked up again
<tepsipakki> Hobbsee: feel like trying mine :)
<Hobbsee> tepsipakki: i'm thinking about it.  i'll check LP first though
<Hobbsee> tepsipakki: any plans to get that into feisty?  
<tepsipakki> Hobbsee: that's up to TB
<Fujitsu> tepsipakki: Did you read the logs of the last meeting? They said they'd like it if it gets packaged.
<tepsipakki> I don't have an official no/yes yet
<tepsipakki> Fujitsu: yes, I read that
<tepsipakki> it happens that Debian is packaging it right now as well :)
<tepsipakki> so that makes it faster
<tepsipakki> in fact xorg-server was in their git for a long time, but I didn't see it first
<mc44> holycow: see https://wiki.ubuntu.com/DistUpgradeProcessImprovements
<holycow> mc44, ah neat, so its a known issue
<Hobbsee> tepsipakki: may well be already there.  https://launchpad.net/ubuntu/+bugs?field.searchtext=screensaver+freeze&orderby=-date_last_updated&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Needs+Info&field.status%3Alist=Fix+Committed&field.assignee=&field.owner=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<mc44> holycow: yes
<phaidros> hi
<phaidros> is there an uptodate clamav (>= 0.9) as .deb around?
<Hobbsee> tepsipakki: https://launchpad.net/ubuntu/+source/xorg-server/+bug/60288 maybe - as a person doing xorg, does that patch make sense?
<Ubugtu> Malone bug 60288 in xorg-server "xorg segfaults in FontFileCompleteXLFD" [Undecided,Confirmed]  
<tepsipakki> great, need to bump epoch on libice, libsm, libxext, libxaw, libxi
<tepsipakki> those got "upgraded" on dist-upgrade
<Hobbsee> oh, it's fixed in 7.2, apparently
<tepsipakki> Hobbsee: I'm merely packaging it, not "doing" it :)
<tepsipakki> but tormod has been keen to see 7.2, so maybe it does make sense
<Hobbsee> tepsipakki: is it in a repo?
<Hobbsee> the 7.2?
<tepsipakki> I'll check
<sistpoty> phaidros: yes... apt-cache show clamav tells Version: 0.90~rc3-1ubuntu1 for feisty
<phaidros> thanx sistpoty 
<sistpoty> np
<phaidros> general: is it problematic to just use dapper+1 packages in dapper (feisty -> edgy) ?
<phaidros> meaning ubuntu+1 & ubuntu , snarf
<holycow> phaidros, expect it to be trouble
<Hobbsee> tepsipakki: the merged tsuff for feisty
<holycow> phaidros, generally it will try to pull in system library updates and you will end up with ahosed box
<phaidros> holycow, as long as there are no system library dependencies it should be okayish then, right?
<holycow> phaidros, what you want to be looking for is a  package compiled for dapper or compile and package it your self
<holycow> phaidros, i will hesitate to say yes but there are no guarantees
<tepsipakki> Hobbsee: yes, from that upstream bug you'll find a patch which is close to the one in the LP bug, and that is in 7.2
<sistpoty> phaidros: even than it might be troublesome, e.g. if maintainer scripts need s.th. newer...
<phaidros> hm, recommendation would be to grab clamav 0.9 deb.src from feisty and build in edgy .. 
<sistpoty> phaidros: yep
<Hobbsee> tepsipakki: cool.  now we just need it in the archives. i'll happily test - that screensaver bug is damned annoying, and i like my pretty screensaver
<Hobbsee> (which is why i usually use a blank screensaver)
<holycow> phaidros, actually yes thats best
<phaidros> so, then today is the day to learn how to rebuild .debs ;)
<Fujitsu> phaidros: You might want to check out the prevu package.
<_ion> Does anyone know what Keybuk uses for keeping the ChangeLog file updated in bzr? I presume it's a bzr plugin.
<Fujitsu> Ah.
<Fujitsu> But that's not in Edgy >_>
<phaidros> thanx anyway Fujitsu 
<phaidros> prevu sounds fine, somebody volounteering ?? ;) (just joking)
<phaidros> well, somebody might use prevu to backport prevu to edgy!
<phaidros> (sadly no feisty around here)
<sistpoty> phaidros: the easiest way is apt-get install build-essential, grab source-package (.dsc, .diff.gz, .orig.tar.gz) from packages.ubuntu.com, dpkg-sourc -x *dsc, install build dependencies (see debian/control) and make -f debian/rules binary, but learning how to build packages is quite offtopic here, #ubuntu-motu would be more suited
<phaidros> thanx sistpoty 
<holycow> how does this channel differ from the motu channel?
<Hobbsee> holycow: see /topic
<holycow> lol
<holycow> so
<holycow> how is this channel different from the motu channel?
<holycow> seriously, please don't point to the topic, its not helpfull at all beyond stating channel rules
<Hobbsee> ie, this is development discussion, that's how to start getting involved in development.  also, this == for the stuff in main, motu, for the stuff in universe
<holycow> so
<Hobbsee> you have no idea how many people dont read the topic, and ask for support in here.
<holycow> sure i do
<Fujitsu> No
<Fujitsu> You don't.
<holycow> i also understand why the topic is that way
<Fujitsu> Gah.
<Fujitsu> Stupid enter key.
<holycow> i assumed motus were devels and would be rolled in here
<Hobbsee> holycow: differnet people focus on main and universe
<holycow> what do devels here focus on ?
<Hobbsee> main stuff
<Fujitsu> holycow: main and restricted.
<holycow> ah
* Hobbsee wonders who would upload an xorg bugfix....
<Fujitsu> (well, main is the focus)
<Hobbsee> seeing as there's no maintainer, per se
<tepsipakki> uh, 3:37AM.. time for a quick nap ->
<holycow> Fujitsu, actually i probably have a very good idea of how many support requests you guys get here ... i get banned from #ubuntu a lot
<holycow> lol
<Hobbsee> tepsipakki: darn!
<Hobbsee> wow, lots of dupes on this
<holycow> Hobbsee, just out of curiosity, what issue? for edgy?
<Hobbsee> holycow: https://launchpad.net/ubuntu/+source/xorg-server/+bug/60288
<Ubugtu> Malone bug 60288 in xorg-server "xorg segfaults in FontFileCompleteXLFD" [High,Confirmed]  
<Hobbsee> holycow: both edgy and feisty
<tepsipakki> Hobbsee: forgot to tell, that upstream doesn't have that patch as-is, I didn't check the git
<holycow> oh weird, okay thanks
<tepsipakki> but now ->
<Hobbsee> tepsipakki: right....
<Hobbsee> tepsipakki: right, that bug now has 6 dupes.
* Hobbsee contemplates rebuilding X with that patch.
<Hobbsee> bah.  how long can it take?  it's xorg-server
<Hobbsee> and i'll do the proper patch in the process
<LongPointyStick> building....
<geser> Hobbsee: the last time xorg-server took 20 min to be build on the buildds
<jdub> hmm
<jdub> upgrading python and python-minimal, apt-get clocks 100%
<jdub> trying again; last time it didn't finish :)
<jdub> hrm
<jdub> and no strace output
<jdub> hrm
<jcole> sudo update-python-modules
<jdub> no, just did an install of python/python-minimal and it was fine
<jdub> whereas the upgrade was wedged
<jcole> everytime python i updated/upgrade update-python-modules is called (i think) which can spike the cpu
<jcole> is*
<jdub> on install, it took no time; on upgrade, it wedges
<jdub> ah, it's wedged after failing to get postfix
<jdub> ahr, --fix-missing
<jdub> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/84476
<Ubugtu> Malone bug 84476 in apt "Wedged at 100% cpu with --fix-missing" [Undecided,Unconfirmed]  
<Hobbsee> geser: not bad.  it appears to fail to build though, no idea why
<nemo_home> 'scuse me. I was wondering if you guys could push out a quick and easy fix. My mom's recent update of her ubuntu broke her wireless due to kernel rename causing wrong tool to be invoked in modprobe.d 
<nemo_home> was concatenating `uname -r`
<nemo_home> ln -s /sbin/ipw3945d-2.6.17-10-generic /sbin/ipw3945d-2.6.17-10-386  fixes, but I was hoping for something "official"
<shackan__> file a bug on the "official" bugzilla
<nemo_home> shoot. was hoping for something broken by an update that you guys could push out a quick fix. not to whine too much in a dev channel, but usual bug cycle takes a while and catching this before others reboot and can't pull down the fix would be nice.
<nemo_home> fixing my mom's from 3000 miles away by phone was... unpleasant...
<shackan__> which is why linux will never catch up on the desktop
<nemo_home> ?
<Burgundavia> nemo_home: if there has been a regression, it is a pretty serious matter
<Burgundavia> please file a bug and make certain it is tagged as such
<Hobbsee> tepsipakki: patch seems to work
<Hobbsee> tepsipakki: hasnt killed X, anyway
<nemo_home> Burgundavia: fine. hope it doesn't take too long.  *registers*
<Burgundavia> nemo_home: testing it to make certain it doesn't break anything further will take time
<Burgundavia> shackan__: less than helpful statements are not really needed
<Burgundavia> please refrain from making them in the future
<nemo_home> Burgundavia: meh. breaking internet is about the worst thing that can break :) makes further fixes difficult.
<keescook> nemo_home: sounds like bug 84372
<Ubugtu> Malone bug 84372 in linux-source-2.6.17 "ipw3945 not working with 2.6.17-11-generic" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84372
<nemo_home> ah-hah
<keescook> can you comment on that with your "ln -s" fix?
<nemo_home> hm. I'm not sure that is the bug, actually
<keescook> ah, hmpf
<nemo_home> the date is correct though, so doublechecking now that I can actually connect to her machine through ssh again
<Hobbsee> hey keescook 
<Hobbsee> keescook: who's best to bug about getting an X patch in?
<keescook> hiya Hobbsee :)
<shackan__> Burgundavia, sorry, just a personal opinion (not appropriate for -devel, I know)
<keescook> Hobbsee: hmmm, dunno.  is there a bug for it?
<Hobbsee> keescook: yeah.  bug 60288
<Ubugtu> Malone bug 60288 in xorg-server "xorg segfaults in FontFileCompleteXLFD" [High,Confirmed]  https://launchpad.net/bugs/60288
<keescook> I'm not sure where things stand, given the possible 7.2 integration, etc
<nemo_home> keescook: possibly related - since uname -r is used, I imagine any change of name would do it. in my mom's case is 2.6.17-10-386  - maybe he's on 2.6.17-11-generic
<keescook> nemo_home: yeah, that part confused me.  :)
<Hobbsee> keescook: do you think it's possible to get this in before they decide on 7.2?  it's making my machine crash at least once a day, and it's doing the same to all the other people with this bug.  the patch has been committed into 7.2
<keescook> Hobbsee: yeah, probably.  Looking at the patch now
<Hobbsee> keescook: thanks
<nemo_home> keescook: other difference is that on her machine she told me, in debugging, that the device didn't even show up under ifconfig -a
<nemo_home> anyway. will file a new one and hope others don't get hit with this
<keescook> nemo_home: ah, okay.  yeah, I'm not sure; I can't reproduce since I don't have that hardware.  :(
<keescook> cool, thanks
<Hobbsee> keescook: i can be cooerced to reproduce that
* Hobbsee does have that wifi card
<Hobbsee> keescook: possible SRU candidate, if nothing else.
<keescook> Hobbsee: yeah, totally.  I agree, though: get it tested now.  :)
<keescook> so, what does it take to spark the crash?
<Hobbsee> keescook: dunno - you'd have to check the backtraces.  run a opengl screensaver, and it'll happen randomly - machine just hardlocks
<keescook> icky.  yeah, I guess I'm missing all the fun by just using screen blanking.  :)
<Hobbsee> come ot think of it, i wonder if this fixes my X crashes for games like scorched3d (reproducable always), ppracer, and tuxkart (sometimes)
<Hobbsee> keescook: yep.  the opengl screensavers are pretty!  :P
<Hobbsee> what's that ln -s for the wifi card fix?
<keescook> (ick, I don't like these LVM updates... I'm getting floods of warnings while manipulating my LV chroots...)
<nemo_home> Hobbsee: I just symlinked so that modprobe.d would pick up the right name
<Hobbsee> nemo_home: got the full symlink?
<nemo_home> Hobbsee: ln -s /sbin/ipw3945d-2.6.17-10-generic /sbin/ipw3945d-2.6.17-10-386
* Hobbsee reboots to test
<nemo_home> Hobbsee: heh, you'll probably beat the reg mail through my greylist
<nemo_home> (forgot to whitelist)
* Hobbsee is back
<nemo_home> and?
<Hobbsee> gotta upgrade edgy first...
<nemo_home> kinda new to this ubuntu thing. edgy is "stable" right?
<Hobbsee> yes
<Hobbsee> getting 269mb archives - ouch!
<TheMuso> Hobbsee: Lovely/.
<keescook> okay... lvm is seriously trashed.  this is now getting in my way.  :P  gah
<Hobbsee> TheMuso: yep :(
<keescook> Hobbsee: got the patch running through a build now.  :)
<Burgundavia> keescook: how do I get a dapper regression dealt with? it is a cupsys one
<Burgundavia> https://bugs.launchpad.net/cupsys/+bug/55828
<Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Medium,In progress]  
<keescook> Burgundavia: not sure, maybe email pitti?
<Hobbsee> keescook: yay!  so it's building?
<Hobbsee> keescook: ie, going into the archives?
<keescook> Hobbsee: locally, yeah.  I'll test it quickly and then upload to LP
<Hobbsee> keescook: right.  it works, i just tried :P
<keescook> Hobbsee: yup, I trust your build.  I just don't trust mine yet.  ;)
<Hobbsee> keescook: :)
<Hobbsee> keescook: you can come and @lart me at the next UDS or something if it doesnt work.
<Hobbsee> or lca, if i'm there
<keescook> hehe  :)
<Hobbsee> :P
<keescook> will you be at the next UDS?
* keescook falls asleep waiting for xorg build
<Hobbsee> keescook: hope to be.
<Hobbsee> keescook: i've got my passport application mostly filled out for it :P
<keescook> Burgundavia: looks like pitti just needs to drive that SRU (everything in that bug looks to be in good shape)
<Burgundavia> keescook: yep, but the SRU has been needed to be driven since october
<keescook> Burgundavia: yeah.  :(  I'm not sure what the right "escalation" method is for SRUs.
<Hobbsee> Burgundavia: heh.  so by the time it's done, feisty will be released!
<Hobbsee> keescook: poking the relevant parties until they give in tends to work
<Hobbsee> ahem, did i say that?
<keescook> heh
<Burgundavia> Hobbsee: this is the third poke on the bug
<Hobbsee> Burgundavia: add some DOOM!!!! behind it, too.
<Burgundavia> frustrated, as it is holding back the complete conversion of my office to Ubuntu
<keescook> Burgundavia: you might ask sfllaw too.  I know it needs to be uploaded to -proposed first, etc
* Hobbsee calculates that the SRU's done now, and any time after now, probably wont make it into edgy before feisty is released, at current standards....
<Burgundavia> yep
<Burgundavia> sfllaw: ping, re bug https://bugs.launchpad.net/cupsys/+bug/55828
<Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Medium,In progress]  
<Burgundavia> Hobbsee: that is a dapper bug, not an edgy one
<Hobbsee> Burgundavia: i realise that.
<Burgundavia> if it was an edgy one, I wouldn't care as much, but dapper is supposed to be "long term" and all that jazz, hence why i run it in my office
<LaserJock> I've got a few more edgy SRU's to do
<Hobbsee> Burgundavia: makes it even harder i guess, as most of the devs wont even have a partition of it
<Hobbsee> yeah
<keescook> I've got 'em all!
<LaserJock> they're a pain in the butt though
<Burgundavia> I can see community members not running dapper
<Burgundavia> paid employees are paid to keep those dapper partitions around
<Burgundavia> although the Ubuntu QA is a million times better than Userful's...
<LaserJock> heh
<Burgundavia> thanks to rocking people like keescook and sfllaw
<keescook> :)
<keescook> Burgundavia: one other idea is to get the debdiff updated for the new-style SRU (using -proposed).  I'll do that while waiting for xorg to finish compiling.  :)
<Hobbsee> keescook: should only take ~20 mins
* Hobbsee reboots
<Burgundavia> LaserJock: here is a nice sob story. Our company president bought the entire Victoria office 19" widescreen laptops
<Burgundavia> sounds great, right?
<Burgundavia> except for one little bug: desktop-multiplier hardcodes 1024x768 into X
<LaserJock> doh
<Burgundavia> I figured out how to hack it to get support 800x600 and 1280x1024, but not widescreen resolutions
<jdong> whoa! feisty  ssh has kerberos support!
<jdong> who do I need to hug for that?
<jdong> that was a pleasant surprise... ssh'ing to linux.mit.edu and having it automagically log in :)
<Hobbsee> keescook: nemo_home i cant reproduce that at all
<Hobbsee> Burgundavia: 915resolution, by any chance?
<StevenK> jdong: Russ Allbery, it's a Debian change that we got when cjwatson merged in 1:4.3p2-7
<jdong> whee!
<jdong> russ, thank you, I hope this message psychically gets to you
<Burgundavia> Hobbsee: no, this is X hardcoding it. We use radeon 7000 or 9250 in all of our computers
<Hobbsee> Burgundavia: ahh.  fun
<jdong> now I shall upgrade the entire EECS lab to Feisty
<jdong> ;-)
<Burgundavia> Hobbsee: unlike most hacks, I have absolutely no idea why we did it
<Hobbsee> nemo_home: does that only occur with teh generic kernel?
* keescook restarts xorg
* Hobbsee wonders if it's just activated the off switch of the card or something
<Hobbsee> to not show up in lsmod would be odd
<Hobbsee> keescook: did it work?
<keescook> Hobbsee: yawp, xorg works.  :)
<Hobbsee> keescook: yay!
<keescook> and I'm still hardware accelerated.  whee.  uploading...
<Hobbsee> :)
<Hobbsee> keescook: those affected will be very appreciative
<Hobbsee> assuming they're using feisty, of course
<keescook> hiya asac
<nemo_home> Hobbsee: hey. sorry. didn't realise it would take you so little time to update. was taking opportunity of restored connection to update stuff on her machine.
<Hobbsee> nemo_home: ahhh
<nemo_home> Hobbsee: all she did, and I paraphrase, was to follow the prompt asking her to reboot her computer. I imagine that it was a scheduled kernel update in stable. after this update her internet didn't work.  I eventually got it running by trial and error and getting her to run the above command with -generic.  I then used the restored connection to note that her kernel name had changed
<Hobbsee> nemo_home: odd.  i dont know why.
<Hobbsee> it all works fine here, with the kernel update - card flashes, networkmanager finds the card.  it's obviously happening only for some people.
<nemo_home> Hobbsee: after update what does uname -r  return for you?
<Hobbsee> -11
* Hobbsee has rebooted now
<nemo_home> huh.
* Hobbsee is afk for a bit
<nemo_home> wtf
* nemo_home re-updates
* keescook -> bed
<nemo_home> I wonder if it is her repo list!
<nemo_home> maybe I broke her machine :(
<nemo_home> I'd followed instructions on ubuntu website for adding unofficial repos so she could play her DVDs and mp3s and such.
<nemo_home> if so I'm really sorry for wasting dev time
<Hobbsee> i'ts not a problem
<Hobbsee> you're not the only one
<nemo_home> 2.6.17-10-386  is definitely her uname -r - *checks update log*
<_ion> Hehe, good quit message.
<LaserJock> jdong: you're going to MIT now?
<jdong> LaserJock: yeah
<LaserJock> when did you start?
<jdong> last week
<LaserJock> I knew you were heading there
<LaserJock> ah, cool
<jdong> this place rocks :)
<LaserJock> heh
<jdong> and it rocks even more now that I can passwordless ssh onto the network
<LaserJock> I thought of going there, but I'm from a little town in Montana, the idea of going to MA scared me off
<LaserJock> :-)
<jdong> :)
<jdong> I'm glad I don't have to drive in this place :)
<jdong> anyone on feisty use evolution with IMAP?
<jdong> it seems to be acting up... refusing to see new mail
<LaserJock> I've not had great success with evo and IMAP
<jdong> well, back to using mh :D
<jdong> man, I still have to meet the great mako one of these days
<geser> 11
<geser> 11
<yacoob> Greetings. Can anyone tell me what was the reasoning behind making linux-686 package obsolete with linux-generic?
<tfheen> the functionality is superseded in -generic
<yacoob> allright, where the optimalization for amd users and such went? :)
<tfheen> AMD CPUs are generally quite well off with about the same optimisations as Intel CPUs.
<yacoob> well, the options in kernel config are there, so I guess they weren't made just for kicks...
<yacoob> anyway, is there any reasoning put anywhere on launchpad behind this change?
<Chipzz> yacoob: they're there for gentoo ricers ;P
<tfheen> no, but it was discussed on ubuntu-devel.
<mdke_> there is reasoning on the mailing list
<yacoob> Chipzz, :)
<mdke_> launchpad isn't used for reasoning :)
<mc44> yacoob: https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/019983.html
<yacoob> 'reason' and 'launchpad' don't go together you say? :)
<mdke_> that's not what I said
<yacoob> hm, this post is interesting, thanks.
<yacoob> apparently I haven't build the kernel by hand for way to long - did things like support for processor-specific extensions made their way to loadable modules?
<tfheen> no, but certain operations are selected at boot-time.
<yacoob> I'd need to take a poke at .config of this generic kernel...
<yacoob> still - where and when specific optimizations are selected?
<yacoob> (asking in the meantime, before I lay my hands on the actual config of this new kernel :)
<mjg59> The optimisations are generic 686
<mjg59> Which, it turns out, are pretty much what you want for any modern processors
<yacoob> (I knew all of this "technological progress" was one big hype... :)
<angasule> would it be possible for a kernel upgrade to check what packages depend on it and not upgrade/warn? I'm talking specifically because I had an nvidia driver from another repo (not manually installed), and with the new kernel in edgy I lost X11 (I had to use the console to edit /boot/grub/menu.lst )
<Chipzz> not supported
<Chipzz> also, you can install multiple kernels, but only one nvidia-glx package
<angasule> ah, didn't know that one
<angasule> btw, I thought ubuntu was considering including nvidia binary-only driver support by default? if so, you'd better support it
<Chipzz> how? it's closed source...
<angasule> Chipzz: what I said earlier: give a warning, so that people are not dumped to the console
<Chipzz> no
<Chipzz> how is ubuntu going to support closed source drivers?
<Chipzz> it's hard to act on bugreports that way
<angasule> same as everybody else who supports closed source drivers :)
<Chipzz> wrong
<angasule> and btw, what I said is clear
<Chipzz> no-one supports closed source drivers
<Chipzz> bzzzzzzt'
<Chipzz> this is of course, depending on what you mean by "support"
<angasule> of course :)
<angasule> and btw, I was clear about the 'how'
<angasule> say "if you do this, your binary driver won't work"
<Chipzz> and I was clear that you can install multiple kernels in parallel so your sugestion won't work? :)
<Chipzz> you can not force a user to boot a particular kernel
<angasule> Chipzz: umh, you can't give a warning?
<Chipzz> 14:57 < Chipzz> you can not force a user to boot a particular kernel
<Chipzz> it will break depending on what kernel you boot
<angasule> when installing a different kernel, give a warning, on *install*, not on the boot menu
<Chipzz> again, wrong
<Chipzz> people don't care about kernels
<Chipzz> (Your grandmother) "What's this kernel this bloody thing is babbling about?" and subsequnt ignore
<angasule> "proceeding with this upgrade may cause problem with your graphical environment, do you wish to proceed?"
<angasule> and dumping her to the console is better?
<Chipzz> no
<angasule> that you don't *like* the warning is different from "it's not possible"
<Chipzz> it's not that the ubuntu developers don't like it
<Chipzz> it's the users that don't care and which will proceed regardingly
<Chipzz> *regardlessly
<Chipzz> "Yeah yeah whatever" *click ok*
<Chipzz> that or:
<Chipzz> *panic*
<Chipzz> bottom line is
<angasule> the "yeah whatever" crowd will not have an excuse, while the *panic* would *PANIC* at the console
<Chipzz> in normal situations the kernel and nvidia module are upgraded together, and the system will always boot the last kernel, so no problem
<Chipzz> your bottom line: you did something unsupported, not ubuntu's proble,
<Chipzz> sorry, but you cannot expect the ubuntu developers to account for every possible repository in existance. that's madness
<angasule> what I said wouldn't require that, but a kernel reverse dependency check
<geser> the old kernel is still available => deps fulfilled
<Chipzz> idd
<Chipzz> let me reiterate:
<Chipzz> you can't have the kernel depend on a specific version of nvidia-glx, because in that case you cannot parallel install multiple kernels
<Chipzz> you also can't have the nvidia-glx package depend on a specific kernel, because the depency may be satisfied by another installed kernel
<angasule> ok, you guys seem as flexible as the #gnu folk, some people actually have to use their 3D cards
<angasule> I did not ask for a single kernel version, you keep bringing up straw men
<Chipzz> no, you just don't get it :)
<angasule> go read slashdot
<Chipzz> you did something unsupported, it's unsupported
<geser> btw isn't nvidia-glx only the xorg driver?
<fabbione> geser: no
<Chipzz> geser: also the libGL stuff
<fabbione> also the libGL stuff that needs to be in sync with the kernel module
<geser> but as long as you have the same versioned kernel module for all installed kernels it should be ok
<fabbione> tho you can have multiple kernels assuming they are all using the same version of the nvidia kernel driver
<fabbione> geser: yes but it's not predictable
<Chipzz> fabbione: idd
<fabbione> and there is no easy way to enforce it
* fabbione has been there before
<Chipzz> fabbione: but you have to upgrade your nvidia drivers at some point...
<fabbione> Chipzz: s/have/can
<Chipzz> fabbione: I hope I was polite enough to the guy?
<fabbione> Chipzz: i think so.. i didn't read the entire scrollback
<Chipzz> I'll agree that it's a nasty problem, but I don't think there's an easy way out
<Chipzz> a warning may be a possibility, but like I said, users will either ignore it or panic :S
<fabbione> no there is no easy way out without a lot of hackering
<fabbione> most often impossible
<Chipzz> hrrrm I'm wondering
<Chipzz> would it be possible/appropriate to issue a warning about installing packages from non-ubuntu repositories?
<Chipzz> "Hi, you're installing a package from a non-official repository. This is unsupported and may break your system. Proceed Yes/No?"
<mjg59> Chipzz: We do support the use of nvidia drivers, but only from our repositories
<fabbione> Chipzz: ask mvo
<fabbione> gotta run
* fabbione &
<Chipzz> mjg59: 14:51 < angasule> would it be possible for a kernel upgrade to check what packages depend on it and not upgrade/warn? I'm talking specifically  because I had an nvidia driver from another repo (not manually installed), and with the new kernel in edgy I lost X11 (I had  to use the console to edit /boot/grub/menu.lst )
<mjg59> Yes, I agree that he was screwed.
<mjg59> But the issue isn't that we don't support binary drivers. It's that if you've installed third-party packages, you're likely to be screwed.
<Chipzz> this may also deal with stuff like automatix etc
<Chipzz> mjg59: that's what I was suggesting anyway :)
<Chipzz> 15:15 < Chipzz> "Hi, you're installing a package from a non-official repository. This is unsupported and may break your system. Proceed Yes/No?"
<mjg59> 13:55 < Chipzz> no-one supports closed source drivers
<mjg59> Which is wrong. We do.
<Chipzz> 14:56 < Chipzz> this is of course, depending on what you mean by "support"
<mjg59> Well, it's quite clear what he meant.
<Chipzz> mjg59: I was referring to support in the context of "fix/be accountable for bugs"
<mjg59> Which is entirely not what he was asking about
<mjg59> Please don't say things like that to users. It just gives them the wrong impression of what the problem is.
<Chipzz> hrrrm ok
<mjg59> In this case, it has nothing to do with closed drivers. It's the fact that they installed drivers from a third-party repository
<Chipzz> uhu
<Chipzz> hence my suggestion about the warning
<mjg59> I'm not criticising your suggestion. I'm criticising your earlier behaviour.
<Chipzz> well, to be fair, I did clarify my point afterwards
<mjg59> Once he was already confused
<Chipzz> blah :P anyway...
<Enola_Gay> hi all
<Enola_Gay> Is ntfs-3g integration planned for Feisty?
<mjg59> Enola_Gay: At this point, it looks unlikely
<mjg59> It's still an rc, so we're still a bit reluctant about using it by default
<mjg59> Eating people's Windows partitions would be really quite bad
<Enola_Gay> It could help Ubuntu a lot since data exchange ist much more easier and it makes much sense for Vista.
<Enola_Gay> mjg59: Ok, that makes sense.
<Chipzz> Enola_Gay: we do support read-only ntfs access for one way data exchange :)
<Chipzz> (I think :P)
<mjg59> Yes, ntfs is supported r/o
<Enola_Gay> Chipzz: Yeah, but if you have a data partition you need fat32 which isn't so good. 2gb limit, fragmentation and so on.
<Enola_Gay> mjg59: Chipzz: And afaik the installer uses ntfsresize which could be very bad too
<mjg59> Enola_Gay: ntfsresize has been tested a great deal more
<Enola_Gay> The possibility is much more higher crashing the whole partition with this one
<Chipzz> Enola_Gay: no, because ntfsresize doesn't actually change your data
<mjg59> Chipzz: !
<mjg59> Chipzz: It rewrites large chunks of the filesystem
<Chipzz> mjg59?
<Enola_Gay> mjg59: The Dapper ntfsresize could make problems with fragmented partions afaik
<Chipzz> mjg59: allow me to clarify
<Enola_Gay> Chipzz: Yes, if the partition is completly defragmented which is not so likely?
<Chipzz> mjg59: one of the problems with ntfs, as I understand it, is that ntfs supports compressed and encrypted files
<mjg59> Chipzz: No, that's not relevant
<mjg59> It's trivial to refuse to touch those. 
<Chipzz> the problem with ntfs-3g is, that when *altering* a file, which may be compressed/encrypted, this may cause data corruption
<Chipzz> ntfsresize as I understand it doesn't actually touch the contents of files, it just shuffles them on-disk
<Enola_Gay> Chipzz: Encrypted files is no problem since it could be only read with user login and compressd could be read. Nothing more is needed. Maybe the permissions but no multi user server would use ntfs under linux imho.
<mjg59> Chipzz: No. ntfs-3g manages that perfectly well. 
<mjg59> The issue isn't file access. That's very, very straightforward.
<mjg59> The issue is dealing with filesystem metadata and layout. That's the hard part.
<mjg59> ntfsresize alters that to a huge extent.
<Chipzz> hrrrrm, maybe my understanding of the problem is incorrect then
<Enola_Gay> mjg59: What's with the hidden data like the internet download tag?
<mjg59> Enola_Gay: All ought to be fine
<mjg59> Chipzz: It would appear so
<Chipzz> as I understand it, ntfsresize just shuffles blocks of data, and alters the directory indexes accordingly (in case of a fragmented ntfs fs)
<Enola_Gay> I can't wait until a stable version with Ubuntu is out. So you can resize ntfs and save data on it. That would make linux testing much more easier for everyone.
<mjg59> Enola_Gay: Indeed. With luck, feisty+1
<mjg59> Enola_Gay: I'll look into making ntfs-3g easier to use, so people can just install it
<Enola_Gay> cool
<Enola_Gay> mjg59: But it isn't shipped with Live CD?
<mjg59> Enola_Gay: No, sadly
<mjg59> Getting it into ship at this point isn't likely to happen
<Enola_Gay> So you need Knoppix or something like that for "reparing".
<mjg59> If you have network access, you can install packages
<Enola_Gay> Does someone know if a grub reparing function is shipped with the CD?
<Enola_Gay> mjg59: That's true.
<sistpoty> any archive admin around, who could look why xmms-sid (binary) hasn't been published for edgy-proposed, while the source is published? (bug #82692)
<Ubugtu> Malone bug 82692 in xmms-sid "[SRU]  xmms-sid broken in edgy" [Undecided,Fix committed]  https://launchpad.net/bugs/82692
<Enola_Gay> It is very hard for a new user to reinstall grub if it is removed from mbr
<Enola_Gay> Afaik Suse has a Live CD grub entry or something like this for the problem.
<mjg59> For those of you interested in wireless, we have some exciting hotness lined up in the near future
<mjg59> Depending on how quickly we can fix stuff up, potentially including an actual free atheros driver
<givre> mjg59: easier configuration of ntfs-3g -> http://givre.cabspace.com/ntfs-config/ . actually in the upload queue
<Enola_Gay> That would be gerat.
<Enola_Gay> mjg59: Is this driver compatible with network-manager and wpa?
<mjg59> Enola_Gay: Yeah
<mjg59> Well, to the extent that any devicescape drivers are
<kmon> mjg59: will it work with new macbooks? :)
<mjg59> kmon: We'll be working on that
<Enola_Gay> That's great. Feisty would be the first Ubuntu version which could deal with wpa out of the box afaik. At least from the live cd.
<mjg59> No guarantees
<kmon> it's based on dadwifi right?
<mjg59> Yup
<mjg59> I'm having some trouble with dscape drivers and n-m at the moment, but it's a generic problem that we'll have fixed
<mjg59> Especially since we'll probably be going with iwlwifi rather than ipw3945
<kmon> I thought openhal was lagging behind
<mjg59> It's behind the closed hal right now
<mjg59> But ought to be fixable
<mjg59> It almost works on my (very recent) atheros
<mjg59> I'm just testing it on older hardware now
<kmon> great news
<shackan__> awesome
<Enola_Gay> Macbooks have no intel wlan chip?
<kmon> Enola_Gay: no
<shackan__> mjg59, unrelated, is anybody hacking on 802.11n yet?
<mjg59> Not really
<Enola_Gay> shackan__: Yeah, that would be interesting.
<mjg59> Intel are committed to d80211 support, and 4965 has n support
<kmon> afaik it's a airport card which is based on atheros chipset
<mjg59> So there'll be no issue with getting generic 802.11n
<mjg59> Specific hardware support might take a little longer
<Enola_Gay> Grub reparing would be great.
<Enola_Gay> cu all
<Enola_Gay> mjg59: Chipzzthanks for information.
<kmon> bye
<mjg59> cjwatson: Hm. I'm getting "Hard disk error" from Grub on a Toshiba that was previously awkward - it's one that doesn't pass the right hard drive id from the bios
<tfheen> mjg59: grub then just tries 0x80, iirc?
<mjg59> tfheen: I thought so, yeah.
<mjg59> But it's now failing when trying to read the geometry.
<tfheen> at least I remember to have read a comment to that effect in the source.
<mjg59> Which implies that it's failing to find LBA support
<mjg59> Which makes me think that something is very broken
<mjg59> Also, grub build-deps on gcc-4.0
<mjg59> Which doesn't seem to be available any more
<tfheen> true, I removed that.  I wonder why it wanted 4.0
<mjg59> tfheen: I'm trying with my old patch to fall back to the device grub was installed to
<mjg59> stage1.S:450: Error: attempt to .org/.space backwards? (-6)
<mjg59> Hm.
<mjg59> That's something to do with my patch.
<mjg59> Ah, I've made it too long...
<mjg59> Hm.
<mjg59> Can I fit this into 4 lines?
<mjg59> Oh, wait a moment
<mjg59> tfheen: stage1.S - the first line of boot_drive_check:
<mjg59> Does that look right to you?
<mjg59> Surely it'll skip straight past?
<asac> keescook: hello ... it was just my daily reconnect :)
<tfheen> yes, that just jumps, I'd think.
<mjg59> tfheen: Which is surely not right
<tfheen> wouldn't think so, no.
<mjg59> tfheen: How do I install grub in an installer chroot?
<mjg59> grub-install just segfaults for me
<mjg59> Hmph. So does grub.
<cjwatson> sistpoty: I fixed up xmms-sid yesterday
<cjwatson> sistpoty: the binaries got lost due to a locking error, and then my initial attempt to resurrect them failed due to somebody writing "-proposed-updates" instead of "-proposed" in a script. But it's been fixed since yesterday.
<mjg59> cjwatson: Any idea why grub is just segfaulting on me?
<cjwatson> mjg59: none
<cjwatson> (and I'm not really here)
<mjg59> cjwatson: Ok
<cjwatson> (aside from the facile "somebody broke it")
<mjg59> Worked fine in the installer, I just can't run it once the machine is up
<mjg59> cjwatson: Turns out that we don't seem to be able to build a working grub righ tnow
<cjwatson> yum
<cjwatson> last version I uploaded was 19 January, and I'm pretty sure that worked
<mjg59> cjwatson: There's no gcc-4.0 in the archive now
<mjg59> Which is a pretty good argument against it building :)
<mjg59> And using 4.1 /seems/ to make it segfault
<cjwatson> bug 51518
<Ubugtu> Malone bug 51518 in grub "grub 0.97-11ubuntu1 segfaults on amd64" [Undecided,Fix released]  https://launchpad.net/bugs/51518
<mjg59> I'm just trying with 3.3
<mjg59> cjwatson: Looks pretty much exactly like that, yeah
<mjg59> cjwatson: Right. We either need to fix it to work with 4.1, re-add 4.0 to the archive or fall back to 3.3 or 3.4
<cjwatson> I think some time spent on the first would be well-spent
<cjwatson> we have a couple of months to release yet, and I'd rather not keep moving backwards
<Keybuk> "over three months until release"
<Keybuk> it makes the panic go away if you repeat that to yourself
<cjwatson> in what timeline?
* cjwatson takes Keybuk's TARDIS away
<mjg59> Keybuk: s/three/two/?
<Keybuk> I did actually mean to type two
<mjg59> cjwatson: Gah. And upstream's fix doesn't actually work anyway, so I'm going to revert that and re-add my own.
<Robot101> iwj: did Xen upstream ever reply/fix the checksum crack?
<Robot101> just ran into it. /again/. sigh.
<cjwatson> mjg59: tried valgrinding it?
<mjg59> cjwatson: Oh, sorry, not that
<mjg59> cjwatson: I mean the upstream "fix" for dealing with bioses that pass the wrong drive ID
<mjg59> cjwatson: 1) the code is never executed because there's a jmp at the start that skips it
<mjg59> 2) Even without that, it doesn't work
<cjwatson> sure, I can believe that
<mjg59> So I'll switch back to mine, which is what we carried previously
<mjg59> The build fixing is likely to be more painful
<cjwatson> hence my valgrind question
<mjg59> I'll get to that next
<cjwatson> I realise it's painful with grub due to the simulator business
<mjg59> I'm trying to get this machine booting first :)
<cjwatson> but from the strace it looks like this is happening just at exit from the simulator or something like that
<mjg59> Yeah
<mjg59> It's not in response to a library or system call
<cjwatson> mjg59: might be worth looking at http://savannah.gnu.org/file/grub-0.95-use_mmap_exec_stack.patch?file_id=2213 instead of the dodgy mprotect thing I did way back in hoary
<cjwatson> mjg59: somebody commented in response to my patch on bug-grub that it was Bad and Wrong in various ways
<cjwatson> I just never did anything about it :-/
<sistpoty> cjwatson: thanks
<mjg59> cjwatson: Won't build on ia32
<mjg59> Since there's no MAP_32BIT
<Mez> keybuk, nice article on upstart in this months linux mag
<_ion> mez: Is it available online?
<Mez> _ion no idea
* Mez goes and grabs the mag to find a link to the website
<cjwatson> mjg59: yeah, I'm not saying it's correct, but my patch is also just plain wrong
<mjg59> cjwatson: What's the mprotect stuff actually needed for? Just x86_64?
<Keybuk> Mez: still not seen it
<cjwatson> mjg59: look for a patch by Peter Jones of Red Hat on bug-grub ages ago
<cjwatson> mjg59: anything with the NX bit
<mjg59> Ah
<Mez> Keybuk, ah shame, you should get a copy :D
<mjg59> cjwatson: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/grub/grub-0.97-nxstack.patch?revision=1.1&view=markup ?
<cjwatson> mjg59: http://www.arcknowledge.com/gmane.comp.boot-loaders.grub.bugs/2005-02/msg00021.html
<cjwatson> the Mandriva patch seems to do other random stuff; not quite sure what that is
<cjwatson> Peter seems to know what he's talking about so I'd go with his as a starting point :-)
<mjg59> I don't have an nx box here
<mjg59> So I'm a touch worried about breaking stuff
<cjwatson> if it fixes your problem, I can test it tomorrow
<mjg59> Ok
<mjg59> Now I just need to figure out how to get a plain text version
<Mez> _ion, nope it's not on their website
<_ion> Ok, thanks anyway.
<mjg59> cjwatson: No, doesn't fix it
<mjg59> cjwatson: It seems to be in grub_putstr, oddly
<mjg59> I'm not sure whether I believe that
<mjg59> cjwatson: Hm. grub_printf seems to get broken, somehow.
<mjg59> cjwatson: If I comment out line 213 of char_io.c, things work
<mjg59> cjwatson: Eh. There's something very funky with this code.
<mjg59> cjwatson: This code scares me, and I don't understand why gdb is telling me lies.
<chrisj> cjwatson:wrt email how short is short term?
<bddebian> Heya
<tepsipakki> what's the best tool to merge two files together? (massive changelogs in this case)
<tfheen> I've found meld useful in the past.
<tepsipakki> tfheen: thanks, looks like a proper tool :)
<cjwatson> chrisj: within the next two or three weeks, maybe?
<mdke> is today's daily a good bet?
<tepsipakki> blimey... xorg-7.2 runs without xorg.conf
<tepsipakki> did 7.1 do that?
<_ion> I don't know, but that's very cool.
<Burgundavia> tepsipakki: nope
<siretart> tepsipakki: how do you configure multihead without xorg.conf?
<tepsipakki> siretart: no idea :)
<tepsipakki> maybe it isn't supposed to do that
<tepsipakki> it detects the device, then uses "Builtin Default" stuff for the configuration
<tfheen> once you get monitor hotplugging, you just start some configuration agent which tells the X server to add a second head.
<Burgundavia> RH is planning to redo system-config-xfre86 for 7.3
<Burgundavia> 7.3=output hotplug
<siretart> sounds promising :)
<Burgundavia> means F7 is not shipping with a graphical client, as 7.2 changes some bits
<siretart> tfheen: can you please give back gxine on sparc? I fixed the FTBFS for xine-lib on sparc
<siretart> Burgundavia: F7?
<tepsipakki> there's some cool stuff on debian XSF todo-list for Lenny
<tfheen> siretart: given-back
<Burgundavia> siretart: fedora 7
<Burgundavia> tepsipakki: you talking about avahi
<Burgundavia> ?
<Burgundavia> siretart: Fedora core is now just Fedora
<siretart> tfheen: thnx
<tepsipakki> Burgundavia: no, we have that already?
<Burgundavia> tepsipakki: you going to be able to get all this lovely xorg stuff past tfheen?
<siretart> tepsipakki: you mean besides monitor hotplugging?
<tepsipakki> Burgundavia: hah
<tepsipakki> remains to be seen ;)
<Burgundavia> tepsipakki: oh, Lenyy, you mean the Debian release, not the person
<tepsipakki> siretart: http://wiki.debian.org/XStrikeForce/XSFTODO
<tepsipakki> Burgundavia: indeed :)
<Burgundavia> Leonard Poetering is one of the avahi devs
<tepsipakki> heh
<Burgundavia> what we need now is somebody to glue all the bits together to have a truly free multiseat
<Burgundavia> as Hal is about to be able to handle multiseat stuff
<tepsipakki> I wondered why the screen looked strange without xorg.conf.. it used the maximum resolution the monitor was capable of :)
<tepsipakki> and a lower refresh rate
<siretart> tepsipakki: I hope you get useful options via xrandr
<tepsipakki> yes, it can be changed from the prefs easily
<tepsipakki> should I build GNOME/KDE in the chroot to make sure the libs don't have regressions?-)
<tepsipakki> hmm, no Composite
<tepsipakki> hah, that was only a stupid config error
<tepsipakki> and now I have compiz running.. was not possible before
<_ion> tepsipakki: With what gfx card?
<tepsipakki> Radeon 8500
<tepsipakki> but maybe it was because of that misconfiguration.. anyway it doesn't crash when running glxgears like before
#ubuntu-devel 2008-02-04
<[reed]> anybody that can correct a typo on the alpha4 release notes page around?
<slangasek> [reed]: I can feed it to the webmaster for fixing later
<[reed]> slangasek: ok, just check http://ventnorsblog.blogspot.com/2008/02/how-do-i-notes-release.html
<[reed]> it explains the two issues
<[reed]> thanks! :)
<slangasek> wow, er, ok
<slangasek> that bug was already in the alpha3 release notes, I wonder why he didn't correct us earlier for misspelling his name :)
<[reed]> heh, guess he didn't notice
 * slangasek chuckles that he corrects us for not including the full title of his blog post, when his blog post doesn't follow correct English capitalization rules for titles ;)
<StevenK> slangasek: Could you please release mlt++ from binary NEW?
<[reed]> slangasek: heh, I'll berate him about that :)
<andresmujica> which package generates /etc/environment ? i couldn't find any using dpkg -S
<slangasek> currently, I'm not sure anything does create it reliably
<andresmujica> i'm triaging some bugs related to that file but cannot find where to put them or which package to assign them
<slangasek> andresmujica: I think pam is going to end up being responsible for the file creation in Debian, and unless the Ubuntu installer has diverged in ways I'm not familiar with, that means it'll be doing the same in Ubuntu; so I think that's an ok starting point
<andresmujica> ok thks
<helpme> HI CAN SOMEONE HELP ME I HAVE A PROBLEM WITH MY UBUNTU :(
<ion_> You can solve your problem by hitting the âCaps Lockâ key once. The light should turn off.
<emgent> helpme, please ask in #ubuntu
<helpme> i did ask there
<richbl> hello all... I'm interested in doing some Ubuntu work. I'm a dev, but I'm specifically interested in interface design/development. Can someone recommend a good mailing list?
<richbl> Hmmm... looks like I need to move to #ubuntu-motu... byef
<pwnguin> hidden elitist IRC channel Linus is involved with?
<ScottK2> pwnguin: If you knew about it, it wouldn't hidden, right?
<pwnguin> ScottK2: i suppose
<pwnguin> but i thought the lmkl was the goto point for conversation
<ScottK2> I have no idea.  Just saying.
<mjg59> It's like anything. Sometimes it's easier for people to talk to each other directly.
<pitti> Good morning
<StevenK> Morning pitti
<pitti> StevenK: hey! back home?
<warp10> Good morning
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<pitti> calc: MainInclusionReportHunspell says that hunspell is the successor of myspell; does that mean that we could get rid of myspell to reduce the *spell duplicate-o-rama a bit?
<pitti> calc: (aspell, ispell, myspell, hunspell -- that's both a maintenance and user experience hell)
<pitti> ArneGoetje: CC: ^
<pecisk> hi people, I try to debug app under Ubuntu. I am using -dbg packages and gdb. However, when I try to run app - under root - in gdb, it says that it can't execute file, however file has execute flag in permitions. It gives error like this: warning: Unable to find dynamic linker breakpoint function
<pecisk> did I miss something? What else need to be installed to debug apps?
<pitti> cjwatson_: did your proposed patch in bug 188650 actually work for you? doesn't here (debugging now)
<pecisk> I read docs on wiki, but they don't tell about such scenario as mine
<ubotu> Launchpad bug 188650 in policykit "configuration makes life difficult for root" [Undecided,New] https://launchpad.net/bugs/188650
<pitti> cjwatson_: (I think the problem is that root usually does not have a ConsoleKit session)
<seb128> pitti: speaking about hunspell
<seb128> pitti: http://fedoraproject.org/wiki/Releases/FeatureDictionary
<seb128> pitti: there is a mail on ubuntu-devel-discuss about that, fedora and opensuse are switching to hunspell
<pitti> seb128: oh, great! thanks
<seb128> pitti: looking at the fedora spec they have quite some patches etc already
<pitti> right, shouldn't be too hard
<cjwatson> pitti: it improved matters slightly as long as I passed XDG_SESSION_COOKIE through sudo
<cjwatson> pitti: I'm not saying it makes everything magically work on its own - there are still other things to fix - but it gets rid of one of the roadblocks
<cjwatson> and like I say it does seem to be a better set of semantics
<cjwatson> the other obvious problem seems to be getting hold of the dbus session bus
<pitti> cjwatson: ah, that was it, thanks; I just wanted to test it before uploading
<pitti> cjwatson: dbus session bus> in earlier g-s-t I had a patch which used the session bus from $SUDO_USER
<pitti> cjwatson: we dropped that patch because it's not necessary by default any more
<pitti> but if we need it for something, we can revive it
<cjwatson> at the moment it makes life easier if you're running over ssh
<pitti> cjwatson: but IIRC it was only time-admin
<pitti> and only for disabling the screensaver
<cjwatson> I sent a mail to Oliver + CK upstream + PK upstream about this
<pitti> ah
<cjwatson> the problem at the moment is that PK denies everything by default if your CK session is not local
<pitti> ok, policykit uploaded
<cjwatson> the PK configuration I suggested lets you work around this using sudo
<cjwatson> you won't be able to test this yet, though, as the openssh patch to create a CK session lives mainly on my disk ;-)
<pitti> so the pam module didn't work out in the end? (would be much more elegant)
<cjwatson> unfortunately not
<pitti> I remember the discussion, but I didn't see all of it
<cjwatson> sshd opens the pam session way before the request comes from the client to create the pty
<cjwatson> the only way to make a pam module work for this would be to completely reorganise how sshd interacts with pam - again
<cjwatson> which doesn't really excite me
<cjwatson> I did try :)
<Company> hm, my weekly dist-upgrade wants to remove epiphany
 * Company looks at seb128 
<seb128> Company: epiphany or epiphany-browser?
<Company> lemme check
<Company> epiphany-browser epiphany-browser-dev epiphany-extensions epiphany-gecko
<seb128> weird
<Company> trying to manually install all the pckages it has kept back to find the culprit
<seb128> ah
<seb128> Company: what version do you have installed?
<Company> 2.20.1-0ubuntu1
<Company> of epiphany-browser
<seb128> k, that's likely because there is no epiphany-extensions 2.21 yet
<Company> ok
<seb128> either remove this one if you don't need it
<seb128> or keep using epiphany-browser 2.20.n
<Company> yeah
<Company> just wanted to make sure you're aware of the issue
<seb128> and talk to chpe about update those and rolling a new tarball ;-)
<seb128> right, we are, we are blocked on upstream updating and rolling a new tarball though
 * Company goes kicking chpe
<Company> unrelated question: are you gonna ship swfdec-gnome?
<seb128> ship on the default installation you mean? because it's already available in universe
<seb128> not sure what are the plan about flash support
<seb128> asac: ^ any idea about this one?
<Company> yeah, the question was more about status than availability
<geser> dholbach: Hi, do you know when a new python-launchpad-bugs will land in hardy?
<asac> seb128: i think he refers to the plugin finder service (e.g. will it be included in result list)
<dholbach> geser: bdmurray wanted to prepare a new upload soon
<asac> the answer is definitly "yes"
<Company> asac: it's more related to libswfdec being an external dep of gnome now
<asac> Company: if there is a software component that requires it, it will automatically be shipped
<Company> asac: not the moz plugin
<Company> k
<Company> so that's magic at work there :)
<asac> if you ask if its on CD ... i don't know. if there is anything of gnome on CD that needs it, then we have to consider it
<asac> Company: more or less :)
<seb128> Company: what does swfdec-gnome brings us? we likely want to consider it if it's useful ;-)
<Company> seb128: thumbnails and a standalone flash player
<asac> seb128: i think its some build dependency of some gnome component/app, but Company would know more details
<Company> seb128: via swfdec-gnome
<seb128> I'm wondering if we have lot of users using flash out of their web browser
<seb128> I don't
<Company> seb128: it's what vuntz called the evil plan to get swfdecinto the desktop ;)
<seb128> I think that's worth discussing, that's always a balance between cost to support and what it brings
<Company> seb128: you might be intersted in https://www.redhat.com/archives/fedora-desktop-list/2008-January/msg00084.html
<asac> Company: in the end having it in universe shouldn't hurt imo (as long as the thumbnail support can be rolled in a plugin like fashion)
<seb128> Company: thanks
<Company> asac: yeah, i wouldn't mind either way
<asac> Company: you said on your own that swfdec might not yet be ready given we have a LTS release ... or isn't that true for thumbnails/standalone player?
<Company> asac: i think the thumbnails/standalone thing is not as critical, which is why i proposed it for gnome
<Company> asac: it doesn't crash your browser if it sucks ;)
<Company> also, it doesn't have as much impact and isn't as hard to implement
<seb128> well, that's still code which we would need to support for security issues, etc if we promote it to main
<awalton__> seb128, ping on launchpad bug 188361, this one's pretty serious
<ubotu> Launchpad bug 188361 in nautilus "Nautilus is following symbolic links when emptying trash" [Medium,Fix committed] https://launchpad.net/bugs/188361
<Company> right
<seb128> awalton__: I've read the discussion on #nautilus and was about to backport it
<awalton__> ah right
<seb128> awalton__: thanks for the ping though
<awalton__> I didn't see you in there
<seb128> ;-)
<awalton__> must just be early
<asac> Company: is the thumbnail support a different tarball? or is it just a matter of packaging?
<Company> asac: it's a dfferent tarball
<Company> asac: from the moz plugin
<seb128> asac: swfdec-gnome, it's in universe
<Company> asac: there's swfdec, swfdec-gnome and swfdec-mozilla
<asac> so we already have it ;)
<Company> right
<Company> it's just in universe
<psicus78> asac: hi
<asac> psicus78: ?
<psicus78> asac: hi asac, I found your nick on the network-manager page on launchpad
<asac> yep
<psicus78> I was wondering if you plan to add support to wired authentication
<asac> psicus78: we don't implement features on our own there, but track what network manager releases upstream.
<psicus78> I know I know...
<asac> ;)
<psicus78> the fact is that the feature has been implemented in network manager and also committed to 0.6 branch
<psicus78> I filed a bug few days ago to ask for packaging
<psicus78> sorry I wasn't clear
<asac> psicus78: then we will get it in hardy :) ... there is discussion to release 0.6.6 i just wanted to see if thats going to happen before cherry-picking more from svn to our package
<psicus78> ok, cool!
<psicus78> :)
<mgunes> is there a release of multidistrotools?
<Fujitsu> mgunes: No.
<persia> mgunes: No, but there are several branches around.  I recommend http://people.ubuntuwire.com/~fujitsu/bzr/multidistrotools/
<mgunes> Fujitsu, persia, thanks. anyone particular who maintains it? it would be nice to have it in Universe.
<Riddell> doko: can you think of any reason why my kde 4 packages have stopped including rpaths in their libraries since last week?
<doko> Riddell: no, not really.
<Riddell> doko: no, me neither, I can work around it
<doko> Riddell: or is this a feature test using the gcc version number?
<pitti> Riddell: instead of using rpaths (which is slightly ugly IMHO), would it work to put an /etc/ld.so.d/ snippet into some libkdeyouneedme?
<pitti> (kdelibs5?)
<pitti> Riddell: /etc/ld.so.conf.d/ of course
<Riddell> pitti: that's exactly me work around
<Riddell> my
<Riddell> doko: no it's not that, RPATH has disappeared from the .so file (compiling the same source package the same way)
<TheMuso> Good night folks.
<pitti> bye TheMuso
<geser> I've a modified Debian package in source NEW (modified to build in Ubuntu) but now there is a fixed package in unstable which could be synced. How to proceed?
<Riddell> geser: I can reject if you want, and you can file a sync request in the normal way
<geser> ok, please do
<geser> haskell-regex-compat is the package
<Riddell> geser: rejected
 * Hobbsee waves
 * geser waves back to Hobbsee
<Hobbsee> sky fallen in yet?
<xivulon> slangasek can you please have a look at bug #140458
<ubotu> Launchpad bug 140458 in wubi "Provide official Ubuntu metalink files on a public webserver" [Low,Confirmed] https://launchpad.net/bugs/140458
<xivulon> need to add support for that to wubi, and would like to have that ready before beta
<ogra> cjwatson, the ck implementation behaves a bit strange if i use: sh -c "DISPLAY=$HOST:6.0 <command>" .... see http://paste.ubuntu-nl.org/54707/
<ogra> according to your mail it shoud just leave x11-display alone or did i understand that wrong ?
<ogra> *should
<ogra> oh
<ogra> ah
<ogra> cjwatson, ignore me, just found a bug :)
<cjwatson> ogra: hmm, looks like you had X11 forwarding on as well ...?
<ogra> yes
<ogra> seems theer is a bug with ldm not dropping -X in its command
<ogra> just testing the fix
<calc> pitti: sounds good to me, assuming it can be a drop in replacement
<mantiena-baltix> hi
<mantiena-baltix> I found strange problem in policykit (I think so)
<mantiena-baltix> who is responsible for policykit ?
<mantiena-baltix> pitti, maybe you ?
<mantiena-baltix> pitti, could you help me identify if there is a policykit problem ? None of gnome-system-tools works for me, but I have all updates, so this is not bug #183673
<ubotu> Launchpad bug 183673 in policykit "Users-admin unlock not working" [Medium,Fix released] https://launchpad.net/bugs/183673
<ogra> ogra@ceron:~$ ck-list-sessions |grep x11
<ogra> 	x11-display = ''
<ogra> 	x11-display-device = ''
<ogra> ogra@ceron:~$ env |grep DISP
<ogra> DISPLAY=192.168.2.49:6.0
<ogra> cjwatson, now it works :)
<seb128> ogra: I think your gartoon issue is https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/188874
<cjwatson> ogra: excellent; do the admin tools work in that context?
<ogra> no
<ubotu> Launchpad bug 188874 in nautilus "Broken icon theme handling in Nautilus 2.21.90 in Hardy" [Low,New]
<ogra> the non-local session is still a prob
<ogra> but i have the sessions listed properly thats a good step forward :)
<ogra> seb128, smells liek it, yes
<cjwatson> ogra: right; try applying the policykit patch I mentioned in my mail and then using 'sudo env XDG_SESSION_COOKIE="$XDG_SESSION_COOKIE" time-admin' or some such
<cjwatson> (obviously a grotty hack from hell but)
<ogra> will do
<mantiena-baltix> I get this error in console when start network-admin: ** (network-admin:9958): CRITICAL **: Unable to find session for cookie
<mantiena-baltix> maybe because of this Unlock button in network-admin is grey ?
<cjwatson> mantiena-baltix: how are you logging in?
<mantiena-baltix> cj, startx
<ogra> use gdm :)
<cjwatson> if you abbreviate my name, then it doesn't highlight in my client. this is not in your best interests
<mantiena-baltix> cjwatson, sorry, there is xchat problem, I pressed tab and it didn't finished ;)
<broonie> mantiena-baltix: There is someone else with the shorter nick in the channel.
<ogra> hmm, probably the startx script should see some ck integration as well ... i guess using startx is a quite common case still
<mantiena-baltix> ogra, I can't user gdm - there is very restricted environment (only 500Mb disk space)
<mantiena-baltix> s/user/use
<ogra> mantiena-baltix, well, the desktop admin tools nowadays want a consolekit session ... there is nothing in startx that sets this up yet
<mantiena-baltix> so, how I can fix this problem without installing gdm and libraries, needed for gdm ?
 * ogra wonders if the pam module would suffice here
<ogra> there is a pam module for consolekit, but i dont think anyone has integrated it with startx yet
<mantiena-baltix> ogra, I can start consolekit session manually
<mantiena-baltix> ogra, just tell me how ;)
<ogra> your session manager needs to do that, all subsequently forked processes need to inherit the environment form that wrapper to use ck authentication ...
<mantiena-baltix> ogra, I use openbox, there is an startup script in openbox - /etc/xdg/openbox/autostart.sh
<ogra> you can surely issue a ck call to dbus or so manually from an xterm and wrap your x session in it i bet
<mantiena-baltix> I can include needed commands in that script
<ogra> fredesktop.org has the consolekit docs ...
<ogra> and i think there is also a python example how to register a session in the git webtool somewhere
<mantiena-baltix> aren't there any simpler way to get active Unlock button in network-admin
<mantiena-baltix> ?
<ogra> nope
<mantiena-baltix> ogra, maybe  libpam-ck-connector package could help me ?
<ogra> thast what i meant with "ogra wonders if the pam module would suffice here" above :)
<ogra> no idea though, but i suspect it could help
<seb128> ogra: that's an icon theme bug
<cjwatson> startx doesn't deal with PAM, AFAIK
<ogra> well, login does
<ogra> you likely wont have x11-display set in the ck session though
<cjwatson> I don't think inheriting from login is really the right answer here
<ogra> seb128, gah, thats what i suspected
<seb128> ogra: http://svn.gnome.org/viewvc/nautilus/trunk/libnautilus-private/nautilus-icon-names.h
<seb128> ogra: directories use the folder icon now
<ogra> seb128, ah, perfect, thanks !
<seb128> ogra: you will likely have to symlink some other things too
<ogra> well, wantd to look into gatoon's successor this week, it probably fixes some of that alread
<ogra> y
<mantiena-baltix> cjwatson, in reality I run startx directly from upstart script
<cjwatson> mantiena-baltix: you could possibly cobble a command-line CK registration program together from /usr/lib/consolekit/ck-collect-session-info and dbus-send
<mantiena-baltix> There are startx script in /etc/event.d which starts this command:
<mantiena-baltix> exec /bin/su ubuntu /usr/bin/startx
<cjwatson> but you will have to do some reading
<mantiena-baltix> cjwatson, currently I don't have a time for this - I should have forking system after 30 min :(
<cjwatson> I put the OpenSSH support together in about three or four days of off-and-on work, starting from knowing OpenSSH fairly well but knowing nothing about ConsoleKit
<cjwatson> if you don't have time, use gutsy
<mantiena-baltix> cjwatson, in this situation I can't use gutsy, because it works not so good on lots of notebooks
<mantiena-baltix> cjwatson, I think best decision today will be to install gnome-system-tools from gutsy
<mantiena-baltix> btw, maybe there are some setting in policy kit for allowing running all software in all situations (even when consolekit-session isn't started) ?
<cjwatson> allow_inactive
<mantiena-baltix> cjwatson, could you tell me how should I write this setting in /etc/PolicyKit/PolicyKit.conf ?
<cjwatson> I don't think it goes there
<cjwatson> you'll have to change the actual policies
<mantiena-baltix> cjwatson, how ?
<cjwatson> you will have to do some reading
<mantiena-baltix> cjwatson, where ?
<cjwatson> oh come on
<cjwatson> you're in a developer channel, use your initiative :)
<mantiena-baltix> cjwatson, I know, but problem is time now :(
<cjwatson> one might for instance start with policykit's file list
<cjwatson> which includes a .policy file, which is in the same directory as lots of others
<mantiena-baltix> cjwatson, you don't know where to include allow_inactive setting ?
<cjwatson> I have given you all the help you need to find it quite quickly
<mantiena-baltix> /usr/share/PolicyKit/policy ?
<cjwatson> try reading some files there
<cjwatson> it will be obvious
<cjwatson> I do not want to give out canned answers to things that are easy to find, because the result of that is that everyone asks this channel for things that are easy to find for themselves
<mantiena-baltix> cjwatson, I think I found - /usr/share/PolicyKit/policy/system-tools-backends.policy , right ?
<cjwatson> instead I want to teach people how to find things for themselves
<cjwatson> mantiena-baltix: I'm not going to answer further questions of this form; please do the reading
<mantiena-baltix> cjwatson, I'm very happy for teaching, thank you
<mantiena-baltix> cjwatson, just one answer - should I restart dbus after modifying that file ?
<cjwatson> I don't know offhand, and the way I'd find out would be to try it
<mantiena-baltix> ;)
<mantiena-baltix> btw, maybe someone can tell me which squashfs-tools version I should use for building hardy-based LiveCD ? Should I use 3.2r2-2build1 from Ubuntu Gutsy (Stable) or 3.3-1ubuntu2 from Hardy ?
<ogra> cjwatson, hmm, no XDG_SESSION_COOKIE at all here ... (with -X and session listed in ck-list-sessions)
<cjwatson> ogra: use ssh -vvv (and ideally run a server on a high port with /usr/sbin/sshd -ddd and connect to that)
<cjwatson> may help
<cjwatson> also check /var/log/auth.log
<ivoks> umm... anyone from canonical server sysadmins here?
<cjwatson> ivoks: #canonical-sysadmin
<ivoks> thanks
<ogra> hmm
<ogra> -vvv is a bit tricky ...
 * ogra goes to hack up ldm ...
<sladen> lloydinho_: good heavens, where have you been
<sladen> lloydinho_: I sent some answers to your initial Thesis draft, but I don't know if you got them
<lloydinho_> hi sladen! Wow, it's been ages
<sladen> lloydinho_: for a time aobut six months ago I was popping through Copenhagen on the train once a week
<lloydinho_> yeh. I just checked. I got a brief note from you about 6 months back
<lloydinho_> .. but in my hurry back then, I misread it, and thought you'd been through Copenhagen once
<lloydinho_> not that you kept coming on back through this way.
<lloydinho_> In any case, you're most welcome to drop by if you're in the neighbourhood some other time.
<lloydinho_> We have plenty of spare beds as it is
<lloydinho_> so feel free, sladen :-)
<pitti> mvo: should apt really complain about not being able to auth a package if it installs it from the local apt cache?
<pitti> mvo: if no, shall I file a bug about it? which info do you need?
<mvo> pitti: your local apt cache is a apt-cacher install or a squit? or a file:/// uri?
<pitti> mvo: I mean /var/cache/apt/archives (other than that I just have de.archive.u.c.)
<mvo> pitti: hm, it shouldn't complain about auth failures anymore at all, it should just use the last known good configuration
<sahin_w> slangasek: ping
<cjwatson> lool: bug 127985 is only an issue for gutsy at this point, not hardy, right?
<ubotu> Launchpad bug 127985 in libgtk2-perl "gutsy/amd64: ftbfs / autopkgtest failure" [High,In progress] https://launchpad.net/bugs/127985
<cjwatson> (it's in the sponsorship queue)
<mvo> pitti: is the retracer running again? it looks like I got nothing for bug #188425
<ubotu> Launchpad bug 188425 in update-manager "update-manager crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/188425
<hunger> Anyone working on a fix to the aptitude crashes?
<pitti> mvo: yes, it's running
<pitti> mvo: hm, that bug is missing a needs-retracing tag
<pitti> mvo: I don't see anything in the log file about this bug
 * pitti adds tag and watches
<pitti> mvo: better now :)
<mvo> pitti: cool, thanks
<pitti> mvo: nicely verbose trace
<mvo> indeed
<JanC> new gparted release: http://sourceforge.net/project/shownotes.php?group_id=115843&release_id=573862
<Riddell> cjwatson: do you expect to get back to seed changes this week now that alpha 4 is out?
<cjwatson> yeah
<Riddell> groovy
<mvo> pitti: if I set "needs-retracing" will the retracer pick that up automatically?#187944 seems to not have this tag either
<pitti> mvo: 'need-i386-retrace' (or other arch)
<pitti> mvo: weird; might be a bug in p-lp-bugs, or LP itself
<mvo> pitti: thanks, I added it now
<luisbg_> anybody fluent in C++ here?
<luisbg_> I need some help
<pipegeek> So.... the version of python-eyed3 in gutsy has this debugging stuff in it
<pipegeek> ie,
<pipegeek> #FIXME
<pipegeek> print "POINT 1"
<pipegeek> which means that using it results in "POINT 1" and "POINT 2" getting dumped out to stdout
<pipegeek> Where should I report this, and is it at all likely that this will be fixed?
<pipegeek> Ugh, and it was reported to debian's bugtracker two years ago, and hasn't been fixed
<ScottK> pipegeek: https://bugs.launchpad.net/ubuntu/+source/eyed3/+filebug
<pipegeek> ScottK: thanks.
<pipegeek> What is the policy on things like this?  Do they get fixed in the current stable release, or do they end up waiting for the next one?
<ScottK> pipegeek: Most things wait for the next one.  Here's the policy on stable release updates: https://wiki.ubuntu.com/StableReleaseUpdates
<pipegeek> Thank you.
<pipegeek> Darnit.  The bug submission form intelligently guessed that I was talking about the package eyeD3 when I wasn't, and I didn't notice until after I clicked 'submit'.  Is there any way I can fix it?
<pipegeek> That is, I know the binary package hint is wrong.
<ScottK2> pipegeek: Yes.  You can edit the affected package
<cjwatson> luisbg_: C++ is a big field; I think you will need to provide more detail
<pipegeek> ScottK2: sorry, I'm a doofus
<cjwatson> oh dear me, I knew you could declare methods in C++ structs (as opposed to classes), but have never actually seen it done in production code before
<ScottK2> pipegeek: No problem.  I'm pulling up the bug.  I'll help you get it sorted.
<pipegeek> Thanks a bunch :)
<pipegeek> #189027
<pipegeek> cjwatson: hehe
<luisbg_> cjwatson, lol, yeah I have a bug I can't squish at work code
<luisbg_> cjwatson, getting frustrated so I thought I could ask here for some pointers
<luisbg_> cjwatson, the problem needs to dive in a little of code between files so #c++ guys probably won't help
<luisbg_> just asking here for some friend help
<luisbg_> ompaul, you there ;)
<ScottK2> pipegeek: What's the problem with the bug?
<ompaul> luisbg_, not in spirit only in body
<luisbg_> ompaul, LOL
<pipegeek> ScottK2: there's no longer a problem.
<luisbg_> ompaul, fluent in c++? :P
<ScottK2> pipegeek: OK.
<ompaul> luisbg_, no :-(
<luisbg_> ompaul, that's ok
<maek> sorry to bother you guys with non dev but I cant seem to find anything. Is there a place to hook a script into the process of starting the network/networkmanger based on profile? I have all these crazy proxy settings I need to do for work and Id like to be able to run the script after I pick the work profile. thanks.
<sahin_h> slangasek: ping
<jdstrand> Keybuk: I am sure this is documented somewhere, but a cursory google search didn't find it
<jdstrand> Keybuk: I use an external usb drive regularly
<jdstrand> Keybuk: I plug it in and hald automounts it (cool)
<jdstrand> Keybuk: recently it stopped, and I was like, hmm
<jdstrand> Keybuk: then it occured to my I hadn't fsck'd it in ages
<sahin_h> sladen: https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/134622
<ubotu> Launchpad bug 134622 in opensync "kitchensync - opensync synchronization crash" [Undecided,Invalid]
<sladen> sahin_h: cya?
<jdstrand> Keybuk: is there a way for hald to notify the user in this case? (it is clearly deciding not to mount it automatically, so maybe part of the decision could be a notification)
<sahin_h> sladen: Sorry for my mistake! I sent this message to slangasek.
<sladen> slangasek: ^^
<jdstrand> Keybuk: s/part of the decision/part of the process/
<jdstrand> Keybuk: I should explicitly say that after fsck'ing (with no errors), I was then able to plug it in and it automounted
<slangasek> sahin_h: sorry, what are you asking me to do with this bug number?
<sahin_h> slangasek: Riddel uploaded a new package to the gutsy proposed queue (or something)...
<sahin_h> slangasek: ... and ask me to inform you about it.
<sahin_h> slangasek: I'm just a user, so I don't know the exact processes.
<sahin_h> slangasek: I rebuilt this package on my system, and works great. And I just told to Riddel it would be nice to produce....
<sahin_h> slangasek: ... a working package to everyone.
<cjwatson> the normal thing we ask testers to do with proposed stable updates is to install the package from gutsy-proposed (not rebuild it on their system - install the actual package) and follow up to the bug saying whether it fixed the problem for them
<sahin_h> slangasek: The opensync-plugin-kdepim package provide syncronization capability between local korganizer calendar and google calendar.
<cjwatson> without knowing what Riddell said to you exactly, talking to people on #ubuntu-devel about it isn't *normally* part of the process ...
<sahin_h> slangasek: So this is a great package and I use a lot.
<sahin_h> cjwatson: Ok, sorry.
<cjwatson> Riddell: ^-- something unusual going on with this bug? :)
<TheMuso> Good morning.
<Riddell> slangasek, cjwatson: sahin_h was asking that it be checked for sanity and let into gutsy-proposed (it's currently in unapproved)
<slangasek> Riddell: erm?  I thought gutsy-proposed was the unmoderated queue, only gutsy-updates requires processing via unapproved?
<slangasek> I could be very wrong of course
<Riddell> slangasek: gutsy-proposed still needs an archive admin to approve it, for main that's pitti only, for universe any admin, but I don't want to approve my own upload
<slangasek> oh.  then I think I need a pointer to the guidelines I'm supposed to be applying here, for this to be anything more than a rubber stamp
<slangasek> unless it really is a rubber stamp, in which case I don't see anything wrong with you applying the stamp yourself :-)
<cosmodad> is there a reason why CONFIG_NO_HZ (tickless kernel/dynamic ticks) is enabled for Gutsy server kernel images, but not desktop ones?
<cosmodad> sorry if this chan is not appropriate to ask this question, but I didn't know where else to ask.
<ScottK> cosmodad: Perhaps #ubuntu-kernel
<sistpoty> any main sponsor, who'd like to upload the debdiff at bug 188868 for me?
<ubotu> Launchpad bug 188868 in sdl-image1.2 "Missing dependency on libjpeg62" [Undecided,Confirmed] https://launchpad.net/bugs/188868
<cosmodad> ScottK: hmm: "Ubuntu kernel development discussion ONLY" :(
<ScottK> cosmodad: Same here.
<ScottK> cosmodad: Mail to ubuntu-devel-discuss then.
<sistpoty> (strange enough, I found out that I fiddled with this lib some time ago, when it was still in universe *g*)
<cosmodad> ScottK: well I just figured it might only affect my box. At least, forum postings indicate so. But I'll further investigate, thanks for the hint.
<seb128> StevenK: are you usually looking at bluez-utils?
<StevenK> seb128: I can look at it
<seb128> StevenK: could you look at the new version which is available? the new gnome-bluetooth has an updated requirement
<cjwatson> Riddell: oh, I see, I misunderstood your comment on the bug then
<cjwatson> sorry
<cjwatson> slangasek: http://wiki.ubuntu.com/StableReleaseUpdates are the guidelines in question
<slangasek> ah, ok
<mathiaz> slangasek: what do you think about bug 186844 for hardy ?
<ubotu> Launchpad bug 186844 in openssl "Please include support for tls extensions" [Wishlist,Triaged] https://launchpad.net/bugs/186844
<slangasek> mathiaz: there was discussion on debian-release about not being able to say with 100% certainty that it's not an ABI change; I would suggest coordinating the package change, and subsequent regression testing, with the Debian maintainer
<mathiaz> slangasek: given our time frame for hardy, is there any chance it will get fixed in Debian in due time ?
<mathiaz> slangasek: IIUC it should be done before FF.
<slangasek> mathiaz: there is some chance; more if you coordinate with the Debian maintainer, I expect :)
#ubuntu-devel 2008-02-05
<mathiaz> slangasek: so IIUC, if a new openssl package with tls extension enabled is uploaded, we can either hope that packages that depends on it won't break or rebuilt all the package that depends on libssl0.9.8 ?
<cjwatson> OpenSSL is a package very commonly used by third-party packages, and we can't make them rebuild
<mathiaz> cjwatson: ok. So what would be the options ? two source packages ?
<cjwatson> mathiaz: try not to break the ABI :-)
<cjwatson> very, very hard
<cjwatson> er, I mean "try very, very hard"
<slangasek> cjwatson: well, then the package would need to be renamed when enabling tls extensions
<slangasek> because it changes the size of several non-opaque structs
<slangasek> and if something links against openssl which is both a) third-party and b) dumb, this may result in segfaults
<cjwatson> fun
<cjwatson> could provide a separate binary package with the extension, perhaps?
<cjwatson> which definitely ought to involve coordination
 * slangasek nods
<mathiaz> which parties would be involved in the coordination effort ?
<slangasek> Debian maintainer + you :)
<el_cubano> When I run 'apt-file update' on Dapper, I get "ERROR 501: Not Implemented."  Is this a known problem?
<el_cubano> Also, does anyone know why packages.ubuntu.com is not responding?
<pochu> el_cubano: for the latter, http://blog.djpig.de/2008/02/01#packages-updates
<el_cubano> pochu: Perhaps that information should be posted somewhere prominent on the main page?
<pochu> Maybe
<el_cubano> Uggh...You have searched for the contents of lyx in dapper, architecture i386.
<el_cubano> Can't find that package, at least not in that distribution and on that architecture.
<el_cubano> Perhaps someone can answer my question.  I am trying to figure out a package build failure on Dapper.  Which package contains the /usr/bin/lyx binary?
<StevenK> lyx
<el_cubano> Not on Dapper it doesn't
<pochu> !info lyx dapper
<ubotu> lyx (source: lyx): High Level Word Processor. In component universe, is optional. Version 1.3.7-0ubuntu4 (dapper), package size 17 kB, installed size 48 kB
<pochu> So it exists.
<el_cubano> pochu: After 'aptitude install lyx'
<el_cubano> the command 'which /usr/bin/lyx' produces no output.
<el_cubano> The file is *not* present.
<pochu> el_cubano: what's the output of "dpkg -l lyx" ?
<el_cubano> ii  lyx            1.3.7-0ubuntu4 High Level Word Processor
<el_cubano> dpkg -S /usr/bin/lyx
<el_cubano> dpkg: /usr/bin/lyx not found.
<pochu> No idea then, sorry.
<el_cubano> This is most puzzling.
<el_cubano> Of course, since apt-file is broken and the packages.ubuntu.com search (even on djpig's alternate host) is also broken, I have no way of finding out which package has that binary :-(
<StevenK> I think because lyx is an alternative?
<StevenK> Hrm
<el_cubano> In that case, though, shouldn't installing it setup the alternative?
<StevenK> On dapper, lyx-qt or lyx-xforms provides the lyx-{qt,xforms} binaries
<StevenK> And then lyx is an alternative that points to either one, I guess
<el_cubano> So, then there is no such thing as /usr/bin/lyx on Dapper?
<el_cubano> The dependency resolution for 'aptitude install lyx' pulled in lyx-qt.
<mjg59> Does lyx-qt contain an alternative for lyx?
<el_cubano> mjg59: Nope.
<Hobbsee> argh.
<Hobbsee> what's the apache upload?
<StevenK> Who uploaded it?
<Hobbsee> can't tell - it's not on changelogs.ubuntu.com
<emgent> [USN] [USN-575-1] Apache vulnerabilities - http://www.ubuntu.com/usn/usn-575-1
<emgent> this ?
<Hobbsee> it's a security upload
<Hobbsee> yeah, probably
<emgent> jdstrand ++
<StevenK> Ah
<emgent> Hobbsee, if you like know all secuirty update see u-hardened
<Hobbsee> emgent: i don't usually care - it's just that that has broken drupal
<cjwatson> it's on the -changes lists too
<emgent> uhm ?
<Hobbsee> dep wise
<emgent> broken drupal ? :Â°
<Hobbsee> The following packages will be REMOVED:
<Hobbsee>   apache2-mpm-itk drupal5 libapache2-mod-php5 php5 php5-gd php5-mysql
<Hobbsee> The following packages will be upgraded:
<Hobbsee>   apache2-utils apache2.2-common linux-libc-dev
<Hobbsee> 3 upgraded, 0 newly installed, 6 to remove and 0 not upgraded.
<emgent> Hobbsee, gutsy?
<Hobbsee> emgent: yes
<Hobbsee> hm, apache2-mpm-itk probably needs a rebuild
<emgent>  possible
<Hobbsee> that's the breaking dep, on apache2.2-common
<scolytus> Hi! I've asked in #ubuntu, but didn't get an answer and i want to support you. I've installed Ubuntu 7.10 Server. There was a bug related to GRUB/MBR. What do you need for a bug report?
<emgent> keescook, ping
<emgent> sabdfl, heya
<sabdfl> hi emgent
<Hobbsee> hi sabdfl, how's it going?
<sabdfl> Hobbsee: good thanks, am on holiday in Rio, for Carnival, then off to work in CT for two days
<sabdfl> how's life down under?
<ion_> http://etymonline.com/index.php?term=carnival âto remove meatâ
<Hobbsee> sabdfl: wow! they give you holidays?  Rio sounds like fun
<Hobbsee> sabdfl: wet.  and thieves suck.
<emgent> ehehe
<sabdfl> sounds like rio, but somehow everybody manages to have fun nonetheless
<slangasek> ion_: a disputed etymology, fwiw
 * jdong waves at sabdfl :)
<sabdfl> hi jdong
<jdong> ok, can some Moin expert explain to me why "wiki.ubuntu.com/interdiff" does not suggest "wiki.ubuntu.com/Interdiff", but instead suggests things like "HintedFonts" and "Littleiffel"???
<jdong> though HintedFonts was a very informative read.
<TheMuso> c
<TheMuso> wrong tab...
<pitti> Good morning
<StevenK> Morning pitti
<TheMuso> Morning pitti.
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
<stgraber> moin
<slytherin> Can anyone please sponsor the debdiff on bug 183164. I am waiting for it to fix the FTBFS for lucene2.
<ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
<Company> bryce: are you the right person to poke about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/147846 ?
<ubotu> Launchpad bug 147846 in xserver-xorg-video-ati "resolution out of sync with version 2:1.3.0.0.dfsg-12ubuntu8" [High,Incomplete]
<seb128> Company: he might be sleeping now, you can try on #ubuntu-x though
<Kalamansi> seb128 : sebastian?
<Company> seb128: will do
<seb128> Kalamansi: no
<seb128> Kalamansi: did you have a question out of mispelling my name on irc? ;-)
<lucas> q!
<lucas> oops
<Kalamansi> seb128 i thought you are sebastian
<Kalamansi> seb - sebastian
<seb128> did you have a question or you just try to guess people names there?
<Kalamansi> actually yes
<Kalamansi> i have a Q
<seb128> you should ask then
<Kalamansi> any good sources for traffix shapping+blocking porn sites+filtering?
<India7> http://forceindiaf1.freeblog.hu/
<Kalamansi> India7 : i have better than than http://www.osnews.com/images/comics/wtfm.jpg
<Kalamansi> traffic*
<seb128> Kalamansi: you should try #ubuntu for user questions
<Kalamansi> thanks
<mvo> pitti: sudo has changed in hardy and now filters out everything in the environment that is not in the whitelist. this breaks the current way that gksu passes the proxy (via http_proxy)  bug #181999 seems to be caused by this. I would like to add http_proxy to the environment whitelist, is that ok with you?
<ubotu> Launchpad bug 181999 in apt "[ubuntu hardy alpha 3] update behind proxy - connections time out " [High,Confirmed] https://launchpad.net/bugs/181999
<pitti> mvo: can we fix gksu instead to explicitly keep that variable?
<mvo> pitti: fix it in what way?
<mvo> pitti: gksu talks to gconf, extracts the proxy, sets the environment and then calls sudo
<mvo> pitti: this way the proxy information is preserved for the app running as root (e.g. synaptic)
<pitti> mvo: hm, I thought sudo had an option to keep a particular environment variable
<cjwatson> it doesn't seem to
<cjwatson> I was looking for that the other day
<pitti> seems you can either use -E (not advised)
<pitti> or sudo VAR="$VAR" command
<pitti> it should have a "sudo --keep-env VAR command" option
<cjwatson> shame -E -e -K -k -P -p are all already used
<pitti> mvo: ATM I think calling it with http_proxy=$http_proxy is the easiest method
<mvo> pitti: its a bit ugly, but I can do that
<Riddell> pitti: coudl you give back kdegames-kde4 on amd64
<pitti> Riddell: done
<Riddell> thanks
<jdstrand> Hobbsee, emgent: apache2-mpm-itk is a universe package and needs to be rebuilt
<jdstrand> (apparently)
<jdstrand> I'll get to it today
<geser> yes, apache2-mpm-itk needs a rebuild for every apache2 upload
<Hobbsee> jdstrand: cool, thanks
<jdstrand> Hobbsee: sorry about that. I'll make a note in our qa-regression-tests on apache2 so this won't happen again
<Hobbsee> ok
<abarbaccia> hey all - im wondering how to appropriately file a bug in the ubuntu kernel - both gutsy and hardy have a problem finding all 4gb of ram on a desktop
<abarbaccia> HIMEM4G only lets you access 2GB of the ram but if you use the server kernel or roll your own using HIMEM64G then you get the full 4. It shouldn't be working like this...
<abarbaccia> So my better question is how do i label the bug so it gets identified correctly in launchpad
<persia> abarbaccia: I'd recommend reading https://wiki.ubuntu.com/KernelTeamBugPolicies and asking this type of question in #ubuntu-bugs.
<sistpoty|work> abarbaccia: iirc himem4g will indeed limit userspace to 2g (memory split), that should be normal (but I may be wrong... haven't digged into this for quite some time)
<abarbaccia> sistpoty|work: yes, userspace and kernel space should each be 2GB - but when you cat /proc/meminfo you should see all 4gb
<sistpoty|work> abarbaccia: yes, indeed
<Mithrandir> asac: do you happen to know if there are any plans to allow for allowing invalid security certs from the browser itself in ff3?  Having to go to preferences and add an exception is quite tedious.
<asac> Mithrandir: yes ... next upload will contain it
<asac> if you ask: when? ... i am waiting for beta3 which should be released pretty soon
<Mithrandir> asac: ok, cool, that's fine for me.  I don't mind waiting a bit, I just didn't want us to end up with a usability problem.
<seb128> asac: will that also fix the epiphany issue?
<asac> seb128: unfortunately not ... i plan to fix epiphany features after FF (as upstream apparently doesn't care much 'bout 1.9 :()
<seb128> ok
<\sh> moins
<\sh> pitti, octave3.0 transition, I think you forgot some packages from the buglist ;) could I send them to you on irc, so you can sync them directly, and the bug is closed? :)
<pitti> \sh: yes, fine for me
<\sh> pitti: cool...
<ScottK> Is the tag "apport-crash" enough for something to get retraced or to I need to add another tag to the bug?
<seb128_> ScottK: need-I386-retrace or the corresponding architecture variant
<warp10> Hi all!
<seb128_> hey warp10
<ScottK> seb128_: Thanks.
<warp10> hey seb128_!
<seb128_> SCottK: you are welcome
<jdstrand> Hobbsee: apache2-mpm-itk rebuilt and uploaded
<jdstrand> https://launchpad.net/ubuntu/+source/apache2-mpm-itk
<Hobbsee> jdstrand: \o/
<pitti> ScottK: hm, this seems to happen quite often now; broken python-launchpad-bugs, I assume (or people have old versions installed)
<ScottK> pitti: OK.  I've added the tag, so hopefully it'll produce something useful.  A crashing spamassassin isn't something I want to leave lying around.
<pitti> ScottK: SA? isn't that perl?
<pitti> or spamd?
<ScottK> It's perl.
<dholbach> bdmurray: can you prepare debian/changelog entries, so we can get new revisions of pylpbugs and bughelper uploaded?
<pitti> ScottK: oh, a crash in perl itself then?
<ScottK> pitti: It failed retrace.  It's Bug #189232 - are there any additional packages the reporter should install to get a better retrace if it recurs?
<ubotu> Launchpad bug 189232 in spamassassin "spamassassin crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/189232
<ScottK> So it appears.
 * soren hugs the sidebar patch for Mutt
<jdong> soren: what! what sidebar! why don't people tell me this stuff?
<geser> jdong: apt-get install mutt-patched
<soren> jdong: You didn't ask.
<geser> jdong: I hope you don't mboxes listed in mailboxes, as it does reread them on every occasion :( maildirs are better
<jdong> geser: I currently use imaps://, but I do have local access to the maildirs behind that :)
<geser> jdong: I use a mix of mboxes (for low-volume lists) and maildirs, every moving in the inbox made mutt to check all mailboxes for new mail
<jdong> hmm
<jdong> I had issues with maildirs in that mutt refused to check for new messages in the main folder listing view
<jdong> which is eventually why I hacked a dovecot server around it
 * pitti laughs -- "TypeError: communicate() takes at least 14155777 arguments (1 given)"
<pitti> now, *that's* what I call a rich API :)
<Keybuk> sounds like a relationship -- 14 million arguments
<dholbach> pitti: ROCK :-)
<dholbach> haha
 * pitti is still quite stunned what to do with that report
<cjwatson> sounds like a python-internal explosion to me :)
<pitti> yeah, I reassigned it to python2.5 as incomplete (needs reproducer)
<pitti> it'll probably just time out itself
<Lutin> Mithrandir: got a minute for a pkg-config question ?
<Mithrandir> Lutin: if it's quick, sure.
<Lutin> Mithrandir: yep :) . I was wondering .. now that Requires.private exists, what are the use cases for Requires ?
<Lutin> in .pc files
<emgent> CVE-2006-3636
<ubotu> Multiple cross-site scripting (XSS) vulnerabilities in Mailman before 2.1.9rc1 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3636)
<Mithrandir> Lutin: you might want to link in a static library, for instance.
<Mithrandir> (think the mozilla embedding thing)
<Lutin> Mithrandir: but requires.private is looked at when building static libs, isn't it ?
<Mithrandir> it is, but not the other way around.
<Mithrandir> and you can't include non-fPIC code in a shared library.
<Mithrandir> and you might have languages which don't have shared libraries or where they work differently than for C-based languages.
<thekorn> pitti: hi, I don't think Bug 163051 is a problem in py-lp-bugs,
<ubotu> Launchpad bug 163051 in python-launchpad-bugs "apport-retrace crashed with LPUrlError in _safe_urlopen()" [Undecided,New] https://launchpad.net/bugs/163051
<thekorn> I guess the reporter wanted to retrace a private bug,
<thekorn> and you can not even get the description of a private bug
<thekorn> when you are not logged in
<Lutin> Mithrandir: ahh ok. so if I got that correctly, when linking C code with shared libs, Requires.private can completely replace Requires ?
<pitti> thekorn: ah, good point
<pitti> thekorn: thanks for poitning out
<Mithrandir> Lutin: if you only have -l and -L flags, yes.  If you have -pthread, no.
<mynameisdeleted> hi
<mynameisdeleted> question question
<Lutin> Mithrandir: ok. thanks a lot for the explanation :)
<mynameisdeleted> my ide drive appears to be scsi in kernel, and wont let me use hdparm
<mynameisdeleted> I'd really like to be able to check dma status and readahead etc
<Mithrandir> Lutin: thanks for the question, I hadn't really realised how obsolete Requires is.
<Mithrandir> mynameisdeleted: please ask support questions in #ubuntu.
<Lutin> Mithrandir: :)
<mynameisdeleted> could the fake scsi driver for ide force it in nodma mode?
<Chipzz> mynameisdeleted: 16:15 < Mithrandir> mynameisdeleted: please ask support questions in #ubuntu.
<Chipzz> mynameisdeleted: and I think I heard something about sdparm
<mynameisdeleted> thats all I wanted
 * Chipzz wonders just how dificult it is to follow channel rules though - *especially* after they are explicitely stated
<davmor2> can anyone tell me the command to run oem complete please the icon appears to be missing from the desktop.
<cjwatson> davmor2: if you're running into bug 188240, chances are it's simply not installed
<ubotu> Launchpad bug 188240 in ubiquity "[Hardy] OEM install from Desktop CD doesn't work" [High,Fix committed] https://launchpad.net/bugs/188240
<Chipzz> dholbach: why did you mark https://bugs.launchpad.net/bugs/125247 as incomplete?
<ubotu> Launchpad bug 125247 in vim "Apache config files in /etc/apache2/sites-available and /etc/apache2/sites-enabled do not alwyas have proper syntax highlighting" [Undecided,Incomplete]
<Chipzz> I think all necessary information is provided?
<Chipzz> although I am willing to make a debdiff though
<davmor2> cjwatson: yes what's the package name and I'll finish this test?
<cjwatson> davmor2: oem-config-gtk but it will be broken if you just do that and it's really not worth trying
<cjwatson> you would have to do a fair bit of other setup duplicated from ubiquity
<dholbach> Chipzz: that'd be great
<davmor2> cjwatson: ah right okay np I'll just go for a standard install then and see if some of the gvfs/gio bugs have been worked out :) ta for the help
<Chipzz> dholbach: though, really, it's a one-line fix and the change is obviously correct; I don't see the point in making a debdiff ;)
<dholbach> Chipzz: it will speed up getting it included
<davmor2> cjwatson: just tried it to save reinstall and it worked just installing oem-config-gtk
<cjwatson> davmor2: mm, ubiquity does do more than that though
<cjwatson> I think it's great if it works, but it's not really a valid test :)
<cjwatson> ubiquity sets up autologin for the oem user for example
<davmor2> cjwatson: yes the autologgin worked.  It was just the means to save the changes and setup the new user I was missing.
<Chipzz> dholbach: debdiff needs to be against vim hardy version?
<dholbach> Chipzz: yeah, that'd help
<asac> doko: j2se1.4-amd64 doesn't build in hardy anymore :/
<doko> blackdown ...
<asac> doko: ... rules is broken as well ... a perl expression failed like: http://paste.ubuntu.com/4207/
<asac> doko: whats the state of icedtea in hardy? is it a viable replacement for 1.4 - so we can drop that?
<ScottK2> pitti: Do you have a moment for a postgresql-8.3 question?
<ScottK> Nevermind.  Figured it out.
<Riddell> pitti: please give back kdebase-workspace on amd64
<warp10> software released as "public domain" can be synced in universe, right?
<cjwatson> yes
<warp10> cjwatson: ok, thanks
<cjwatson> it depends slightly on the country, as in some countries you're not allowed to relinquish your copyright
<cjwatson> some people choose to add something that basically says "or the nearest approximation available" (but in better wording)
<ln-> it would be an interesting move from an PD author to sue people for copyright violation in such countries.
 * warp10 hates, hates, hates debian/copyrgiht
<Robot101> ln-: how about a code user in such a country sueing the author because it's unfit for purpose? :)
<slangasek> warp10: except for sauerbraten-wake6, which has to go to multiverse because of its /dependencies/, not because of its license...
<warp10> slangasek: indeed. I always check deps when I request syncs, but I missed that sauerbrauten is in multiverse :(
<slangasek> warp10: well, it would be exceptional that a package in Debian contrib should be synced to universe instead of multiverse, without there being a categorization bug on one side or the other :)
<warp10> slangasek: I am currently looking at glam2, in contrib, that is licensed as public domain and doesn't either depends or build-depends on software in multiverse or restricted. Shouldn't it go on universe?
<slangasek> warp10: er, glam2 isn't in contrib :)
<warp10> slangasek: damn... my flu confounds both my mind and my eyes. My apologies :)
<smagoun_> Can someone with a hardy system install totem-gstreamer and tell me whether the .so's are linked against libtotem-plparser-mini.so.10?
<jdong> can't that be checked by unpacking said deb and using ldd?
<smagoun_> jdong: I suppose so...
<pochu> smagoun_: http://paste.ubuntu.com/4211/plain/
<zyg2> sorry for asking here (ubuntu+1 seems idle) but have there been any package upgrades since alpha 4 release?
<pochu> zyg2: there are package updates everyday, but there haven't been a new release
<zyg2> hmm, that's what I find strange
<zyg2> I expected lots of packages rebuilt everyday
<zyg2> but I don't see any ...
<smagoun_> pochu
<zyg2> ahhh
<zyg2> I got it - I was using local country mirror that does not seem to pull hardy yet
<smagoun> pochu: thanks for the info
<pochu> Who is the hppa porter? lamont?
<ScottK2> Yes
<pochu> Thanks. I'll wait until he shows up.
<Riddell> Mithrandir: could you give back kdebase-workspace on amd64
<zul> soren: ergh
<soren> zul: Which version of mysql-doc-5.0 is installed right now?
<zul> 5.0-0ubuntu1
<soren> If a package has "Replaces: mysql-doc-5.0 (<< 5.0.56-0ubuntu1)", how does it make sense that it says "trying to overwrite `/usr/share/man/man1/mysql_config.1.gz', which is also in package mysql-doc-5.0", when trying to install it and mysql-doc-5.0 is at 5.0-0ubuntu1?
<soren> Shouldn't the "Replaces:" tell dpkg that it's fine for the package to overwrite it?
<mathiaz> Hum.. I've also updated the package version mysql-doc
<mathiaz> It was mysql-doc-5.0-0ubuntu1 - now mysql-5.0-5.0.56-0ubuntu1
<soren> Er..
<soren> How much of that is package name, and how much is version?
<Mithrandir> Riddell: done
<soren> slangasek: You're clever... Can you provide enlightenment here?
<mathiaz> soren: old version: 5.0-0ubuntu1 - new version: 5.0.56-0ubuntu1
<mathiaz> soren: see https://launchpad.net/ubuntu/+source/mysql-doc-5.0/
<soren> mathiaz: Ok.
<soren> mathiaz: I fail to see the point.
<luisbg> http://www.cs.helsinki.fi/u/hprajani/phun/disk.jpg
<mathiaz> soren: I don't have any point. It was just another comment regarding things that have changed.
<soren> mathiaz: Oh, ok.
<zul> ill try the replace+conflict we were discussing earlier
<slangasek> soren: the Replaces should indeed tell that it's ok to overwrite it; from what's said above, I don't see why this should fail
<mathiaz> Is there a way to tell which iso has been used to install a machine once the machine has rebooted ?
<soren> slangasek: Thanks so much. I thought I was going nuts. :)
<soren> mathiaz: Yes.
<soren> mathiaz: /var/log/installer/syslog
<soren> mathiaz: Or something to that effect.
<mathiaz> soren: ok. Thanks
<soren> zul: Could you please "dpkg -I mysql-server-5.0-blahblah.deb" and triplecheck that the Replaces field is set properly?
<zul> soren: Replaces: mysql-doc-5.0 (<< 5.0.56-0ubuntu1),
<soren> slangasek: We had a discussion earlier today about the necessity of adding the corresponding Conflicts: field (when a file moves from one package to another).. I couldn't come up with a good explanation as to why it's added, but looking through the archive, it's *very* common.
<slangasek> soren: there are two possible explanations for this. a) widespread misunderstanding of the meaning of the fields, b) if you have a package that Replaces: another but does not Conflicts:, and you install the replacing package and then remove it, the replaced package will still be 'installed' but will have some of its files magically missing
<soren> slangasek: Ah, yes, of course!
<soren> slangasek: Excellent point.
<slangasek> soren: I don't think the latter is likely to be the real explanation for why it's done, though, except perhaps by way of cargo-cult copying, because very few of the people I've discussed this with had recognized this possibility :)
<slangasek> (and even once recognizing it, many maintainers seem indifferent to it)
<soren> slangasek: Heh :)
<smagoun> seb128: Hi, totem-gstreamer doesn't function without libtotem-plparser10. You closed bug 188133 on the issue saying it's already been reported. I couldn't find another bug on the issue though. When do you expect to push a fix to Hardy?
<ubotu> Launchpad bug 188133 in totem "totem lacks dependency: libtotem-plparser10" [Medium,Invalid] https://launchpad.net/bugs/188133
<stgraber> Does one of you know what could generate this : "[unknown] ASSERT: "i >= 0 && i < height()" in file image/qimage.cpp, line 1712" ?
<stgraber> Riddell: ^
<stgraber> it's from italc which I'm trying to integrate for the next Edubuntu and it's like the only remaining bug we have
<stgraber> (this one causes a segfaul on the client when the teacher computer start a demo)
<slangasek> seb128: do you know if anyone's working on bug #187328, then?
<ubotu> Launchpad bug 187328 in seahorse "seahorse: misbuild on 64-bit architectures due to missing ldap prototypes" [High,Confirmed] https://launchpad.net/bugs/187328
<seb128> smagoun: bug #181794
<ubotu> Launchpad bug 181794 in totem "Xubuntu's instance of totem fails (dup-of: 182231)" [Low,Invalid] https://launchpad.net/bugs/181794
<ubotu> Launchpad bug 182231 in gnome-desktop "[Hardy A3] libgnome-desktop-2.so.2 is missing" [Medium,Confirmed] https://launchpad.net/bugs/182231
<stgraber> http://paste.stgraber.org/141 <--- The backtrace
<seb128> smagoun: I'll have a look to it but it's low issue on my list since other things depends on the lib anyway in the standard installation
<seb128> slangasek: is there any hurry? I'll forward it upstream soon and it'll likley be fixed with next tarball, but feel free to do an upload if you want to get it fixed now
<slangasek> seb128: no particular hurry, it's just that seahorse is the last package in main depending on libldap2 and I'd feel really good about demoting or nuking that package after all these years :-)
<seb128> slangasek: well, it didn't fail to build so it should make no difference there
<seb128> no?
<slangasek> seb128: sorry, what do you mean?  seahorse hasn't been rebuilt at all against libldap-2.4-2 yet, because doing so without this source fix would cause a misbuild on amd64
<smagoun> seb128: Thanks for the info. I'm working on Ubuntu Mobile (which doesn't have the same set of packages as desktop), so I'd like to get a fix for Hardy. I can push a patch to LP, does that work for you?
<seb128> slangasek: ah ok, reading the bug I though it had but the result was buggy
<slangasek> nah, I reported it based on the detected misbuild on ia64/debian
<seb128> smagoun: I'll likely look at it soon, I think the bug comes from debian but you are welcome to fix the issue
<Biff> hi, dont know if this is the correct place to ask, but i have been quite annoyed at the command-not-found handler thingy which is implemented in python and is very slow (200-1000ms) to find a package, so i reimplemented it in c, and it is quite fast, is this interesting to get into ubuntu instead of the python version?
<Biff> it uses the same databases and stuff as the old one, its just the bash hook that is in c
<_MMA_> Biff: I would actually email the -devel and or the -devel-discuss mailing lists.
<_MMA_> https://lists.ubuntu.com
<Biff> and or? :-)
<_MMA_> Your question looks appropriate for both. -devel-discuss will go throught faster as its unmoderated.
<seb128> grrr at the linux network stack
<seb128> slangasek: I've opened the seahorse bug on bugzilla now
<Biff> ok, thanks
<TheMuso> Good morning.
<Biff> evening here
<seb128> who was speaking about the totem depends issue?
<Chipzz> slangasek: with my complete lack of official understanding of that rule, my guess would be the conflicts in most cases is a *versioned* conflict to force the upgrade to a version of the package that doesn't have the conflicting file anymore
<seb128> Chipzz: you want to use Breaks in such cases
<seb128> didn't read the question though
<Chipzz> seb128: 21:30 < soren> slangasek: We had a discussion earlier today about the necessity of adding the corresponding Conflicts: field (when a file moves from one package to another).. I couldn't come up with a good explanation as to why it's added, but looking through the archive, it's *very* common.
<seb128> Chipzz: or are you speaking about same contents in different binaries? in which case you want to use replaces
<seb128> ah
<Chipzz> seb128: conflict/replaces pair is common
<seb128> yeah, it's controversial whether it's right or not
<Chipzz> and the question was about what purpose the conflicts part served
<seb128> it allow to downgrade without issue
<seb128> which is not really a supported case so is not required
<_MMA_> seb128: I think it was smagoun re: Totem issue.
<Chipzz> seb128: but nice to have since you can downgrade manually I guess
<ScottK2> Chipzz: I think the key issue is if you want to force the old package uninstalled or not.   For the common case of renamed binary package you do.
<seb128> Chipzz: not really nice to have, it makes upgrades harder to calculate
<seb128> ScottK2: in such cases you sue conflicts,replaces,provides which is correctly supported
<Chipzz> seb128: so what would you do while testing a package you're changing? force stuff with dpkg --force-... ?
<smagoun> seb128: totem depends was me
<seb128> smagoun: ok, I've figured the issue, will upload tomorrow
<seb128> Chipzz: what do you mean? replaces is enough to install the new version
<smagoun> seb128: thanks, I appreciate it. was it just a missing libtotem-plparser10 dependency in the control file? (I tested such a patch locally and it worked for me)
<slangasek> Chipzz: yes, they are generally versioned conflicts; but in that case, the question is why use replaces at all instead of just the conflicts :)
<Chipzz> seb128: say you, as a package maintainer, are testing a new version of a package in which a file has migrated from one package to another; you can upgrade to test it, but if you want to subsequently downgrade to test a new version, what do you do?
<seb128> I do apt-get install --reinstall binary=version where version is the version I want to reinstall
<seb128> the issue is rather if you try to reinstall the package which has been replaced
<seb128> another issue is that when you downgrade the package you install the files which were replaced will not be copied there again, so you need to reinstall the other package too
<seb128> technically the conflicts are not required but they avoid those corner cases
<seb128> smagoun: no, that's a dh_shlibdeps call in the rules which is lacking
<seb128_> re
<seb128_> smagoun: no, that's a dh_shlibdeps call in the rules which is lacking
<seb128_> not sure if you received it before the disconnect
<jdong> thanks, ~ubuntu-archive for accepting clutch :)
<superm1> ~ubuntu-archive, why was wxformbuilder rejected?
<ScottK2> superm1: Usually they mail you.
<superm1> yeah i didn't get anything about it
<Riddell> seb128, slangasek: after doing backports mind and pass them through new or unapproved, there were ones that have been waiting there for three weeks
<Riddell> Hobbsee, pitti, Mithrandir: please give back kdeaccessibility-kde4 kdeartwork-kde4 kdemultimedia-kde4 kdenetwork-kde4 on amd64
<TheMuso> Woohoo. More pulseaudio esound compat layer bugs. :)
#ubuntu-devel 2008-02-06
<dn4> Is there a way to configure xorg in the development version?
<dn4> the dpkg-reconfigure xserver-xorg
<dn4> seems to be very minimal
<pochu> there's displayconfig-gtk
<ion_> Which does a good job of consistently breaking your xorg.conf. :-)
<pochu> hey, we don't need xorg.conf anymore! :)
<ion_> Mostly
<ion_> And i wish displayconfig-gtk knew that as well. :-) I admit, i havenât tried it for months, it may have improved a lot.
<tormod> displayconfig-gtk will probably be replaced, see https://code.edge.launchpad.net/~bryceharrington/gnome-control-center/multi-monitor-config
 * Hobbsee waves
<Hobbsee> Riddell: done
<zul> hi Hobbsee
<Hobbsee> hey zul
<JediMaster> Hi all, I'm not sure if I'm in the right channel for help on making .deb packages?
<superm1> hey Hobbsee
<RAOF> JediMaster: You'd be better off in #ubuntu-motu, probably.
<TheMuso> JediMaster: #ubuntu-motu
<JediMaster> thanks =)
<Hobbsee> hi superm1
<Hobbsee> how goes it?
<superm1> pretty well.
<superm1> and yourself?
<Hobbsee> yeah, going OK
<superm1> Hobbsee, i lied, i just got a new puppy, so i'm pretty excited :) http://www.flickr.com/photos/23258998@N04/sets/72157603857206524/
<Hobbsee> whooo!
<RAOF> Puppies!
<tjgillies> Anyone gotten the Ubuntu Certified Professional yet?
<glickster> hi, is anyone runnin ubuntu on a dell latitude 830?
<ScottK> glickster: Support in #ubuntu or #ubuntu+1
<ScottK> Very few people here this time of day in any case.
<glickster> k thanks
<Aloha> why are hard drives listed as /dev/sd* on ubuntu even if they are ATA drives?
<TheMuso> Aloha: Because a lot of the IDE controller drivers in the kernel have been ported to use libata.
<slangasek> because the trend in the Linux kernel has been that all hard drives are being moved into a single subsystem, derived from the SCSI subsystem
<TheMuso> as far as I understand it anyway
<slangasek> (libata, yes)
<TheMuso> slangasek: Thanks for the better explanation.
<Aloha> im studying for LPIC-1 so it was kinda confusing because its hda based heh
<TheMuso> Not all drivers have been changed however.
<Aloha> i was like ... there is no /proc/ide
<TheMuso> The IDE controller in my mac mini still uses hd devices, as well as a highpoint controller driver in another machine.
<StevenK> TheMuso: Actually, there are new drivers that use libata.
<StevenK> TheMuso: Which is suspect is a port of the old one.
<Aloha> TheMuso, so its the naming convention is based on what your hardware uses?
 * StevenK goes back to hiding
<TheMuso> StevenK: Hrm I thought they just hadn't been ported.
<TheMuso> I've never really dug into it however.
<TheMuso> It just works, thats all I care about.
<Aloha> TheMuso, i.e. my drive shows up as /dev/sda because it was manufactured that way?
<StevenK> Aloha: It's the controller, not the drive.
<TheMuso> Aloha: I don't know
<Aloha> StevenK, is the controller part of the drive, or is it a BIOS thing?
<TheMuso> I was just pointing out an observation.
<StevenK> Aloha: Neither
<Aloha> StevenK, oh, a kernel thing?
<StevenK> Not that either
<StevenK> Aloha: It's a device that hangs off the south bridge
<Aloha> StevenK, then what kinda thing is it?
<Aloha> StevenK, south bridge?
<StevenK> An IDE controller is just another device, like a video card
<Aloha> StevenK, is it on the motherboard?
<StevenK> Aloha: In 98% of cases, yup
<RAOF> Not necessarily, but all modern motherboards incorporate at least one controller.
<StevenK> Which means it turns into a connector (or more) and a few chips
<Aloha> StevenK, so its my motherboard thats telling ubuntu that i have a scsi drive?
<TheMuso> Upon researching my new machine, I have seen boards with only one IDE port now.
<ScottK> I'm looking at an application (scribus) where we take the .desktop strings that get translated and copy them into the .pot file and then add an Ubuntu specific gettext domain to the .desktop.  My question is: Does the Debian toolchain support doing it that way, do they not care, would it at least do no harm.
<StevenK> TheMuso: That started about nine months ago
<StevenK> TheMuso: When SATA started getting popular
<ScottK> The looks like the only potential barrier between us and a sync.
<RAOF> Aloha: Nothing is telling Ubuntu that you've got a scsi drive.
<TheMuso> StevenK: Well I've not really been following
<StevenK> Aloha: It isn't a SCSI drive, it's just named that way
<TheMuso> Yeah well the board I'm looking at has 8 sata ports.
<RAOF> Aloha: The kernel is *naming* that drive like a scsi drive because *everything*'s going to be named like a scsi drive.
<StevenK> TheMuso: That expands out to two SATA controllers
<RAOF> TheMuso: Wow.  More than last I checked.  A bunch of those would be fakeraided together, yes?
<TheMuso> StevenK: Yeah, 6 for 1, and 2 for the other I think, from reading specs.
<Aloha> RAOF, gotcha. is that because canonical wants it that way or because thats how the kernel is set up?
<TheMuso> RAOF: If you choose to use them that way, yes.
<RAOF> Aloha: It's an upstream kernel decision.  Everything's moving from the IDE subsystem to libata, and libata names drives sd?
<Aloha> RAOF, oh... i get it. so whatever distro's kernel uses libata then that distro will name their drives /dev/sd*, correct?
<RAOF> Unless they do something crazy, yes.
<ion_> AFAIU the goal is that all disk access will be abstracted behind an unified interface. The sd* naming is just a side-effect of that.
<StevenK> Well, it means you have SCSI and then libata on top
<Aloha> is there a file for disk geometry like /proc/ide/hda/geometry?
<RAOF> Probably.  Why don't you ferret around inside /proc? :)
<TheMuso> Can't hdparm get that kind of stuff?
<Aloha> find . -name "*geo*" returned nothing
<Aloha> oh hdparm -g
<Aloha> TheMuso, thnx
<TheMuso> Aloha: np
<Aloha> ibm developerwork LPI tutorials are really good
<emgent> debian #464170
<ubotu> Debian bug 464170 in wordpress "wordpress: security flaw in xml-rpc implementation" [Grave,Fixed] http://bugs.debian.org/464170
<pitti> Good morning
<pitti> ScottK: postgresql-8.3> what was it?
<pitti> Riddell: give-backs> seems that Hobbsee beat me to it
<ScottK> pitti: I sorted it out.  It was needing to backport postgres-common too.
<pitti> ScottK: ah, backports; yes, you need -common
<ScottK> pitti: You've got a backport for Feisty/Gutsy waiting for you or whichever archive admin gets to it first.
<pitti> ScottK: do I need to bump the dependency to it?
<pitti> or what was the trouble?
<pitti> (i. e. it didn't work, but it did with a newer -common?)
<ScottK> It worked with the newer common.
<ScottK> It won't go back to Dapper though due to cdbs version needs.
<pitti> ScottK: right, and due to the python packaging policy
<pitti> ScottK: what broke with the current dependency version?
<ScottK> I didn't get that far.
<ScottK> It wasn't present in sufficient version and I don't know enough about postgres to really look at if a source backport to Dapper would make sense.
<pitti> ScottK: I currently keep a manually maintained backport of 8.2
<pitti> ScottK: it would be no problem to do the same with 8.3 (technically)
<ScottK> If it's manual, I suspect it might be better to let the 8.3 package get some age on it first.
<ScottK> I don't guess you'd really want to do two.
<pitti> right, one would be better; I maintain 8.2/dapper mainly for Launchpad
<superm1> morning pitti.  i was wondering if you could tell me why wxformbuilder got rejected?  neither myself (the sponsor), or the packager got an email about it
<pitti> superm1: was it rejected yesterday?
<pitti> superm1: I never saw that package, if it was yesterday I think Riddell examined it
<superm1> let me check when.
<superm1> yeah it was yesterday
<superm1> i'll check with Riddell then when he's back around
<superm1> thanks
<pitti> zul: on upgrade I get a file conflict on /usr/lib/libblktap.so.3.0.0 which is both in libxen-3.{1,2}
<pitti> zul: yay for packages with bad sonames :/
<pitti> zul: I guess this library needs to be split out to its own package if it doesn't follow SONAME bumps, or it needs a forced bump
<dholbach> good morning
<emgent> hi dholbach
<ion_> Howdy-ho
<dholbach> hey ion_, hey emgent
<seb128> anybody here with acroread installed?
<tjaalton> pitti: is it reasonable to ask that apport crash files are readable by users? There's a bug open about it
<tjaalton> seb128: _o/
<seb128> tjaalton: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/183271
<ubotu> Launchpad bug 183271 in poppler "evince and kpdf fail to open a pdf which works in Adobe Reader 7" [Low,New]
<seb128> tjaalton: can you try to open the file attached there?
<tjaalton> seb128: sure, a sec
<seb128> tjaalton: apport files are readable by users at the moment alreadt
<tjaalton> seb128: ok, in that case I'll close it as fixed
<tjaalton> seb128: yep, works with acroread
<seb128> thanks
<seb128> tjaalton: you can read your own crashes, not the one from other users, is that what you expect?
<tjaalton> seb128: that makes sense
<tjaalton> it's bug 72665
<ubotu> Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665
<pitti> tjaalton: WDYM with 'readable'? except for the core dump they are just ascii
<tjaalton> pitti: that the user can look at the contents without sudo
<tjaalton> I have a compiz crashdump with mode 0000
<pitti> tjaalton: ah, that meaning of 'readable' :)
<pitti> tjaalton: they are usually 000 while the report is still being written
<pitti> so that the frontend doesn't try to read a half-written report
<pitti> but when apport finishes it chmods it to 0600
<tjaalton> oh ok
<pitti> tjaalton: it sounds like apport crashed in your case
<pitti> tjaalton: does the .crash file look complete? do you have an exception in /var/log/apport.log?
<pitti> tjaalton: I didn't see that bug, and I went through all apport bugs yesterday; what's the #?
<tjaalton> pitti: which one? bug 72665 was against xorg-server
<ubotu> Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665
<tjaalton> so perhaps apport failed in this case as well
<tjaalton> pitti: my apport.log only shows the "executable: /usr/bin/compiz.real (...) entry and nothing else about the crash
<pitti> tjaalton: got disconnected; did you say anything after '[10:23]  tjaalton| oh ok' ?
<tjaalton> pitti: ah, yes:
<tjaalton> 11:26 < tjaalton> pitti: which one? bug 72665 was against xorg-server
<ubotu> Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665
<tjaalton> 11:26 < tjaalton> so perhaps apport failed in this case as well
<tjaalton> 11:28 < tjaalton> pitti: my apport.log only shows the "executable: /usr/bin/compiz.real (...) entry and nothing else about the crash
<pitti> tjaalton: that particular bug seems useless, yes
<pitti> tjaalton: and it doesn't talk about the permissions being 000, just that it belongs to root (which is correct)
<tjaalton> pitti: yeah, closing
<tjaalton> pitti: so since the process is run as root -> crash file owned by root?
<pitti> right
<Riddell> superm1: https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/015359.html
<saispo> anyone have an idea or know how to fix the dot in console mode with an Ubuntu gutsy ?
<saispo> under a French keyboard i must use shift for doing a dot with the keypad...
<seb128> saispo: what happens when you don't use shift?
<saispo> seb128: nothing :/
<saispo> i try a dpkg-reconfigure console-data
<saispo> but not working :)
<saispo> seb128: have you the same things ?
<seb128> saispo: no idea, I'm using my laptop right now and I've no keypad there
<saispo> yes, same for me :)
<cjwatson> saispo: don't use console-data, it's dead as of edgy
<cjwatson> console-setup <- new world order
<saispo> ok, will try
<saispo> cjwatson: nothing :)
<cjwatson> saispo: grep XKB /etc/default/console-setup; what's the output?
<Mez> doko_: you're the on handling coreutils for ubuntu atm ?
<doko_> the same way as every core developer does
<Mez> doko_, ah - I was only wondering as you're the last changelog.
<Mez> doko_, I dont have access to a debian system at the moment, but I noticed that in ubuntu the /usr/share/locale/*/LC_TIME/coreutils.mo symlinks are all broken
<saispo> cjwatson: hmmm query ?
<cjwatson> saispo: sure
<doko_> Mez: probably a version mismatch with current langpacks? pitti?
<Mez> doko_, no idea - I'm just running a test on my system for broken symlinks
<pitti> doko_, Mez: ah, it seems to assume that ../LC_MESSAGES/coreutils.mo exists
<pitti> which isn't true with langpacks (it's in /usr/share/locale-langpack, not /usr/share/locale/)
<cjwatson> maybe the langpacks should ship the LC_TIME symlinks
<cjwatson> seems pretty messy to symlink from locale/ll/LC_TIME/coreutils.mo to ../../../locale-langpack/ll/LC_MESSAGES/coreutils.mo
<Mez> also found a typo in libsnmp
<pitti> cjwatson: I agree
<ogra> cjwatson, was thre a decision about putting users into fuse by default with hardy ?
<ogra> i think it would make sense to have it in the default groups adduser uses to avoid all these issues
<ogra> (instad of having a notification)
<cjwatson> adduser doesn't have default groups; user-setup does
<cjwatson> somebody filed a bug on user-setup asking for that, although they mentioned several other groups in the same bug
<cjwatson> I'm open to opinions - it sounds fairly reasonable to me but I'm interested to hear if anyone has contrary opinions
<ogra> should put it on e meeting agenda ?
<cjwatson> what security vulnerabilities, if any, does being in that group open up?
<cjwatson> yeah, that sounds like a good idea actually
<ogra> full access to dev fuse ....
<ogra> which means you can do all nasty stuff through hacking togther your own fuse userspace tools
<cjwatson> right, I know, but for instance there is presumably a reason why that isn't just open to everyone
<cjwatson> I'm wondering whether this is like group audio or like group disk
<ogra> fuse has a lots of power
<cjwatson> the former shouldn't be open to everyone, but it makes complete sense for the default user to have it
<ogra> rahe disk i guess
<ogra> *raher
<ogra> gah
<cjwatson> the latter lets you shoot yourself in the foot and so we do not even give it to the default user
<ogra> well, you *can* have full access to any filesystem through a userspace toolou write ourself ...
<ogra> grmbl
 * ogra beats his wireless keyboard
<cjwatson> err
<cjwatson> are you saying that fuse lets you read/write to a filesystem that's on a block device not otherwise mounted anywhere that you do not otherwise have permissions to use?
<cjwatson> as opposed to a loop-mounted file in your home directory, for example
<ogra> i think thats possible, yes
<cjwatson> or presumably let you create a filesystem as an ordinary user and put a set-id executable on it?
<cjwatson> or does it block set-id?
<ogra> no idea, really, that would need more info from a security person who knows a bit more on that level than me, but if i look at scott balneaves playing with ltspfs and sshfs it seems reasonable that you can easily write your own stuff to circumvent low level restrictions through going through fuse
 * Hobbsee wavse
<Hobbsee> pitti: yeah.  being an australian, that's easier
<pitti> hey Hobbsee
<ogra> i think you can work around access restrictions in userspace here but thats an unproven statement
<cjwatson> ogra: would you investigate these questions before the meeting, please? for example, for the latter, you could create a filesystem containing a set-id executable as root, and then mount it as an ordinary user and see if you can still escalate privileges using it
<cjwatson> I think we need more information before making a decision here
<ogra> good
<Mithrandir> ogra: uh, no, it doesn't work that way at all.  fuse runs as your user.
<ogra> Mithrandir, the module ?
<ogra> i know the top level does
<ogra> but that gains me access to low level functions i wouldnt be able to use directly
<Mithrandir> ogra: the file system itself, at least, yes.  I would think that fuse doesn't allow suid by default, anything else would be a gaping hole.
<Mithrandir> like what?
<cjwatson> Mithrandir: I think we need to check this :)
<ogra> Mithrandir, no idea, disks i couldnt access otherwise :)
<cjwatson> ogra: hmm, that does seem curious; opening the block device ought to be done on the userspace side
<ogra> i mean look at ntfs .... ntfs3g does exactly that, no ?
<cjwatson> ogra: ntfs-3g opens the block device from userspace
<cjwatson> (see ntfs_device_unix_io_open)
<Mithrandir> : tfheen@xoog ~ > /bin/ntfs-3g /dev/sda3 /mnt
<Mithrandir> Error opening partition device: Permission denied
<Mithrandir> Failed to mount '/dev/sda3': Permission denied
<Mithrandir> so that has to be invoked from a privileged process
<ogra> ok
<cjwatson> Mithrandir: what happens if you mount -t ntfs-3g /dev/sda3 /mnt?
<cjwatson> err, possibly fusermount
<ogra> mount wont let you :)
<ogra> right
<Mithrandir> and suid doesn't go across at least sshfs
<cjwatson> that could be just sshfs not implementing it though
<cjwatson> don't get me wrong, I think you're probably right, but I also think it deserves to be checked
<Mithrandir> how would it "not implement it"?  It's suid from the looks of ls.
<Mithrandir> -rwsr-xr-x 1 list tfheen 9066 2008-02-06 12:46 test*
<Mithrandir> : tfheen@xoog ~/iphone > ./test
<Mithrandir> 1000
<Mithrandir> : tfheen@vuizook ~ > ./test
<Mithrandir> 38
<cjwatson> Mithrandir: sshfs has a method somewhere that returns the permissions set on the file
<cjwatson> it has to figure out what those are on the other end of ssh
<cjwatson> it could easily decide only to care about mode&0777
<Mithrandir> wouldn't then ls not list it as suid?
<cjwatson> http://lists.planet-lab.org/pipermail/devel/2006-November/001831.html <- possibly relevant
<cjwatson> Mithrandir: oh, I thought you meant that that was native ls
<cjwatson> ok
<Mithrandir> oh, sorry, it was through sshfs, yes.
<Mithrandir> and even with -o suid it's still mounted nosuid,nodev
<cjwatson> (the oops that the poster to planet-lab ran into is fixed in our current kernels)
<Mithrandir> that one looks like "fuse might have bugs", which given it's software, it's bound to have.
<ogra> right, but do we want it in the default groups with these possible bugs ?
<ogra> or do we want to go on to get 10-20 "permissions on /dev/fuse are wrong" bugs every release, from users that didnt grok they have to re-login after adding themselves to fuse
<cjwatson> I'm much less concerned about DoS possibilities (which we need to fix anyway) than about fundamental misdesign
<Mithrandir> ogra: the kernel probably has exploitable bugs in various syscalls too.  Or sudo.  Or any other piece of the stack.
<ogra> i'm only concerned about all that bugreports :)
<cjwatson> ogra: if you have a current open master bug about this, please reassign it to user-setup
<Mithrandir> cjwatson: agreed, and fuse doesn't seem to have fundamental misdesigns, afaict.
<ogra> the actual fix would be "instantly applying group membership" though
<Mithrandir> at least not from a security point of view.
<Mithrandir> ogra: that's hard, due to how UNIX works.
<ogra> Mithrandir, right ... well i have three options: notification afetr fuse-utils is installed, having all users in the fuse group anyway ... change UNIXs design :P
<cjwatson> leave the notification there, but we'll make it go away for the default user
<cjwatson> I think that's a reasonable compromise for hardy
<ogra> leave ? you mean add one :)
<cjwatson> I thought there was a notification at the moment
<cjwatson> in that case, I guess add one
<ogra> there is nothing atm
<cjwatson> though fuse is installed by default
<cjwatson> so perhaps a notification is unlikely to be all that useful
<ogra> we talked about it last week ... and i was looking into the bugs, what made me think about adding all users by default
<cjwatson> I am not comfortable with adding all users by default for hardy
<ogra> s/what/that/
<ogra> ok
<ogra> i'll add the notification so we cover te upgraders at least
<ogra> *the
<Mithrandir> would it be useful for the user to get a notification if his groups in the passwd file are different than for, say, gnome-session?
<Mithrandir> to me, that looks like something which could (and maybe should) be generalised.
<ogra> hmm
<soren> Where can I find the info that used to live in /proc/bus/usb/devices ?
<persia> soren: Some of it is in /sys/bus/usb, and the rest is no longer directly available.
<ogra>  /sys/bus/usb/device
<persia> soren: The discussion in bug #156085 may provide more information
<ubotu> Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Low,Confirmed] https://launchpad.net/bugs/156085
<soren> persia: That's the bug I'm working on fixing :)
<persia> heh
<soren> persia: I don't want to reenable usbfs.
<soren> persia: Aw, screw it. I'll teach it how to extract the info from sysfs. That's the sensible thing to do anyway.
<soren> I just wanted to check if it was already available somewhere.
<persia> soren: It wasn't available in November when I last hunted for it upstream.  Teaching the tools about /sys/ is likely better anyway.
<ogra> asac, i just had a QA tracker notification about a new firefox build to test from mozilla.qa.ubuntu.com, does that differ from our ff-3.0 package in universe ?
 * soren goes to lunch
<asac> ogra: http://www.asoftsite.org/s9y/archives/127-CALL-for-TESTERS-firefox-stabilitysecurity-RC-builds-need-QAfeedback.html
<asac> ogra: was the mail truncated for you?
<ogra> http://paste.ubuntu-nl.org/54981/ yup, apparently
<asac> ogra: those are QA builds for security updates of our stable releases ... so yes. they are about 1.5 (dapper) and 2.0 (edgy,feisty,gutsy)
<ogra> ah, right
<ogra> that info was missing
<asac> dholbach: pitti: i don't understand why the xml entities don't get installed in the same directory :)
<asac> i mean even the source has them in the same dir afaict
<zul> pitti: hmmmm?
<dholbach> slytherin, persia: asac seems to have some questions aout the change
<asac> and catalogs are only an sgml standard afaik ... no such thing officially exists for xml
<pitti> zul: the hmm refers to what? :)
<asac> if parsers support it ... fine ... but we cannot demand all xml parsers to know about catalogs
<slytherin> asac: Are you referring to the comment on Debian bug?
<zul> pitti: something about abi and soname?
<pitti> zul: well, you can't ship the same library in two different packages which don't Conflicts: to each other
<asac> slytherin: well ... i think the last comment is right. just install the entitites in the same directory as the dtds (the source ships them in the same dir after all)
<pitti> zul: and libfooX.Y packages should not conflict to each other
<zul> ill fix that today
<pitti> zul: libxen3.{1,2} violate the library packaging standard, because they ship sonames different from 3.{1,2} and thus generate file conflicts
<slytherin> asac: Yes, I am the one who made that comment. :-)
<pitti> zul: what's your feeling how this shuold be fixed?
<asac> pitti: dholbach: slytherin: i think we should install them in the same dir ... and then listen carefully for regressions in packages/software that does expect them in the current locations
<pitti> ack
<asac> w3c distributes: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd + http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent for instance
<asac> so same directory as well
<pitti> asac, slytherin: it shouldn't be too hard to check the reverse dependencies; there are only 5
<zul> pitti: add the conflicts and see about adding sonames or talking to upstream about it
<pitti> zul: please don't add Conflicts:, that'll break upgrades
<pitti> zul: as a Gross Hack(tm) you could have -3.2 Replaces: -3.1, but eventually this should be fixed properly by splitting out the library into a separate pacakge
<pitti> (IMHO)
<asac> slytherin: can you update the debdiff to just use the same location? and fix the catalogs accordingly?
<slytherin> asac: Ok. Will do. But then I don't have enough time to analyze the regressions
<zul> pitti: ok will have a look ill talk to soren as well
<pitti> thanks
<asac> slytherin: thats ok ... i will take a quick look if you bug me afterwards :)
<persia> asac: Might it be OK to ship with symlinks for now, and dig through the possible regressions later?
<slytherin> asac: I guess if I update catalog also then there shouldn't be much problem. I will keep my fingers crossed.
<pitti> persia: but they should be the other way round then (symlinks are in the old place, files in the correct one)
<asac> persia: when? i suspect that most rely on catalog so we most likely won't see regressions.
<asac> i am fine with what pitti says too
<persia> asac: the issue is that some packages FTBFS due to not finding things in the right place.  Moving them may result in a different set of packages FTBFS.  We don't see this from Debian due to local compile of arch:all.
<persia> pitti: Sounds perfectly sane.
<asac> persia: do we have a list of current FTBFS due to this?
<persia> asac: I only know about lucene2.  slytherin was investigating in more depth.
<slytherin> asac: persia: Even I know only lucene2 as of now. But the problem will be there for any app trying to use DTD directly
<slytherin> I can only comment about java apps though. Not sure about how C/C++ apps use the DTD
<asac> slytherin: http://paste.ubuntu.com/4246/ ... is that the error you refer to?
<slytherin> asac: That error is due to lucene2 trying to access DTD on internet. The error when trying to use local DTD is 'File not found' because it can not find entity sets
<asac> hmm ... but it would still fail on that internet access ... or is it a fallback because it couldn't resolve it locally?
<persia> The attempt to access the internet is a fallback from not finding it locally.
<asac> sure?
<slytherin> asac: persia: No. We are trying to use local DTD as solution to the connection problem on buildd.
 * persia reviews the build log again, somewhat confused
<asac> slytherin: how?
<slytherin> asac: we patch the lucene2 unit test to make it refer the local DTD and add w3c-dtd-xhtml package as build dep.
<asac> slytherin: hmmm ... have you tried http://xml.apache.org/commons/components/resolver/tips.html ?
<asac> to tell where the catalog is?
<asac> (e.g. patching system ids to refer to absolute local paths isn't much better ;))
<persia> That solution also needs an additional build-dep (which isn't necessarily bad)
<slytherin> asac: No I didn't try it.
<asac> no idea if it can work if lucene uses xerces directly (without commons)
<stgraber> asac: I'm looking at the tracker's log and see that you triggered a bug when adding a new build (at 12:46 and 12:47). Though I'm unable to reproduce, do you know what happened ?
<asac> stgraber: the only thing i know is that the mail got truncated (maybe thats the bug)?
<asac> thought i hit some max letters constraint or something
<asac> stgraber: UTC?
<stgraber> the bug is happening in the event handling part of the code but it's before the mail is sent
<stgraber> CET (UTC+1)
<asac> stgraber: hmm ... i added new milestone + new builds ... but i made a mistake when adding new milestone so i had to hide it without adding a build
<asac> maybe that?
<soren> pitti: How will splitting the library into a separate package fix anything? (re: libxen3.[12])
<stgraber> asac: btw, you could have just renamed your extra milestone :)
<asac> oh ... yeah. still need to get used to all the tiny tiny things on that page i guess :)
<stgraber> ok, so you added 3 milestones and then went to the Add build page
<stgraber> ticked Firefox, entered the version number and added, doing the same for the 3 milestones ?
<asac> more or less. i am not sure when i noticed the wrong milestone (i used the same version for gutsy as for edgy)
<asac> once i noticed it, i hid it and added the correct one
<asac> i didn't see an error page though. hmmm let me think. i think i added a build to a previously hidden milestone once too
<soren> zul: I don't think i understood completely yesterday.. Are libxen3.1 and 3.2 actually ABI incompatible? Doesn't 3.2 just add new stuff, but provides backwards compatibility?
<stgraber> ok, I tried to reproduce here with the latest changes I did and I'm unable to reproduce so it should have been fixed
<asac> stgraber: good!
<stgraber> asac: Do you have a link to the mail you sent earlier so I can see what went wrong with it ?
<asac> i try to remember more details on what i did next time :)
<zul> soren: it is backwards compatible I believe
<asac> stgraber: a link?
<stgraber> asac: yes, or just a copy/paste of the content
<soren> zul: In that case, I think we should build a libxen3 binary rather than a libxen3.2 one.
<asac> stgraber: not 100% the same ... but the content was similar to what i posted here: http://www.asoftsite.org/s9y/archives/127-CALL-for-TESTERS-firefox-stabilitysecurity-RC-builds-need-QAfeedback.html
<soren> pitti: What do you think?
<asac> stgraber: i did manual line breaks though
<stgraber> asac: Do you remember if the preview was correct ? (a preview of the mail is shown before it's actually sent)
<asac> stgraber: yes the preview was correct
<asac> thats why i had to do manual line breaks ;)
<asac> stgraber: i now see that it got chopped at the first |"|
<geser> could an build admin please give back: shogun. Thanks.
<asac> most likely an escaping issue i guess
<asac> stgraber: e.g. f you donât have time to do the full âtestplan from https://wiki.ubuntu.com/MozillaTeam/QAâ ... it truncated after "full"
<asac> the letter count and line count doesn't look suspicious so maybe its indeed the "
<stgraber> asac: ok, reproduced, it's indeed the "
<asac> great ... always happy to hit corner cases ;)
<stgraber> asac: I now have to find how I'm supposed to handle escaping with php's mail() function (I doubt I can use the same escaping as for the SQL)
<jwendell> seb128, Hi. The mouse scroll in touchpad is not working in Hardy. Is this an know issue? (Also the mouse capplet doen't have touchpad tab anymore)
<seb128> jwendell: no idea, that doesn't look like a GNOME bug and I don't know about xorg etc
<persia> jwendell: bug #173411
<ubotu> Launchpad bug 173411 in xorg "[Hardy][Regression] Touchpad vertical scroll does not work" [Medium,Confirmed] https://launchpad.net/bugs/173411
<jwendell> thanks, persia
<persia> Also, #ubuntu-bugs is a good place to ask about known bugs.
<jwendell> wow 12 duplicates :)
<asac> stgraber: why do you need to escape sql? do you concat strings? instead of using placeholders and setting the values (i presume that those two approaches exist for php as well)
<Mithrandir> geser: given-back
<asac> stgraber: like http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.php.doc/doc/t0023150.htm
<asac> stgraber: or http://www.petefreitag.com/item/356.cfm
<pitti> soren, zul: building libxen3 instead of 3.x> that sounds great (plus replaces:/provides/conflicts)
<soren> pitti: R/P/C of course. Business as usual :)
<pitti> soren: that's by far the best solution indeed, great
<soren> pitti: Cool. Thanks for your input.
<stgraber> asac: those are not the standard mysql functions you have in PHP (the first is object oriented and the second is about some db2 functions I don't have with mysql)
<asac> stgraber: you mean the second is object oriented and the first is db2 :)
<slytherin> asac: pitti: persia: FYI ... updated debdiff attached to bug 183164
<ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
<asac> stgraber: what is bad about using OO in php for prepared statements?
<stgraber> asac: yes, I haven't opened them in the order you gave them :)
<asac> :)
<stgraber> asac: we are using Drupal as backend and it's code is done using the standard mysql functions + some wrapper
<stgraber> so I'm basically using some db_* functions which then access the DB server (now postgresql, it used to be mysql)
<stgraber> so we'll use object-oriented as soon as Drupal also does
<asac> thanks for clarifying
<asac> slytherin: ok looks good ... have you tested that it fixes the build failure?
<slytherin> asac: Let me do it. I guess I will have to install it locally in pbuilder right?
<asac> slytherin: yes ... to be safe tear down your network during the build :)
<asac> let me know if the build succeeds. i would then upload
<asac> slytherin: i think just testing a build in your normal system without network should be sufficient as well (if you don't want to deal with pbuilder)
<slytherin> asac: I am patching the unit test to use local DTD. I don't think I need to disconnect from network.
<asac> slytherin: yes, thats why i said "to be safe" :)
<slytherin> asac: Ok. Let me install build deps first
<slytherin> I will be back. :-)
<gaspa> someone's going to fosdem, this month?
<stgraber> asac: problem found and fixed, the fix will be on-line with the next code update (probably today)
<geser> shogun FTBFS because it build-depends on python-numpy-dev which is provided by python-numpy and still a real package but NBS. apt tries to install the real one but python-numpy conflicts with it and apt reports broken deps. What the better solution: drop the build-depends or kill python-numpy-dev from the archive?
<asac> stgraber: rock!
<stgraber> asac: Ng just did the sync, so it's fixed on qa.ubuntu.com now
<slytherin> asac, lucene2 builds fine. :-)
<asac> slytherin: ok uploading
<superm1> thanks Riddell.  I'll make sure that gets taken care of.  sorry for the oversights
<zul> seb128: ping
<Iulian> Hi
<seb128> zul: no context ping no reply
<seb128> hey Iulian
<zul> seb128: sorry its yor archive admin day today correct?
<seb128> zul: yes
<zul> seb128: we need to get rid of all the xen related packages out of main except for libxen what is the process of doing that?
<seb128> zul: open bugs and subscribe ubuntu-archive
<zul> seb128: ok thanks..
<seb128> you are welcome
<seb128> or one bug with the list of packages to demote
<_MMA_> seb128: Hello. I was wondering if you updated the gdmplay issue? With it not being executable.
<seb128> hey _MMA_
<seb128> _MMA_: ah, right, let me fix that right now
<_MMA_> Awesome. Thanx.
<seb128> you are welcome
<Mez> what kind of database does dpkg use?
<Mez> (for dependencies)
<soren> Mez: I'm curious... why?
<Mez> soren, thinking about making lil playthings to query the database etc etc
<soren> Mez: I recommend you use the existing tools for that. It's a simple rfc822-ish text file, though.
<Mez> soren, more stats stuff
<Mez> soren, just curious about playing around
<Mez> soren, location?
<soren> Mez: /var/lib/dpkg
<Mez> yep, theres a lot of files in there
<Mez> I'm looking specifically for the deps stff
<soren> Mez: It depends on what you're looking for specifically.
<Mez> soren, dependencys
<Mez> s/y.ie/
<Mez> s/\./\//
<soren> Mez: You might want to look at the output from apt-cache dumpavail.
<Mez> soren, but where does that get it's info from?
<soren> Mez: /etc/apt/sources.list, /var/lib/apt/lists/
<Mez> so it reads directly from the cached packages files for all the dependency stuff?
<Mez> I thought it'd read from some sort of database...
<Mez> hmmles
<soren> apt-cache dumpavail reads from the cached PAckages files.
<geser> pitti, Mithrandir: shogun FTBFS because it build-depends on python-numpy-dev which is provided by python-numpy and still a real package but NBS. apt tries to install the real one but python-numpy conflicts with it and apt reports broken deps. What the better solution: drop the build-depends or kill python-numpy-dev from the archive?
<Mez> soren, when apt resolves dependencies (when you try to install it and it says "but I need this and this and this and this"
<Mez> that gets it from the cached packages too ?
<soren> Mez: Yes.
<soren> Mez: There is no binary database of any sort, if that's what you're looking for.
<Mez> soren - I see... I can forsee me having fun making it use a database ;)
<Mez> soren, I just think it might be faster and less resource intensive to query a database
<pochu> Has anyone noticed a slowdown on bootup with the 2.6.24 kernel (vs 2.6.22) for usplash to ask for the key?
<asac> calc: on?
<charles_> jamiemcc: ping
<jamiemcc> hi charles_
<charles_> hi
<charles_> jdong asked me to talk to you about https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/189439
<ubotu> Launchpad bug 189439 in transmission "Transmission should use a temp-dir to exclude from indexing" [Wishlist,Incomplete]
<charles_> the basic problem is that downloading huge binaries somewhere under the users' home directory seems to mix poorly with indexing :)
<Vadi> Imo, that's the trackers problems. It even indexes .part files.
<jamiemcc> charles_: yeah we are working on auto blacklisting files that change frequently
<charles_> the recommendation in that ticket is to download to a tmp dir instead, but I'm not sure storing downloads in a tmp dir is a good idea :)
<jamiemcc> charles_: we should be able to detect stuff thats chaniging too often in the next version
<charles_> cool
<charles_> how far away is the next version?
<jamiemcc> charles_: we are aiming for feb 14th - the ubuntu feature freeze
<charles_> oh, that's great news
<charles_> I'll annotate the ticket with that information
<jamiemcc> charles_: ok thx
<charles_> thanks
<jdong> jamiemcc: what would be the "cost" of such detection and does it work against slowly trickling torrents?
<jdong> jamiemcc: for example, a torrent with 10 700MB files, all are preallocated at the beginning, then maybe only 2 or 3 are actively downloading at a time
<jdong> jamiemcc: does that mean tracker will detect 6 unchanged 600MB blank files and try to index them?
<jamiemcc> jdong: yes unless we can ignore them
<jdong> jamiemcc: is there currently an API/command for an application to tell tracker to ignore a certain path, then later unignore it?
<jamiemcc> jdong: not at the moment - but it is a good idea
<Vadi> While we're on this, can it ignore .part files? Those that are being downloaded. It makes tracker get stuck on them.
<jdong> jamiemcc: I mean, the modification exclusion is a good thing (tm) but an API like this will be more useful for P2P and other harder to detect corner cases
<jamiemcc> Vadi: sure - thats a good idea too
<jamiemcc> jdong: I agree
<charles_> jamiemcc: the API call to say "ignore this directory" is essentially what Transmission does for Time Machine on OS X
<jamiemcc> charles_: I will see if i have time to squeeze that in before feature freeze
<jdong> jamiemcc: in addition to ignore this directory (recursively), it'd be nice if it also accepts "ignore this file"
<jdong> though of course that adds a design question as to how the unignore command should work
<jamiemcc> jdong: yes agree
<charles_> I like the idea of trackerd auto-detecting better though...  fewer ways for the clients to screw things up
<jamiemcc> charles_: yes thats the plan - if you know any file patterns that should always be ignored then let me know
<jdong> charles_: well autodetecting is a good initial barrier and should be used but it cannot be expected to detect ALL cases to ignore indexing
<jamiemcc> charles_:  jdong: i have to shoot off for an hour - email me jamie.mccrack@gmail.com any toughts
<jdong> charles_: which is why an API is a nice option for applications that can slip by :)
<calc> asac: yea
<calc> asac: whats up?
<asac> calc: openoffice.org -> xulrunner-1.9
<Vadi> Does Ubuntu 6.06 use the 2.4 or the 2.6 kernel?
<asac> calc: how is firefox-dev used atm during build?
<asac> calc: could you take a look and give me pointers so i can drop some brief instructions on how to switch build-depends?
<calc> asac: ok, looking
<asac> calc: i see that rule defines --with-system-mozilla=firefox ... but couldn't see how the build system makes use of it
<calc> its done a bit differently
<calc> i'll privmsg it to you since its about 10 lines
<asac> calc: paste please :)
<asac> http://paste.ubuntu.com
<calc> asac: oh oops did it already
<calc> i'll put it up on paste as well
<asac> calc: didn't get any pmsgs
<calc> http://paste.ubuntu.com/4256/
<pochu> calc: you need to be identified to be able to /msg people :)
<asac> well ... i know that ... but still i don't know where the build system makes use of it
<calc> ah somehow freenode forgot i was identified
<calc> i hate freenode
<calc> it always forgets i am identified for whatever reason
<calc> asac: oh that, i'll have to look to see if i can find out where, the build system is a bit complicated
<asac> calc: at best just move it to xulrunner-1.9-dev while you are at it ;)
<asac> if you have specific issues i can tell you how, but you are more used to building ooo then i am i guess
<calc> ok yea i'll see what happens if i just change it over to xulrunner-1.9-dev
<asac> calc: it won't work ... if it works, you have done something wrong :) ... or the build-depends/depends are not needed (which would be even better i guess)
<asac> for instance the .pc files are named differently (at least some)
<calc> asac: ah ok, i will look into how it is used then first :)
<asac> right
<asac> i'll prod you later today ;)
<calc> so if the pc files changed is it even api compatible?
<calc> evand: had any time to look at the partition issue? ;-)
<evand> calc: probably not until FF at this point :/.  Lots of spec work.
<calc> evand: ok
<davmor2> guys libxen3.2 seems to be broken this is the error report in synaptic.  E: /var/cache/apt/archives/libxen3.2_3.2.0-0ubuntu3_i386.deb: trying to overwrite `/usr/lib/libblktap.so.3.0.0', which is also in package libxen3.1
<cjwatson> known
<cjwatson> (zul and pitti were talking about that earlier)
<davmor2> cjwatson: cool
<tjaalton> damn, the -intel driver I just uploaded is broken (hangs on xserver start at least on i965), could it be put on hold until a fix is released?
<tjaalton> hmm, actually, the patch I got works after all..
<tjaalton> so I'll just upload that
<asac> calc: api compatible - depends on what kind of api ooo uses
<Lutin> pitti: can you give-back kdenlive please ?
<asac> calc: figure that out and i can give you more info :)
<pitti> Lutin: done
<Lutin> pitti: thanks
<calc> asac: ok
<geser> pitti: have you seen my question about the shogun FTBFS?
<pitti> geser: no, I don't think I did
<geser> pitti: shogun FTBFS because it build-depends on python-numpy-dev which is provided by python-numpy and still a real package but NBS. apt tries to install the real one but python-numpy conflicts with it and apt reports broken deps. What the better solution: drop the build-depends or kill python-numpy-dev from the archive?
<pitti> geser: if it's NBS, then I'd drop it in any case
<pitti> geser: but fixing the build dep would still be good
<warp10> Good evening
<pitti> hi warp10
<pitti> geser: I removed it
<warp10> hey pitti :-)
<geser> pitti: thanks, will do an upload later
<pitti> geser: oh, I just see that we don't have a delta yet
<pitti> geser: I'd say, don't worry about it; I'll just give it back tomorrow morning
<alex-weej> the archives are very slow...
<alex-weej> at least the UK one is
<alex-weej> 10 kb/s :(
<alex-weej> vs. well over 1 Mbit on other routes
<asac> doko: my local icedtea build works for me in ffox on amd64 ...
<asac> ?
<geser> pitti: ok, thanks
<doko> asac: hardy?
<doko> nice!
<ogra_cmpc> doko: many people on that bug colin pointed out said the same ...
<ogra_cmpc> i think the last commenter even suspected a discrepancy between soyuz and pbuilder
<doko> ogra_cmpc: hardy != gutsy
<ogra_cmpc> oh, right, sorry
<asac> ogra_cmpc: i have used pbuilder with buildd flavour ... no idea if that comes close to our soyuz though
<asac> but most likely it was a temporary bustage in some lib/compiler ;)
<ogra_cmpc> i'll send a test call out to the edubuntu ML tomorrow ... even though i think most of my users use 32bit FF on theior 64 bit servers
#ubuntu-devel 2008-02-07
<rtc> Did someone already fix the issue noted by Knuth in his "Flame About 64-bit Pointers" (http://www-cs-faculty.stanford.edu/~knuth/news.html)?
<rtc> Ah, found it in the bugtracker...
<Vadi> Quick question, but how does dependency resolution work when I remove a package? I ran into this problem - installed the emacs package, it for 67mb of other stuff. Removed it, and it only cleared 40kb of stuff.
<Vadi> I had to manually go into synaptic and remove the things it dragged in. Not good, because there's a ton of other programs that can probably leave packages about and I won't know about them...
<mahmoud_> !offtopic | Vadi
<ubotu> Vadi: #ubuntu is the Ubuntu support channel, #ubuntu+1 supports the development version of Ubuntu and #ubuntu-offtopic is for random chatter. Welcome!
<Vadi> Uh huh. Exactly which do I go to?
<mahmoud_> join #ubuntu
<Vadi> That's a support channel, I was already there.
<Vadi> I need a technical explanation, please.
<ScottK2> That doesn't make this a support channel, but in a console window do sudo apt-get autoremove and that'll get rid of it (assuming you aren't on Dapper).
<Vadi> I did it, but that didn't work.
<Vadi> It said everything was okay.
<Vadi> But, oh well, whatev. I'll file a bug report
 * Hobbsee waves
<RAOF> Howdie, Hobbsee!
<Aloha> whats a sprint?
<lifeless> its faster than a walk
<lifeless> sorry ;)
<Aloha> heh
<lifeless> in general
<lifeless> http://en.wikipedia.org/wiki/Sprint
<lifeless> but in Ubuntu
<lifeless> http://en.wikipedia.org/wiki/Hackathon#Sprints
<Aloha> lifeless, thanks :)
<Aloha> lifeless, what gathering are ubuntu sprints centered on?
<Aloha> oh ijust realized soyuz is russian for launchpad
<AfterDeath> Aloha: in the general sense, a sprint is using a burst of energy to run as fast as possible (unlike normal running, where you would run at a pace that would allow you to keep running for a long time)
<Aloha> AfterDeath, i know. i was wondering about software sprints. i used to run track
<AfterDeath> ah
<jdong> Aloha: sprint's an overpriced poor coverage north american cellphone provider :)
<Aloha> jdong, i use AT&T ;)
<superm1> jdong, well the nextel side of things is overpriced at least, but my coverage is great
<jdong> Aloha: I use AT&T too... it's great at my home in MI
<jdong> Aloha: but here on the MIT campus, I can freaking use Skype to make calls from more places than I can use my cell
<superm1> jdong, you need to hack together some sort of mic for the touch and then port over an SIP app
<superm1> thats a much better project than what you mentioned in -motu the other day :)
<jdong> superm1: well first I need to fix some.. er.. packaging issues.. with the MIT intro to EECS laptops :)
<jdong> superm1: my predecessor went kinda metapackage-happy....
<superm1> haha
<jdong> and to make matters worse, several metapackages contain VITAL INIT SCRIPTS
<jdong> :D
<superm1> running what distro?
<jdong> superm1: Feisty :)
<StevenK> !jdong
<ubotu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<jdong> Ubuntu is well loved around here
<superm1> jdong, just ditch feisty and port it all to hardy?
<jdong> the next version of the campus public workstation OS will be based on Ubuntu
<jdong> superm1: wish I can, but we use a proprietary kernel module atm
<StevenK> For what?
<jdong> superm1: fortunately, we have one bright student working on reverse engineering that
<jdong> StevenK: NIDAQ data acquisition box
<superm1> jdong, the module isn't available on newer kernels?
<jdong> the thing hardlocks and/or panics the kernel when it isn't happy
<StevenK> Nice
<superm1> jdong, to build against newer kernels that is
<jdong> superm1: from what I understand, it can give RMS heart attacks from 3 floors down
<jdong> :)
<Aloha> jdong, that sucks. i don't have to worry about coverage too much. I live on an island
<superm1> haha
<jdong> superm1: but yeah.... it is full of problems the least of which is we have to force-dep on the original released feisty kernel
<jdong> (YES... it's a BINARY kernel module....)
<superm1> oh that's really unfortunate
<jdong> there's no such thing as "compiling" 'round here :D
<superm1> you guys tried to contact NIDAQ?
<jdong> once this rev enged one kicks off, I'm gonna be happy
<jdong> superm1: I'm not sure, this is the first day I've been submersed into the inner world of the 6.01 course
<superm1> ah
<jdong> superm1: last term I served as a lab assistant primarily answering student questions on lab assignments and python code
<jdong> this term.... I'm kinda managing all the course laptops and stuff too
<superm1> jdong, but for the machiens that don't end up needing support for the data acquisition box, they could go to a newer release could they not?
<jdong> superm1: well they all will by the 4th week of labs
<jdong> superm1: as I said, upgrading Ubuntu is one of the smaller concerns
<jdong> right now, there's 4 padlocked RHEL lab workstations that are hardlocked
<jdong> the datestamp on one of them is 2000
<jdong> apparently it's padlocked so well nobody knows how to get in :D
<jdong> overall though it's a finely run class. Just shows how fun technology can be at times :D
<pitti> Good morning
<ion_> Hi
<Hobbsee> morning pitti!
<pitti> hey Hobbsee, hi ion_1
<slytherin> Hi all, we have latest kernel in repos linux-image-2.6.24-7-generic but linux-image-generic still depends on linux-image-2.6.24-5-generic. Is this a known issue? The reason I am asking is that the latest kernel fixes ibook boot issue on hardy but it won't be installed in standard upgrade.
<Hobbsee> slytherin: normal for a while, until each image has been out for a bit
<Hobbsee> slytherin: has linux-image-* built on all arches yet?
<Hobbsee> slytherin: and has l-r-m and l-u-m built on all arches yet?
<slytherin> Hobbsee: let me check
<mjg59> slytherin: linux-ubuntu-modules isn't built yet, I believe
<pitti> no, lum and lrm weren't uploaded yet
<slytherin> Hobbsee: hppa build for linux-image has failed, ia64 is currently building.
<Hobbsee> slytherin: the above 2 conditions are why, then
<slytherin> Thanks for info
<slytherin> I am also eager to check if the new driver manager handles broadcom 43xx devices because there is now a new driver.
<pitti> slytherin: not yet, but I think I'll manage to add one for b43 in the next week
<pitti> slytherin: can I ping you once it's ready, for testing?
<pitti> slytherin: would be great if someone could test it before I upload it
<TheMuso> pitti: Add me to that list also. I've a mini here iwth a b43 I think it is, so I'd be happy to help with testing also.
<pitti> cool
<TheMuso> Yeah, a BCM4306
<pitti> TheMuso, slytherin: I don't know anything about b43 and b43-fwcutter; from a clean install, is it enough to install b43-fwcutter and it does the rest? if not, which steps are necessary in addition
<TheMuso> pitti: All I need do after an install, is install fwcutter, and I think, it works from there.
<pitti> ok, great
<pitti> that should be easy enough, then I just need the detection
<pitti> TheMuso: do you have the current jockey installed?
<TheMuso> pitti: I plan on doing a fresh install in the next few days, so will try the procedure again. If its any different, I'll ping you.
<pitti> TheMuso: can you please do "jockey-gtk --debug --list >/tmp/jockey.log 2>&1"
<TheMuso> pitti: Just updating the box now..
<pitti> TheMuso: and send me /tmp/jockey.log? that should help me to verify the current detection
<TheMuso> pitti: Will do.
<pitti> awesome, thanks
<TheMuso> As soon as the mini update.
<TheMuso> updates
 * TheMuso gets dinner while waiting...
<slytherin> pitti: I will be happy to test. It is jut that I am not sure if the firmware needed with new driver is same as the old driver. Also the old driver is now blacklisted in favour of new one. I will do some manual installation over weekend needed to make the wireless work with latest kernel and then let you know.
<pitti> slytherin: great, thanks; maybe you can do the same --debug --list command that I asked above?
<pitti> slytherin: the handler will just detect if you have a broadcom wifi, and if so, install b43-fwcutter
<pitti> slytherin: if you need anything in addition, please tell me, so that the jockey handler can do it automatically
<slytherin> pitti: will do but I will have to wait for the kernel upgrade, right? because current kernel does not boot.
<pitti> oh :)
 * Hobbsee sighs at her connectino
<dholbach> good morning
<slytherin> pitti: this is specific to ibook only. related to some old ide drivers. By the way, bcm43xx-fwcutter is in universe. Shouldn't it really be in main and included in CD? because how are you supposed to install it if your connection is not working.
<Hobbsee> morning dholbach
<dholbach> hey Hobbsee
<pitti> slytherin: if it's not working, then it's useless anyway, because it needs to fetch the firmware from the net
<slytherin> pitti: You can have firmware saved locally. At least 'Restricted Manager' allowed using a local .so file.
<pitti> MacSlow: introducing ubuntu specific strings in patches is ok, as long as the package updates the POT during build
<pitti> MacSlow: if the package uses cdbs and gnome.mk, this will happen automatically
<pitti> slytherin: hm, true
<MacSlow> pitti, the packages in question are libwnck and gnome-panel
<pitti> MacSlow: if not, you have to call intltool-update -p
<MacSlow> pitti, that one I know
<pitti> MacSlow: ah, both use cdbs, and gnome.mk I suppose
<pitti> MacSlow: so, just patch the strings, and the POT and LP translations will automatically get them
<pitti> so that people can start translating them in LP
<MacSlow> pitti, for testing I've provided my own translation for de
<pitti> MacSlow: you can add your new translations as a patch, but IMHO it's easier to maintain if you just translate them in LP
<iiPing> lo
<stgraber> moin
<pitti> hi stgraber
<MacSlow> pitti, well since I cannot add anything to LP myself (in an official packages) I've to wait for seb128/mvo/you to sponsor/integrate my stuff
<iiPing> people i bump a lot, where can i find the ubuntu-app-developer for ubuntu channel?
<MacSlow> greetings carlos
<carlos> MacSlow: hi
<pitti> MacSlow: not? you should become a member of the German translation team then
<pitti> hey carlos
<TheMuso> slytherin: Actually, I haven't been able to boot recent 2.6.24 kernels on my mini either.
<TheMuso> As the mini has notebook components, I'd say they both use the same IDE chip.
<pitti> TheMuso, slytherin: FYI, I created the first version of the b43 handler, which should work at least in general; I'll do the testing/fine-tuning together with you later
<TheMuso> pitti: Sure.
<TheMuso> pitti: You should have mail from me sometime soon.
<pitti> \o/
<pitti> brb, testing new udev
<TheMuso> pitti: Actually, discard that. Seems the bcm43xx module wasn't loaded for some reason.
<slytherin> TheMuso: it is blacklisted in favour of new driver. check /etc/modprobe.d/blacklist
<slytherin> TheMuso: and the not booting problem is fixed in latest kernel uploads.
<TheMuso> slytherin: Yeah I'm using 7.11.
<TheMuso> slytherin: Is the newer driver in lum?
<slytherin> TheMuso: the driver is in kernel itself. But I am not sure which firmware it needs. Check dmesg, it should have some message related to b43 firmware
<mjg59> b43 needs revision 4 firmware. b43legacy needs revision 3.
<TheMuso> slytherin: Whats the module name
<mjg59> bcm43xx uses revision 3
<MacSlow> seb128, greetings
<seb128> hi MacSlow
<slytherin> and I guess b43 will need b43-fwcutter instead of old bcm43xx-fwcutter
<mjg59> The issue isn't the application
<mjg59> bcm43xx-fwcutter can extract version 4 firmware
<mjg59> But you need different firmware for b43 and b43legacy, and we need to support both
<mjg59> b43 can't drive everything bcm43xx can
<TheMuso> ah I see
<mjg59> It's made even more difficult by the latest hardware needing even newer firmware
<slytherin> damn, I thought bcm43xx chipsets are not used anymore.
<slytherin> TheMuso: by the way, the module names are b43 and b43legacy. But I am not sure which one handles which chipset
<TheMuso> slytherin: Yeah I worked it out.
<TheMuso> pitti: Oh ok, the one I sent you is the right one.
<mjg59> b43legacy handles old cores. b43 handles new cores. You can't tell from the PCI ID alone.
<TheMuso> Well on my mini, b43 gets loaded, and there is no firmware change needed.
<Iulian> Good morning.
<slytherin> mjg59: then how can one decide which to use if not from PCI ID? Or do we trust the autodetection?
<mjg59> Does it use the ssb bus implementation yet?
<MacSlow> *sigh*
<StevenK> MacSlow!
<MacSlow> can someone tell me what's wrong with the way I created http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch, which not apply to libwnck-2.21.90 when doing dpkg-buildpackage -rfakeroot ?
<StevenK> MacSlow: Can you pastebin the error you get?
<StevenK> MacSlow: It also doesn't patch configure
<MacSlow> isn't configure always generated when one starts a package-build?
<mjg59> No
<StevenK> MacSlow: Not always, depends on the package
<cjwatson> pitti: http://paste.ubuntu.com/4282/
<cjwatson> pitti: output of jockey-gtk --debug --list for me; no mention of b43, weirdly
<cjwatson> MacSlow: configure is in fact usually *not* detected to avoid build-depending on autoconf et al
<pitti> cjwatson: right, no ssb: modaliases, hmm
<cjwatson> which sometimes causes problems - generally regarded as better to have the maintainer generate that locally and verify that it's correct
<cjwatson> MacSlow: s/detected/generated/
<MacSlow> StevenK, pitti, cjwatson: http://paste.ubuntu-nl.org/55063
<pitti> cjwatson: does the b43 module get autoloaded for you? or did you stuff it to /etc/modules?
<MacSlow> StevenK, pitti, cjwatson: http://paste.ubuntu-nl.org/55063
<cjwatson> pitti: gets autoloaded, along with bcm43xx
<MacSlow> I created the patch for libwnck like this
<asac> calc: any info on ooo + xul yet?
<cjwatson> pitti: I had to blacklist bcm43xx to avoid problems
<pitti> cjwatson: right, bcm43xx is blacklisted by default now
<asac> cjwatson: i think latest update blacklisted it
<asac> ack
<TheMuso> cjwatson: My log didn't have b43 either
<cjwatson> MacSlow: there should be a log somewhere with the output of patch
<pitti> hm, so I wonder how b43 can autoload if /sys does not have the corresponding modalias
<cjwatson> MacSlow: it may be that you didn't generate it against the immediate parent patch, and collided
<pitti> MacSlow: unpack the source to a fresh and clean directory, cdbs-edit-patch 02_expose_wm_keybindings.patch, resolve the conflicts
<TheMuso> pitti, cjwatson, my ifconfig -a also gives this: http://www.pastebin.ca/894827
<TheMuso> This is with b43 autoloaded.
<mjg59> b43 doesn't use PCI modaliases
<mjg59> It uses ssb ones
<MacSlow> cjwatson, I guess you mean these http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch.level-0.log http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch.level-1.log http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch.level-2.log
<mjg59> ssb has the PCI modalias
<mjg59> Broadcom uses a bus called ssb - depending on what sort of host bus you have, the ssb bus will be bridged onto that
<StevenK> MacSlow: Yeah, that's them.
<StevenK> MacSlow: You probably have them locally now, too. :-)
<cjwatson> pitti: /sys/bus/ssb/devices/ssb0:0 is my Broadcom card, though
<mjg59> The PCI device is just a PCI to ssb bridge
<MacSlow> StevenK, of course
<mjg59> So ssb gets autoloaded, and then generates modalias events for the Broadcom cores
<MacSlow> StevenK, still I don't understand why that fails
<mjg59> pitti: Does that explain things?
<MacSlow> I did use cdbs and created the paches as always
<StevenK> mjg59: What does ssb expand out to? Wikipedia failed me.
<mjg59> Silicon Sonics Backplane
<StevenK> MacSlow: Because the patch doesn't apply for some reason.
<TheMuso> pitti: Mine is /sys/bus/ssb/devices/ssb0:0
<StevenK> MacSlow: Either too much fuzz, or failed hunks
<cjwatson> mjg59: ssb doesn't seem to expose modalias files in /sys
<cjwatson> which is what jockey is looking for
<mjg59> cjwatson: That's potentially the case
<mjg59> I'm in San Francisco right now, so I don't have access to a Broadcom right now
<cjwatson> MacSlow: level-1 is the relevant one; three failed hunks for some reason
<pitti> TheMuso: wlan0_rename> udev bug, I filed it a while back
<MacSlow> it drives me nuts when additional levels of "infrastructure" suddenly make my created patches not apply anymore
<StevenK> MacSlow: But it just runs patch ...
<pitti> mjg59: yes, thanks; I just need to find a way how to grab it out of /sys then
<TheMuso> pitti: ah ok. My mini is on ethernet, and I never use wireless on it, so thats alright for now.
<pitti> TheMuso: can you tar up your /sys and send it to me?
<TheMuso> pitti: Can do.
<pitti> TheMuso: if I cannot rely on moaliases, I need to find a b43 specific way of autodetection
<pitti> TheMuso: thanks muchly
<pitti> TheMuso: I'll do "moalias present" || "b43 ssb custom detection" then
<mjg59> pitti: The b43 and b43legacy modules do, at least, have the revisions they each support in them
<MacSlow> e.g. just running: patch -p1 <../02_expose_wm_keybindings.patch (while in a freshly grabbed libwnck-2.21.90 works flawless)
<StevenK> MacSlow: Ah ha. Then the first patch affects it
<pitti> mjg59: right; I hope I can pick out the vendor/product/revision IDs somewhere from /sys and compare it against the modalias lines from modinfo b43
<slytherin> pitti: in my case b43 got loaded automatically and dmesg had a message that it needs firmware. That is on ibook G4. But I don't have access to the machine right now so can not give more info.
<slytherin> pitti: I will be able to help on weekend though.
<MacSlow> StevenK, but I started cdbs with the first patch as parameter
<pitti> slytherin: thanks; if all goes well, I'll already have a handler to test for you
 * mjg59 sighs at the kernel
<MacSlow> even then it applied in the cdbs-session
<mjg59> It's being mean :(((
<StevenK> MacSlow: Wierd. I'd follow pitti's suggestion of using cdbs-edit-patch
<StevenK> mjg59: Show me on the doll where the nasty kernel touched you
<pitti> mjg59: (BTW, jockey does not only look for pci modaliases)
 * StevenK hides
<mjg59> pitti: Sweet
<pitti> . o O { and I thought that modalias paradigm would be a reliable standard nowadays... }
<mjg59> pitti: If ssb isn't exposing the modaliases in sysfs (it's certainly generating the uevents) then it probably needs fixing
<TheMuso> pitti: on its way
<TheMuso> brb
<pitti> TheMuso: cheers
<StevenK> pitti: Could I impose on you to process bug #189797?
<Hobbsee> bug #189797
<Hobbsee> ubotu: ping
<ubotu> ping yourself ;-) really the diodes all down my left side are sore
<pitti> *chuckle*
<StevenK> Hah
<Hobbsee> oh, LP is timing out
<Hobbsee> ubotu: go back to parking cars!
<pitti> StevenK: synced
<Hobbsee> [20:52] <ubotu> Error: I am only a bot, please don't think I'm intelligent :)
<StevenK> pitti: Thanks!
<StevenK> pitti: Can I bug you to let it out of binary NEW after it builds? :-)
<pitti> please bug me, yes
 * StevenK pastes that quote on the front page of wiki.ubuntu.com
<StevenK> :-P
<MacSlow> f**king crap!
<MacSlow> I did cdbs-edit-patch 01_workspaces_default_name.patch
<MacSlow> applied the patches to the .new-variant
<MacSlow> from that created the new patch-diff between .new and the origianal
<MacSlow> then I tried to apply the resulting patch against a fresh grab of libwnck-2.21.90 I also did cdbs-edit-patch 01_workspaces_default_name.patch for
<MacSlow> failed again
<TheMuso> pitti: I hope you can find something in there thats useful.
<soren> Could an archive team member please take a look at netcat-openbsd? Pretty please?
<pitti> TheMuso: aaah
<pitti> TheMuso: $ cat ./devices/pci0001:10/0001:10:12.0/ssb0:1/uevent
<pitti> MODALIAS=ssb:v4243id0807rev02
<pitti> TheMuso: did you tar this up as root or as user? and with -p?
<TheMuso> pitti: as user, without -p. I can do it again...
<pitti> TheMuso: as user is great
<pitti> TheMuso: can you please check the permissions of /sys/devices/pci0001:10/0001:10:12.0/ssb0:1/uevent on your system?
<TheMuso> pitti: -rw-r--r--
<pitti> cool
<TheMuso> -rw-r--r-- 1 root root 4096 2008-02-07 20:03
<pitti> mjg59: does it sound like a good idea to consider 'uevent' files which have a MODALIAS= line instead of/in addition to looking at 'modalias' files in /sys/devices ?
<ion_> dholbach: Dâoh, i knew i forgot something. Thanks. :-) (Re: the missing (LP: #...) in the changelog)
<mjg59> pitti: Erm. Can we guarantee that the uevent will only be the modalias?
<dholbach> ion_: no problem
<mjg59> Devices can generate arbitrary uevents?
<pitti> $ find /sys/devices -name uevent|xargs grep MODALIAS|wc -l
<pitti> 93
<pitti> $ find /sys/devices -name modalias|wc -l
<pitti> 93
<pitti> doesn't seem to make a differnence on my box
<mjg59> I haven't checked the defined smeantics
<pitti> TheMuso: I take it above commands deliver more results for the udevent line on your system?
<mjg59> But if it's guaranteed to always provide the modalias, then sure, just check that
<pitti> mjg59: well, to save a lot of file i/o I could probably just do it for the b43 module
<pitti> the other things we support (nvidia, fglrx et al) don't seem to need it
<pitti> or, generally just for stuff below /sys/devices/.../ssb*/...
<pitti> (that seems like the best option to me)
<hubuntu> hello guys.. Wil network manager 0.7 be included in hardy? to coupe with netman 0.65 for an LTS release is probably not the best idea?
<hubuntu> fedora 8 has it already and its rocking.... Will netman 0.7 make it before the feature freeze?
<cjwatson> hubuntu: at present it's unlikely since the rewrite doesn't look like it'll be in good enough shape for us by feature freeze
<cjwatson> although the decision is not final
<cjwatson> hubuntu: LTS is not, in general, an argument for switching to new versions of software that are a complete rewrite and are still as yet rather lightly tested
<hubuntu> then it will probably end in backports? I
<soren> Quite the contrary, really.
<cjwatson> backports obviously has a much less strict policy
<hubuntu> I know, I'm just all excited about 0.7 and been waiting for a long time for its inclusion... Will the gnome-obex-vfs be included by default? Phones and ubuntu work perfectly now with it, shouldn't it probably be included by default?
<hubuntu> it's just a shame that the bluetooth applet is there with the option to browse the phone and it just doesn't work out-of-the-box and has to be installed manually...
<seb128> hubuntu: obex has not been ported to gvfs yet so it doesn't work at all in hardy
<hubuntu> cjwatson: yeah, but backports are not supported...
<cjwatson> that's correct
<hubuntu> seb128: so we are going for gvfs and drop bluetooth support? Anyone thinking about blueman as an option? I do not know if it supports gvfs but it sure works better than anything else i have tried...
<hubuntu> ok then hardy+1 will be the one to fiunally bring VPN to the masses :)
<seb128> hubuntu: dunno about bluetooth
<slytherin> hubuntu: For bluetooth work you should probably keep a watch on this blog, http://www.hadess.net/ :-)
<asac> hubuntu: are you using my nm 0.7 packages from ppa?
<hubuntu> I have been giving it a try and things seem to work fine with several pcmcia cards
<hubuntu> d-link and netgear cards.. some with restricted drivers other with atheros and one with some open driver i don'Ã¦t remember
<hubuntu> wpa enterprise wortk like a dream
<hubuntu> ;)
<asac> hubuntu: do you have fedora?
<hubuntu> no
<hubuntu> well I've seen it
<hubuntu> and tried it a bit
<asac> ok ... would be curios to know if we lack some features compared to their release
<Hobbsee> ah yes, i need to try out the mangler again
<hubuntu> I am justthere was an update i haven't checked on fedora 8: http://liquidat.wordpress.com/2008/01/24/networkmanager-enterprise-encryption-eduroam-style-works-again/
<hubuntu> good work with those packages asac :) Netman really is the new Chuck Norris and you are the ubuntu Chuck Norris ;)
<hubuntu> that is logic, right?
<asac> lol
<slytherin> asac: which PPA has latest network manager?
<hubuntu> well it seems bluetooth got even better with gvfs :) - gnome-obex-send is dead, long live bluetooth-sendto. @ http://hadess.net gives me peace of mind
<hubuntu> his
<asac> slytherin: ~asac
<asac> slytherin: https://edge.launchpad.net/~asac/+archive
<slytherin> asac: oops I forgot, PPA doesn't yet support powerpc arch right?
<hubuntu> jo'er..
<asac> slytherin: nope ... you need libnl + wpasupplicant + nm + nm-applet iirc
<slytherin> asac: that means I will first have to set the pbuilder on my ibook and then build these packages.
<Hobbsee> asac: is it safe just to add the repo, or?
<hubuntu> asac you should follow this guy closely: http://blogs.gnome.org/dcbw/ But i guess that's old news for you...
<hubuntu> thanks for all your help :)
<asac> Hobbsee: for now you need to look what packages i have in there. I will use the ppa of ~network-manager team in future.
<Hobbsee> asac: right.  when will that change over?
<asac> Hobbsee: next time i upload a nm to ppa. not ETA yet
<Hobbsee> ok
<pitti> thekorn: current p-lp-bugs uses any() and thus crashes on python 2.4
<pitti> thekorn: would you mind if that was rewritten to be 2.4 compatible or shall we just hack it locally?
<pitti> thekorn: I just manually added a definition for any() to commentsbase.py now :)
<YokoZar> Is "Switch Page Direction" still on the right click menu for Hardy FireFox?
<Hobbsee> doesn't look like it
<TheMuso> pitti: Sorry, been on the phone. I'll run sed commands and give you the results.
<pitti> TheMuso: thanks
<TheMuso> pitti: 53 for the first find command, and 51 for the second.
<pitti> TheMuso: ok, then you have two which are undetected by scanning for modalias; I guess those are the two ssb ones
<pitti> TheMuso: when I'm done with wrestling with GTK, I'll tackle this to fix it generally in jockey
<TheMuso> pitti: No rush, I'm about to go to bed anyway, so feel free to email/leave an IRC message if further testing/commands are neded.
<pitti> TheMuso: I'll put your /sys layout of the ssb devices into the test suite
<pitti> TheMuso: I will, thanks (or ask slytherin)
<calc> asac: been working on apt/dpkg backporting
<asac> calc: ok, today?
<calc> asac: i'll try to get to it today, i'm still working on the backports but will get on the xulrunner stuff once they are done
<asac> backports?
<calc> asac: i'm having to backport apt/dpkg lzma patches (once i find them all) to dapper and edgy for the buildds/servers
 * calc is going back to sleep now, his son had woken him up :-\
<asac> calc: ok. sleep well
<thekorn> pitti: py-lp-bugs is supposed to work under py2.4, so I will remove this 'any'/'all' statements
<pitti> thekorn: ah, danke
<thekorn> gerne
 * torkel hugs pitti for finally fixing #148003
<pitti> \o/
<Ng> win 141
<pitti> Ng: >= 141 channels? wow, that's what I call a busy IRC client :)
<Ng> pitti: or a lazy irc operator. once I get past 19 windows and can't use the alt key anymore, it becomes irrelevant how many there are, so I just don't bother closing them ;)
<pitti> Ng: heh, that's why I try to keep them <= 10
<ion_> I use query autoclose.
<StevenK> pitti: With irssi you can use alt + q w e .... for above ten
<pitti> ah, neat
<Amaranth> ooh
<StevenK> Heh
 * Hobbsee likes alt+a
<pitti> alt+a is what I use for these, too
<pitti> since I already put commands on alt+letter
 * mjj29 has bound all the letters and numbers to channels
<ion_> I had all the letters bound to window change back in the day. Nowadays i try to limit the amount of channels. :-)
<mjj29> and alt-` for active-window
<ion_> I have tab bound to active window.
<mjj29> ion_: just tab?
<ion_> Yep
<mjj29> what about tab-completion
<ion_> I donât find it useful on IRC. In shell, it is really useful.
<ion_> (At least when you have a shell where you can type /u/s/d/compi/RE and get to /usr/share/doc/compiz-core/README with a small amount of keypreses)
<Mithrandir> ion_: it's useful for nick-completion, I find. I've pondered binding it to word-completion too, but suspect I'd develop zshenia in my irc client too.
<Hobbsee> Mithrandir: is this a problem?
<Mithrandir> Hobbsee: it wears out my tab key.
<StevenK> zsh users only need Tab and Enter anyway
<Mithrandir> on the other hand, I should be able to just bind all keys on my keyboard to tab and make do with that.
<ion_> Nicks are typically short, and i prefer to talk to somedude instead of _someDUDE77^ no matter which nick he chooses to use. Also, every so often you complete to the wrong nick and only notice it after hitting enter. :-)
 * StevenK high fives Mithrandir 
<Mithrandir> ion_: I'm lazy. :-P
<Mithrandir> and people suck at speling Mithrandir
<StevenK> pitti: fbreader hasn't built on ia64, if you can cope with that, could you let it out of binary NEW?
<Hobbsee> Mithrandir: and in the event of that, you then bind the tab function to your capslock.  problem solved.
<pitti> StevenK: done
<ion_> My caps lock is control, but iâve been considering making it an escape instead. :-)
<Mithrandir> mine's compose.
<ion_> My right hand WindowsÂ® key is compose.
<Mithrandir> laptop doesn't have a windows key, so. :-)
<Hobbsee> mine does.  you need a bigger laptop
<Hobbsee> or to bind it to right alt or something.
<Keybuk> my caps lock key is CAPS LOCK
<Mithrandir> I use right alt for random things.
 * Hobbsee used to bind things to insert, long ago.
<Hobbsee> Keybuk: yes, but you're boring :P
<ion_> I use the right alt mostly for â, â and â.
<Keybuk> about the only useless key on the keyboard for me is "Pause/Break"
<pitti> and the menu key for me; I have never used it
 * ion_ just noticed his âLogitechâ key opens a calculator. :-)
<ion_> An idea: make it open irb in a terminal!
<Mithrandir> I have a calculator key on my desktop keyboard.
<Mithrandir> and a house key.  And one with a letter (as in, what you put in a mailbox) on it.
<Amaranth> I have a calculator key on my laptop
<charles_> "By pressing down a special key It plays a little melody"
<Amaranth> It's handy, even enables numlock for me
<pitti> TheMuso, cjwatson: if you have a moment, could you please try running http://people.ubuntu.com/~pitti/tmp/detect-test.py and pastebin the output for me? it's the /sys walking ripped out of jockey, now with SSB support
<pitti> it passes my test suite with TheMuso's /sys layout, but I'd like to test it on real hw first
<cjwatson> pitti: http://paste.ubuntu.com/4287/
<pitti> cjwatson: rocking' that works; it even detects that the module b43 is linked to it
<pitti> cjwatson: thanks!
<cjwatson> np
<tbf> glatzor: since you packaged policykit for gutsy... do i have to take some special actions, before i can use policykit?
<tbf> glatzor: currently there seems to be no 'org.freedesktop.PolicyKit.AuthenticationAgent' service on the session bus
<glatzor> tbf: I only backported them from debian experimental some monthes ago
<tbf> glatzor: hmm. ok.
<glatzor> tbf: sorry, but I haven't looked at them for a time.
<tbf> thanks
<ScottK> pitti: I was wondering if there was any chance of MIR processing today?  I still have faint hopes of integrating amavisd-new in the mail server tasksel before feature freeze...
<pitti> yeah, that was my plan; I'll start after the team meeting
<pitti> ScottK: doko wanted to process some today, too
<ScottK> Thanks.  He seemed skeptical about amavisd-new.  I'd rather you looked at it. ;-)
<emgent> heya
<pygi> siretart, poke
<pitti> cprov, mvo: hm, the symlink should have been mirrored by now, but it's still not on a.u.c.
<mvo> pitti: ok, I will mail elmo then
<pitti> I guess symlinks pointing outside of /ubuntu don't work
<pitti> so I'll do a copy instead
<mvo> pitti: he mentioned that the mirror script used may not pick it up
<pitti> ah
<pitti> mvo: ok, please do that first then
<mvo> pitti: I will and will CC you
 * pitti hugs mvo
 * mvo hugs pitti
<dholbach> superm1: does this look interesting to you:  http://www.murrayc.com/blog/permalink/2008/02/07/gnome-lirc-properties-a-gui-to-configure-infra-red-remote-controls/ ?
<superm1> dholbach, yeah it looks quite interesting. It obviously won't take advantage of the patch that I'v got locally (upstream hasn't accepted it yet) for "include" files in lircd.conf
<dholbach> superm1: ah nice
<superm1> but that is going the right direction, and fairly similar to what upstream eventually had in mind
<superm1> dholbach, hopefully next cycle that person authoring that gets in contact with us and we can work together on making it fit well
<dholbach> superm1: that sounds awesome
<tseliot> superm1: did you read my email?
<tseliot>  dholbach: hi
<dholbach> hi tseliot
<superm1> tseliot, should I be reading someone else's mail :)?
<superm1> tseliot, ah yeah you were thrown in a different filter
<superm1> that's why I didn't see it
<tseliot> ok
<superm1> tseliot, that is with the latest public release?
<superm1> or with something else?
<tseliot> yep
<tseliot> and I also tried the tarball from phoro git
<superm1> tseliot, you're on list - can you please try with a testing release?
<tseliot> ok
<superm1> there has been a significant amount of changes to the packaging scripts between last month and the next upcoming one
<tseliot> I need to get Envy to work with it on Hardy
<superm1> right
<superm1> well that exact issue cropped up before due to the way that dh_shlibs was handling things
<superm1> and it should have been corrected within the last couple of weeks
<tseliot> I'm downloading the latest test release right now
<tseliot> superm1: let's chat in private
<superm1> okay
<Catachan> Hello, would this be the proper channel to ask abou how to change the color of the screen that pops up between logging in, and the actual Desktop?
<sistpoty|work> Catachan: #ubuntu
<Catachan> okay
<Catachan> thank you
<sistpoty|work> np
<pitti> doko: looking at amavisd MIR now
<doko> soren: could you have a look at kvm building with gcc-4.2?
<soren> doko: I'm realiably informed it won't work.
<soren> doko: Well, on i386, anyway.
<doko> soren: there are patches floating around, iiuc
<pitti> ScottK: just replied to bug 183418; would you mind doing the upload soon, so that we can actually promote it?
<ubotu> Launchpad bug 183418 in amavisd-new "MIR for amavisd-new" [High,New] https://launchpad.net/bugs/183418
<ScottK> pitti: Will do.  Thanks for the advice.
<ScottK> pitti: I'll upload it in the next 24 hours.  Up to my eyeballs in $WORK today.
<doko> pitti: looking at the pam/radius MIRs
<soren> doko: Only bad ones.
<soren> doko: Although..
<tgelter>  hey all, is it currently possible to use the nvidia driver with hardy?
<tgelter> I encounter errors when I try to install nvidia-glx-new. I also am unable to load the nvidia kernel module after a successful install of the driver straight from nvidia
<soren> doko: Fabrice (the qemu guy) wrote a new code generator that should alleviate the need for gcc-3.x. It's x86 only, so far, but that's all kvm should worry about.
<tgelter> oh, in relation to my comment about nvidia, I'm running x86_64 hardy
<soren> doko: I can check next week. This week is completely booked.
<doko> soren: thanks!
<soren> doko: er.. When was gcc-3.4 demoted to universe?
<soren> doko: That's a *Very* recent change, isn't it?
<doko> soren: no, was done at the sprint
<soren> doko: That counts as very recent in my book. :)
 * soren grumbles a bit
<soren> I mentioned kvm needing it on several occasions.
<pitti> tgelter: that's the same setup that I run here, and n-glx-new works fine for me
<tgelter> pitti: brb and then I'll have a question for you
<tgelter> pitti: pastebin.com/m34edd00
<pitti> tgelter: ah, that indeed does look like a packaging bug; tjaalton?
<tgelter> pitti: note that I upgraded from gutsy, this wasn't a fresh install
<pitti> right, or that
<tgelter> so what're my options?
<pitti> tgelter: can you please file a bug against linux-restricted-modules-2.6.24, including this output?
<tgelter> sure thing
<tgelter> wouldn't this indicate a problem with nvidia-kernel-common rather than linux-restricted-modules?
<pitti> tgelter: oh, sorry, indeed; it's a separate source
<tgelter> is there anything to explain why I can't load the nvidia kernel module after installing with the binary installer from nvidia?
<tgelter> is there a particular log I should be checking to see if modprobe is returning any errors?
<tgelter> ah, looks like someone else already created that bug report
<zul> pitti: around?
<slangasek> ember: any chance you can follow up on bug #187328?  Now that seahorse has been rebuilt against openldap 2.4, there's a potential for crashes on 64-bit archs in the LDAP code
<ubotu> Launchpad bug 187328 in seahorse "seahorse: misbuild on 64-bit architectures due to missing ldap prototypes" [High,Triaged] https://launchpad.net/bugs/187328
<ember> slangasek sure, thanks
<geser> does somebody know if gimp will stay at 2.4.3 for hardy or will it get updated to 2.4.4?
<geser> I try to figure out what to do with ingimp as it wants gimp < 2.4.3 and the latest version in Debian already wants gimp 2.4.4 (but there was a version in unstable generating the right depends on gimp)
<hendrixski> is there a separate tool from apt-ftparchive for creating debug symbol repositores?  because it doesn't seem to pick up ddeb packages :-(
<slangasek> doko: are you aware of cwidget being dep-wait on i386 because it's grown an ikiwiki build-depends-indep?
<LCID_Fire> Hi
<doko> slangasek: now I'm aware of it. thanks
<LCID_Fire> Could anyone give me a hand with grep?
<ScottK> LCID_Fire: #ubuntu for support.
<LCID_Fire> k
<slangasek> doko: ok, cheers :)
<hendrixski> I've made some debug symbol packages, but I can't seem to put them into a repository.  Is there a way to get dpkg-scanpackages or apt-ftparchive to pick those up?
<geser> slangasek, doko: cwidgets needs also libhtml-scrubber-perl from universe to fulfil build-depends-indep
<hendrixski> pitti, I've seen your name on a few posts dealing with repositories of ddeb packages.  If you get this, can you direct me to some documentation about how to make them.  Thanks :-)
 * jdong reads Fedora 9's release notes and learns there's now something called PackageKit
<jdong> hmm... redhat camp seems really Kit happy
<TheMuso> jdong: IMO its shameful.
<TheMuso> :p
<lifeless> I find the *Kit naming bizarre
<TheMuso> lifeless: likewise.
<jdong> likewise
<jdong> will we get BazaarKit anytime soon? ;-)
<jdong> because I really version control belongs on top of dbus and HAL
<StevenK> Are they trying to pay homage to Knight Rider or something?
<lifeless> we have it, import bzrlib.plugins.dbus
<lifeless> kthxbye
<jdong> :D
<jdong> there's actually a dbus plugin?
<lifeless> https://launchpad.net/bzr-dbus
<slangasek> KatKit, for managing your pet's diet in a trademark-infringing manner
<jdong> StevenK: *Kit feels really Apple-y to me
<TheMuso> I think I'll make a speechkit./
<TheMuso> Or TTSKi.
<TheMuso> TTSKit
<jdong> TheMuso: shouldn't that be a part of ConsoleKit?
<jdong> :D
<jdong> what's the subunit of a Kit?
<TheMuso> jdong: No.
<lifeless> jdong: (in a word - yes there really is a dbus plugin)
<lifeless> jdong: and avahi
<TheMuso> avahi I can understand... But not dbus.
<jdong> lifeless: I can understand the value of avahi branch announcements
<jdong> but... dbus...
<lifeless> bzr commit-notify
<lifeless> listens on dbus
<lifeless> gtk window pops up on each commit/push/pull/uncommit
<lifeless> or branch
<jdong> interesting
<lifeless> bzr lan-notify shares these on the LAN
<jdong> what's next? coreutils-dbus?
<lifeless> so you commit to a public branch, I get a commit notify back through dbus and gtk
<jdong> the ability to pipe things into dbus and then for another coreutil to fetch it out? :D
<jdong> I guess I just had a very different conception of what "utopia" meant :)
<TheMuso> lifeless: I actually like that.
<TheMuso> THat gtk notification stuff.
<lifeless> thanks :)
<lifeless> TheMuso: I haven't done much/any a11y stuff for it
<TheMuso> lifeless: Oh I'm not so worried about that, although I should check it out some time. I just like the window notifications of branch updates.
<lifeless> do you use it regularly ?
<TheMuso> lifeless: I've never used it, but I'm interested enough to check it out.
<lifeless> :)
<lifeless> bbiab
#ubuntu-devel 2008-02-08
<arcticpenguin380> why isnt reiser4 in ubuntu
<cjwatson> because it is not upstream, and it is not compelling enough to develop the local expertise that would be necessary to integrate and support it ourselves in the absence of support from the main kernel developers
<cjwatson> if and when it is integrated into mainline Linux, we'll almost certainly include it
<arcticpenguin380> ext4 is in the kernel but not avalibalbe for installation
<mjg59> arcticpenguin380: ext4 is not guaranteed to maintain a consistent on-disk format yet
<mjg59> Until that's guaranteed, we can't offer it for installation
<mwolson> maintainer of the emacs22 package speaking
<mwolson> would a main sponsor be willing to act on Bug #172389, which has had a new version languishing for 4 weeks?
<ubotu> Launchpad bug 172389 in emacs22 "Please upload emacs22 22.1-0ubuntu10" [Undecided,Fix committed] https://launchpad.net/bugs/172389
<mwolson> the patch attached there fixes a handful of other bug reports in addition to that particular one
<MacSlow> how can one force a autoreconf if a new option for configure has been introduced?
<TheMuso> MacSlow: Depends on how the package gets built now.
<TheMuso> There is the autoreconf command, which might help in what you want to do.
<MacSlow> TheMuso, I know how to do it all "outside" of dpkg with the normal upstream codebase
<MacSlow> TheMuso, but I want to avoid adding the diff to the configure file to a debian/patch/foo_bar.patch
<MacSlow> I just added the diff to the configure.in
<MacSlow> and added a one-line diff to the debina/rules file
<MacSlow> but during "dpkg-buildpackage -rfakeroot" configure is not automatically recreated (thinking of it, it makes sense that it's not recreated)
<crimsun> I presume you're passing -f.
<MacSlow> no
<MacSlow> crimsun, would that need to be passed to dpkg-buildpackage?!
<crimsun> (to autoconf)
<mwolson> thanks to whoever just uploaded emacs22 22.1-0ubuntu10; it is much appreciated
<crimsun> mwolson: yw.
<MacSlow> crimsun, there's no autoconf-related dh_something command or is there?
<crimsun> MacSlow: not AFAIK.
<crimsun> I certainly don't claim to be an authority on debhelper, however.
<MacSlow> so there's no way around adding the diff to configure itself?!
<TheMuso> No I don't think there is any dh magic to help.
<MacSlow> damn
<crimsun> MacSlow: well, err, what I've done in the past is use "autoreconf -f" [or "autoconf -f"]
<MacSlow> crimsun, I know about that
<crimsun> it does bloat your Build-Depends, but it has always worked for me.
<MacSlow> I just wanted to avoid doing this bigger delta to upstream
<MacSlow> but I hate taht
<MacSlow> that
<MacSlow> a ~3000 line diff just for a newer version of the configure file
<MacSlow> *spewÂ³*
<RAOF> MacSlow: Isn't autotools wonderful? :(
<MacSlow> RAOF, well it's more me "fighting" with the deb-tool infrastructure
 * MacSlow regrets not being a seasoned MOTU Ã  la seb128, dholbach & Co
<RAOF> It would be rather nice to have a dh_autoconf or somesuch; basically a special-cased patch system.
<RAOF> Because you'd like the build to be repeatable as possible, so you don't particularly want to autoreconf during package build, but it's really ugly to have the huge diffs.
<tjaalton> mjg59: hey, will you push the DIX patch upstream?
<soren> pitti: Archive day today?
<mjg59> tjaalton: Which one?
<mjg59> tjaalton: Oh, the scaling one? It's in bugzilla already
<tjaalton> mjg59: the one that stevenk applied on xserver
<mjg59> I didn't write it :)
<tjaalton> ah
<tjaalton> which bug?
<mjg59> Hm.
<tjaalton> right, it was "from", not "by" :)
<mjg59> Don't have it to hand, I'm afraid
<tjaalton> ok, I'll dig it up
<tjaalton> mjg59: you mentioned a while ago that synaptics needs some love.. any news on that?
<mjg59> Still working on the Xi code for that
<tjaalton> ok
<dholbach> good morning
<Hobbsee> morning dholbach
<dholbach> hey Hobbsee
 * Hobbsee sigh
<Hobbsee> please do *not* run cron.daily when i'm not at dinner!
<pitti> Good morning
<pitti> soren: archive day> yes
<pitti> hendrixski: sure, see first paragraph of https://wiki.ubuntu.com/DebuggingProgramCrash
<Hobbsee> morning pitti!
<pitti> hey Hobbsee
 * pitti waves to dholbach, too
 * Hobbsee hugs pitti
 * pitti tickles Hobbsee
 * Hobbsee stomps on pitti's feet
 * pitti jumps away in time and steals the long pointy stick
<pitti> hey carlos!
<carlos> pitti: hi
<Mithrandir> Hobbsee: you're aware that cron.daily is supposed to run at like 0600 in the morning?  At which point you should not be at dinner.
<Hobbsee> Mithrandir: yeah, but the laptop is never on then, so i'm expecting it runs when it gets turned on
 * pitti sighs at new -- 223 items
<warp10> Good morning
<Mithrandir> pitti: if you do two of those, there'll only be 221 left! :-)
<pitti> Mithrandir: hey -- I should've thought of that!
<pitti> good morning warp10
<warp10> Hey pitti!
<Mithrandir> pitti: and then you can do two more and there'll only be 219 left.  And so on. :-P
<pitti> hm, seems that nobody else processed NEW during the week :/
<soren> Hm... Do I want "Intel 3945ABG Wireless Card" or "Dell Wireless 1505 802.11a/g/n" ?
<Hobbsee> the former
<thegodfather> probably intel
<seb128> pitti: I didn't but I can give you a hand on it today
<RAOF> Performance or guaranteed-working.  Choices... :)
<seb128> any thunderbird user around?
<thegodfather> soren: 11n is still in draft
<soren> pitti: Which one did you get in your Dell?
<Hobbsee> seb128: yeah
<thegodfather> soren: not a full RFC/standard/spec
<soren> thegodfather: That's a good point.
 * Hobbsee --> dinner
<seb128> I'm probably missing something obvious, but how do I update the messages counts?
<pitti> soren: I have the 3945
<soren> pitti: And you're happy?
<pitti> soren: I had the alternative of a 4965
<pitti> soren: it's working fine, at least with the gutsy kernel
<Hobbsee> soren: iwl3945 seems to work fine.
<Hobbsee> on hardy
<pitti> soren: the iwl3945 driver (hardy) has troubles with my home's wifi
<seb128> like evolution does on send&receive
<soren> Oh. It says the 4965 is only for Core Solo.
<seb128> to know which folders have unread mails
<pitti> soren: but it worked fine for all wifis in London
<soren> pitti: Interesting.
<seb128> pitti: what sort of issue?
<soren> pitti: Yours is the Latitude D430?
<pitti> soren: once I do have a connection, it works fine here, too
<seb128> nm0.7 doesn't work on my home wifi, I had to downgrade to 0.6
<seb128> using my d630
<pitti> but often it doesn't see the essid
<seb128> it was working fine in london
<pitti> so it takes some rounds of rmmod/modprobe/sudo iwlist scanning until it works
<pitti> soren: d430, yes
<soren> erk
<Hobbsee> seb128: are you subscribed to the folders?
<Hobbsee> seb128: oh, change mail.check_all_imap_folders_for_new to true, in about:config
<Hobbsee> and make sure you're subscribed to the folders you want
<seb128> Hobbsee: ok, no wonder people think thunderbird is faster if it doesn't update anything :-p
<Hobbsee> :P
<pitti> soren, seb128: nm0.7 works well here (same as 0.6)
<MacSlow> seb128, any idea how to force "dpkg-buildpackage -rfakeroot" regenerate configure from configure.in, which is altered by an included patch?
<seb128> urg?
<seb128> cdbs-edit-patch 90_autoconf_update
<seb128> autoconf
<seb128> rm -rf autom4te.cache
<seb128> ctrl-D
<MacSlow> seb128, I want to avoid addint a ~3000 lines diff to my patch just for having --enable-gconf be used
<seb128> run autoconf usually is not that much change
<seb128> we do it for lpi in lot of packages
<pitti> (provided that you use the same autoconf version)
<MacSlow> pitti, seb128: well I'm on current hardy here
<seb128> that doesn't matter
<MacSlow> ?
<seb128> using the same autoconf than upstream does the diff smaller
<seb128> but you don't care about 30 lines or 3000 lines changes
<seb128> that's still small in the diff.gz
<MacSlow> I could live with 30, but not with 3000
<seb128> why not?
<seb128> don't look at the GNOME packages in ubuntu and debian then
<MacSlow> Ok I won't :)
<seb128> we have many autoreconf patches with ten of thousand lines of changes
<MacSlow> I try to keep patches comphrehendable
<seb128> that's just running autoconf there and doing a patch with the changes, what is the issue,
<seb128> 90_autoconf_update is a patch with autoconf update as indicated by the name
<seb128> who would like to read that?
<seb128> that's the reason why we split the code change and the autoconf run
<seb128> you have your small patch for changes you wrote
<seb128> and one for the autotools update that nobody read, they just know that's an autoconf call to update
<MacSlow> hm... well for two days now I'm trying to get the patch into shape so I can hand it over to you, mvo or pitti for uploading
<MacSlow> and I still don't know how to make sure the new strings will show up for translation in LP
<seb128> just ask on IRC if you are blocked, I'm happy to help you
<MacSlow> there's no .pot file anywhere in libwnck-2.21.90
<seb128> easy enough, just make sure the file with the strings is listed in po/POTFILES.in
<MacSlow> it is
<mvo> MacSlow: if you pass the patch to one of us and tell about the outstanding issues, we are happy to help getting around those packaging issues
<seb128> the pot are created at build by running intltool-update -p usually
<MacSlow> it's not adding new source files... just adding some strings in existing sources
<seb128> cdbs does that for you
<seb128> just build and look after the build to the po directory
<seb128> if you have _() correctly around those they will be translatable
<MacSlow> well the build does not work (incorporate my changes, due to the --enable-gconf not being applied to configure)
<MacSlow> seb128, I know how to use all the gettext stuff in the upstream-land... but getting that "through" the debian-tool-chain-infrastructure is... *sigh*
<seb128> MacSlow: come on, there is nothing to do, just build your package and look to po/ and the pot is there
<seb128> MacSlow: and for the configure update I gave you the exact commands to type 15 minutes ago
<seb128> MacSlow: anyway I'm happy to do the packaging changes and check that the template is correctly updated, just send me the patch you have with the corresponding bug number
<MacSlow> seb128, ok verified that the libwnck.pot does have the newly introduced strings
<MacSlow> trying the configure-stuff now
<TheMuso> pitti: Nothing seemed to change for me re jockey. I even removed the firmware, and the driver didn't end up spewing firmware needed dmesg output.
<pitti> TheMuso: changed> it doesn't detect and show the driver for you?
<TheMuso> pitti: Not in the window, nothing is listed.
<pitti> TheMuso: ok; can you please send me jockey-gtk --debug --list output again?
<TheMuso> pitti: Ok.
<MacSlow> seb128, hm... compilation currently fails due to not foudn gconf-includes... trying to figure out why
<seb128> MacSlow: where is your patch.
<seb128> ?
<MacSlow> seb128, for libwnck-2.21.90... http://people.ubuntu.com/~mmueller/changelog http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch http://people.ubuntu.com/~mmueller/90_autoconf_update.patch
<seb128> and what error do you get?
<MacSlow> on compilation of pager.c:41:32 error: gconf/gconf-client.h: No such file or directory
<seb128> ah
<MacSlow> somehow the stuff from configure does not get pulled in
<seb128> you did Makefile.am changes
<MacSlow> it works with doing th stuff again upstream
<seb128> not only configure
<MacSlow> hm..
<seb128> change the 90_autoconf_update to be 90_autoreconf_update
<seb128> and run autoreconf -v -f instead of autoconf there
<MacSlow> autoreconf should have been better
<seb128> that will update the Makefile.in too
<MacSlow>  I'll redo the 90_thing with autoreconf -v -f
<MacSlow> next try
<MacSlow> nope that failed with the same error
<seb128> is GCONF_CFLAGS set in the Makefile?
<MacSlow> seb128, see http://people.ubuntu.com/~mmueller/02_expose_wm_keybindings.patch
<seb128> MacSlow: still broken?
<seb128> let me try
<MacSlow> right in the first 30 lines or so
<MacSlow> those changes there work with libwnck-2.21.90 when building it normaly (without the debian-tools)
<MacSlow> no clue why it fails otherwise
<seb128> MacSlow: looks like you did run autoreconf in your autoreconf patch
<seb128> MacSlow: can you put your dsc and diff.gz online?
<seb128> I just tried the patch with an autoreconf -v -f run and that build fine
<MacSlow> but wasn't that what you told me?
<seb128> what?
<seb128> <seb128> change the 90_autoconf_update to be 90_autoreconf_update
<seb128>  and run autoreconf -v -f instead of autoconf there
<seb128> you have a Makefile.am change, so you need to autoreconf, you were just speaking about configure this morning when I told you to run autoconf only to update
<MacSlow> you meant me to edit the fiile 90_auto(re)conf_update directly?!
<seb128> no
<seb128> drop the patch
<MacSlow> I assumed you meant recreate it and use "autoreconf -v -f" instead of "autoconf"
<seb128> cdbs-edit-patch 90_autoreconf_update
<seb128> autoreconf -v -f
<seb128> rm -rf autom4te.cache
<seb128> ctrl-D
<seb128> debuild
<seb128> yes, that's what I did
<MacSlow> ok... so know I have a freshly grabbed libwnck-2.21.90
<MacSlow> I copied changelog and 02_expose_wm_keybindings.patch
<MacSlow> no 90_autoconf_update or 90_autoreconf_update yet
<MacSlow> I now create that by calling cdbs-edit-patch 90_autoreconf_update (followed by the stated commands in the created shell session)?!
<MacSlow> seb128, ?
<MacSlow> is there a difference between calling "debuild" or "dpkg-buildpackage -rfakeroot"?
<seb128> MacSlow: yes, do those
<MacSlow> it fails here still
<dholbach> MacSlow: debuild makes use of dpkg-buildpackage -rfakeroot and writes a build log (it's a wrapper)
<pitti> MacSlow: debuild does some extra magic, cleaning environment, and selecting GPG keys, etc.
<seb128> calling lintian too
 * MacSlow hates this day
<pitti> -rfakeroot shouldn't be necessary in hardy any more, BTW
<seb128> MacSlow: copy the dsc and diff.gz online
<dholbach> MacSlow: calm down - it's not that bad :-)
<MacSlow> dholbach, dude you have no idea how unproductive I feel right now
<dholbach> MacSlow: take one step, then the next - you'll figure it all out and it'll be fine
<MacSlow> dholbach, I just followed seb128's described steps exactely and it failed
<seb128> MacSlow: copy the dsc and diff.gz and I'll help you
<MacSlow> I mean how much damage can I cause by copy&pasting seb128's commands
<seb128> MacSlow: it'll be easier with a quick glance
<MacSlow> seb128, they are of use although the build failed?
<seb128> yes, precisely
<seb128> I want to try with the same version here
<MacSlow> http://people.ubuntu.com/~mmueller/libwnck_2.21.90-0ubuntu2.diff.gz http://people.ubuntu.com/~mmueller/libwnck_2.21.90-0ubuntu2.dsc
<MacSlow> there you go
<TheMuso> pitti: Interesting that. I use it out of pure habbit, and likely will nver stop using rfakeroot. :)
<pitti> TheMuso: well, I grew up with debuild, and I'm a lazy typer :)
<TheMuso> haha
<MacSlow> pitti, Ctrl-R for the rescue I always say
<pitti> heh
<seb128> MacSlow: ok, I confirm the bug
<MacSlow> seb128, so my setup here is broken?
<MacSlow> any idea what's causing it?
<seb128> MacSlow: looking at it
<MacSlow> ok
<seb128> MacSlow: bah, I figured
<MacSlow> is it nasty?
<seb128> MacSlow: you dropped the debian/rules --enable-gconf use
<MacSlow> but how?
<seb128> don't ask me
<seb128> you diff.gz give a rules not using this option
<seb128> you like took the source
<seb128> copied the patch
<seb128> the changelog
<seb128> run autoreconf
<seb128> and forgot to update rules?
<seb128> you likely rather
<MacSlow> but it's in the file 02_expose_wm_keybindings.patch
<seb128> oh
<seb128> patches are applied by the rules
<MacSlow> how could that have been "dropped"?
<seb128> you edit rules directly
<seb128> what you did is racy
<seb128> the rules is read before the patches are applied
<seb128> so the change is not used
<MacSlow> *sigh*
<seb128> rules is a Makefile
<MacSlow> so how would what I did in 02_expose_wm_keybindings.patch be done the "right" way?
<seb128> edit directly debian/rules and drop the change from the patch
<seb128> patches are for source change
<seb128> the packaging is a debian thing, we directly edit the debian directory
<MacSlow> ok
<MacSlow> now for the 1432nd try
<MacSlow> here goes the debuild
<seb128> is it working now?
<MacSlow> did not break yet
<seb128> that show a bug in your code BTW
<seb128> if --enable-gconf is not used the build try to build with gconf anyway and breaks
<pitti> TheMuso: ah, thanks; got the bug
<MacSlow> seb128, so the configure.in stuff is broken?!
<TheMuso> ~pinp
<seb128> MacSlow: yes
<TheMuso> pitti: np
<MacSlow> seb128, at least the build of the libwnck with my additions now finally worked here
<pitti> TheMuso: I'll add a test case for this, fix it in trunk, and then go back to your box to verify it later; if you can leave my login for a day?
<MacSlow> seb128, I'll look into the configure.in issue
<TheMuso> pitti: I can leave it running for a day if you need.
<MacSlow> seb128, once that's done I'll ping you again or email you or mvo for upload if you're ok with the rest of it (ok three icons and the translations are still missing)
<MacSlow> seb128, that those can come later
<pitti> TheMuso: as you prefer; alternatively I can just send you updated .debs for testing; more work for you, less power consumption :)
<MacSlow> seb128, anyway did you try the newer version of libwnck?
<pitti> TheMuso: (well, I'll need testing from you for the graphical bits and the root operations anyway)
<TheMuso> pitti: The mini doesn't use a lot so its no big deal.
<TheMuso> pitti: Righto, I can leave it on overnight at least, so you can do what you need to.
<pitti> TheMuso: cool, thanks; I'll mail you
<TheMuso> pitti: No problem.
<TheMuso> ...and I'm off for the night, and the weekend.
<dholbach> TheMuso: have a great weekend!
<TheMuso> dholbach: You too.
<seb128> MacSlow: I think the issue is  ENABLE_GCONF case, you look for yes but don't handle the auto case there
<MacSlow> seb128, there's implicit support for "auto"?
<seb128> MacSlow: enable_gconf is not set in your case if the configure option is not used, you can add a [enable_gconf=yes] to set a default case
<seb128> MacSlow: but your configure will still be buggy I think
<seb128> if test "x$enable_gconf" != "xno"; then
<seb128>         PKG_CHECK_MODULES([GCONF], [gconf-2.0 >= 2.20.0])
<seb128> 	CFLAGS=-DUSE_GCONF
<seb128> that should be conditional to whether the gconf-2.0 is installed
<seb128> because you set the CFLAGS anyway there
<seb128> MacSlow: setting the default value to yes should do the trick
<Riddell> asac: network-manager-kde 0.7 in my ppa if you want to test, it didn't work for me (but neither did the gnome applet)
<asac> Riddell: gnome applet didn't? how?
<asac> Riddell: do we have a bzr sync for nm kde 0.7? where is that maintained?
<Riddell> asac: no, I just stole the source from suse
<Riddell> asac: gnome applet didn't show any devices for me
<asac> so they do in house development?
<asac> Riddell: anything in /etc/n/i ?
<Riddell> asac: just "lo"
<asac> can you paste syslog somewhere? does nm bring down interfaces if you start it?
<asac> Riddell: ^^
<Riddell> asac: Feb  8 11:24:14 wido NetworkManager: <WARN>  nm_dbus_manager_init_bus(): Could not get the system bus.  Make sure the message bus daemon is
<Riddell> running!  Message: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
<asac> Riddell: huh .. which version?
<Riddell> is what happens when I /etc/init.d/dbus stop and start again
<asac> is there still a nm around?
<Riddell> dbus 1.1.2-1ubuntu2  network-manager 0.7~~svn20080121t191418+eni1-0ubuntu0~pre7
<asac> isn't system bus hal?
<Riddell> I imagine hal uses it
<asac> Riddell: do you still have the 25NetworkManager in /etc/dbus-1/event.d ?
<asac> Riddell: 0.7 is restarted by /etc/init.d/NetworkManager restart atm
<soren> pitti: Your laptop has the trackpoint thing, doesn't it?
<pitti> soren: both a touchpad and a trackpoint
<soren> pitti: Awesome. I just ordered mine, and it suddenly occured to me that I wasn't sure if it had such a thing.
<Riddell> asac: when I run /etc/init.d/NetworkManager I get http://kubuntu.org/~jriddell/tmp/nm
<asac> console kit
<asac> is that related to nm?
<cjwatson> Riddell: does kdm register a ConsoleKit session?
<cjwatson> (sorry if I missed the discussion due to network trouble)
<Riddell> cjwatson: it tries to, seems to be having some issues though
<Riddell> asac: not that I know of
<persia> tjaalton: Are you planning to update nvidia-legacy so that bug #72979 can be executed?  I'm perhaps a little confused about activity from just reading bug reports.
<ubotu> Launchpad bug 72979 in nvidia-settings "Please remove nvidia-settings from gutsy" [Low,Confirmed] https://launchpad.net/bugs/72979
<tjaalton> persia: refresh :)
<tjaalton> persia: I just uploaded a new revision which installs nvidia-settings in nvidia-glx-legacy
<tjaalton> so nvidia-settings can be removed from hardy
<persia> tjaalton: Excellent!  That bug has been bothering me for a rather long time.  Thank you.
<tjaalton> no problem, now some lunch ->
<cjwatson> mvo: current apt-key/ubuntu-keyring is having trouble adding the CD signing key; it says "gpg: error reading key: public key not found"
<cjwatson> mvo: I think that this line is wrong?
<cjwatson>             if $GPG --list-sigs --with-colons $add_key | grep ^sig | cut -d: -f5 | grep -q $master_key; then
<cjwatson> mvo: shouldn't that be $GPG_CMD --keyring $ADD_KEYRING, rather than $GPG?
<cjwatson> since the key isn't necessarily in /etc/apt/trusted.gpg yet
<mvo> cjwatson: let me check
<dholbach> MOTU Q&A session in #ubuntu-classroom in 10 minutes
<mvo> cjwatson: you are right (of course). fixing it now, I will upload a new apt today that will also include the networkless-install bits
<cjwatson> mvo: thanks! I just uploaded an apt-setup that seeds /var/lib/apt/lists with signed Release files
<mvo> nice!
<cjwatson> mvo: is there any more to AptAuthenticationReliability, or can I mark it implemented now?
<mvo> cjwatson: I think that was it, we should be done (modulo bugs of course)
<cjwatson> mvo: maybe the notification on failed updates?
<mvo> cjwatson: right, that one is sitting here in my local disk, I'm a bit unsure if we should enable it. there is a warning now in update-notifier/update-manager if the last update of the sources.list did work for a certain amount of days (7 currently)
<cjwatson> if s/did work/did not work/, I think that's good enough for me
<mvo> yeah,  s/did work/did not work/ indeed :)
<cjwatson> we could enable the warning and turn it off if it annoys people
<mvo> and check how much people actually see it, how widespread the problem is
<mvo> that sounds like a plan
<ScottK> pitti: The trimmed amavisd-new (removed the milter) is uploaded, so it should be ready to be promoted.
<pitti> ScottK: ah, neat; I checked this morning and didn't see it yet
<ScottK> I just uploaded.
<ScottK> pitti: Do you have a moment to discuss another issue.
<pitti> ScottK: sure
<ScottK> pitti: I've been looking after clamav for some time and as I'd imagine you're aware there is quite a security problem in Dapper.
<ScottK> I've got a list of 12 or 13 CVEs that are open and valid against the current Dapper clamav.
<ScottK> It's old enough to be unmaintainable for any reasonable effort MOTU might be able to muster.
<ScottK> In dapper-backports, we uploaded the current clamav package (with some small changes to work on Dapper) and updated all the rdepends.
<ScottK> It's been several weeks now with no bugs filed.
<ScottK> pitti: My proposal is that these updates be copied from backports to dapper-updates.
<ScottK> At this point our choices boil down to this or leave the vulnerabilities.
<ScottK> If you think this is worth considering, I can file a bug with the CVEs and a complete package list.
<pitti> ScottK: I do think that it is worth considering
<pitti> ScottK: depending on how much positive feedback we got?
<pitti> ScottK: I think we should open/find a bug suitable for SRU, copy -backports to -proposed, and call for testing
<ScottK> Myself and a few other people tested all of these uploads in a PPA before they were backported and documented the test results.
<pitti> ah, great
<ScottK> https://wiki.ubuntu.com/MOTU/Clamav?action=show
<pitti> can you please include a pointer to these results into the bug?
<ScottK> Yes
<ScottK> Will do.
<pitti> oh, that looks like great documentation
<DktrKranz> pitti, do you think this is applicable to normal issues too (not concerning security vulnerabilities) ? . I saw some requests to release upgrades for completely broken apps (mainly youtube clients)
<pitti> ScottK: if it really has been proven that well already, that should suffice for verification
<jdong> DktrKranz: when the original is so defective that it "couldn't possibly get any worse"... I'd like for a procedure like this to be documented to take a new version trhough backports->proposed->updates
<ScottK> pitti: OK.  I do think we've tested it pretty thoroughly.
<ScottK> pitti: I've also uploaded a New amavisd-new-milter source package to maintain that binary in Universe.
<DktrKranz> jdong, really. I tried to isolate single patches for some of these packages, but changes are invasive as much as backport new release.
<pitti> ScottK: what's the X in claws-mail-clamav?
<ScottK> It doesn't exist in Dapper
<frafu> Hello, as you probably know, an accessibility tab has been added to the mouse control panel in GNOME 2.22 (and consequently, it is also available in hardy). However, the new accessibility features are in a separate module that is currently as a new module in the build queue for universe.
<pitti> DktrKranz: if the regression potential for a package is zero because it doesn't work at all, I'm fine with updates; if it works under some conditions, upgrades have to be evaluated to avoid regressions
<ScottK> pitti: If you look at the PPA  - https://launchpad.net/~ubuntu-clamav/+archive - you'll see we've got packages for all the releases for testing.
<frafu> My question: Should I file the mir right away, or do I have to wait for mousetweaks to be available in the universe repo?
<pitti> ScottK: ah, I see
<pitti> ScottK, DktrKranz: well, in this case my feeling is that the updates should go to -proposed in the first place, and not to -backports; WDYT?
<jdong> pitti: do you think this workflow should be documented as an exception on the StableReleaseUpdates process, or do you feel this is rare enough that we can seek approval informally from you on a case-by-case?
<persia> frafu: it's better to wait until it is in universe, but you might get started on the wiki entry beforehand, given the tight timing for hardy.
<pitti> jdong: I think we should keep the workflow, and rather add the condition to the list of acceptable SRUs
<jdong> ok
<ScottK> Makes sense
<ScottK> I do think for situations where the package supports a service that makes random non-compatible changes it ought to be SRUable.
<frafu> persia: I have already written the mir in the wiki: https://wiki.ubuntu.com/MainInclusionReportMousetweaks
<DktrKranz> pitti, going through -backports sounds like an additional step to be taken, since we should test packages on -backports and -proposed.
<pitti> if it worked in breezy, then it already falls under the 'major regression' case
<pitti> DktrKranz: right; -backports isn't really meant for bug fixes, it's for new features
<jdong> DktrKranz: I don't think going through backports is unreasonable for introducing a new upstream version of anything, if it came from Hardy
<frafu> It would be odd to have the gui in hardy but no the functions because mousetweaks is missing.
<ScottK> jdong: It depends on if something's fundamentally broken or not.
<jdong> ScottK: hmm... actually on second thought, I don't think going through backports is a good idea
<jdong> the backports buildd's build against all components
<jdong> so it can't be guaranteed  to be "just like -updates"
<elmo> jdong: err, what?
<jdong> elmo: backporting a packages from main is allowed to build against multiverse ;-)
<jdong> it was like during Breezy or so that we had issues with changing definitions of sections and the decision was just to do away with sections altogether :)
<elmo> jdong: umm, seriously?
<jdong> elmo: yeah...
 * jdong can sense elmo's blood boiling :)
<DktrKranz> pitti: suppose we have a package in gutsy broken beyond any repair, and hardy new upstream version fixes the issue, which version should we adopt to avoid clashing with existing packages?
 * ScottK steps to the other side of the room, away from the late jdong.
<DktrKranz> using ~gutsy as backports do?
<Hobbsee> jdong: what crack are you proposing now?
<jdong> Hobbsee: none :) I'm just recapping on crack from 1.5yrs ago :)
<ScottK> Hobbsee: Actually it's DktrKranz's crack.
<Hobbsee> and a soyuz bug, it appears
<ScottK> My fault though.  I started it.
<jdong> DktrKranz: rmadison azureus; and yes ~gutsy1
<DktrKranz> ScottK, heh :)
<jdong> Hobbsee: It was intended functionality, not a soyuz bug (this time :D)
<pitti> jdong: hm, so what's the current status of bug 184386? that's a bit confusing
<ubotu> Launchpad bug 184386 in gutsy-backports "Please backport bzr-svn (0.4.5-1) from Hardy" [Undecided,New] https://launchpad.net/bugs/184386
<Hobbsee> jdong: so it was a crack decision.  got it.
<jdong> pitti: don't backport for now, awaiting a sync of 0.4.7-1 to hardy, at which point, backport
<pitti> jdong: also in relation to bug 188781 ?
<ubotu> Launchpad bug 188781 in bzr-svn "[backport-request] bzr-svn not installable when backports enabled" [Undecided,Invalid] https://launchpad.net/bugs/188781
<jdong> pitti: those two are dupes
<pitti>    bzr-svn |    0.4.7-1 | hardy/universe | source, all
<jdong> Hobbsee: well considering the restrictions placed on the origins of backports, IMO not all that crackful
<jdong> pitti: oh, already synced :) guess I'm not on the ball
<pitti> jdong: so "the bzr-builddeb issue" (whatever that is) is ok?
<jdong> pitti: ask dholbach, I'm not sure :D
<pitti> jdong: I did it this morning, I think
<jdong> pitti: gimme a quick second to make sure bzr-svn 0.4.7 actually works on Gutsy
<pitti> jdong: marked as dup, thanks
<pitti> jdong: ok; no rush, we can do it later
<dholbach> pitti, jdong: bzr-builddeb on backports is all sorted out - I thought I had replied on all the bugs
<pitti> dholbach: yeah, it just wasn't clear to me what the issue was
<jdong> pitti: what's unclear to me is how it was resolved
<dholbach> it might have been the bzrtools dependency or something
<jdong> the issue I assume was bzr 1.0 does not work with bzr-builddep $existingversion
<jdong>  bzrtools (>= 0.18),
<jdong> yep it's surely a dep
<jdong> pitti: btw, bzr-svn 0.4.7-1 is good for gutsy-backports
<pitti> so, if everything is alright, I wait for jdong's final ack for bzr-svn, and then we backport
<pitti> cool
<jdong> pitti: ready to do this all again with bzr 1.10? :D
<pitti> sure
 * pitti â¥ bzr
<jdong> don't we all :)
<pitti> and bzr-svn is so great
<jdong> even my TODO list is managed via bzr :)
<pitti> my /etc backup, too
<jdong> nice
<soren> pitti: Er... Why was netcat-openbsd rejected?
<pitti> soren: it was a duplicate in the queue
<pitti> someone synced it without NEWing
<soren> Ah.
<pitti> slangasek: ^ might have been you? if you sync new pacakges from Debian, please keep a list and immediately NEW them (U pkg1 pkg2; q accept pkg1 pkg2)
<soren> That was you, I think :)
<pitti> soren: I synced the second one, yes (the bug was still open)
<soren> Ah, ok.
<soren> Ah, yes, I see there's an accepted one from bigon. Ok, good.
<soren> Awesome, actually.
<ScottK> pitti: Bug #190187 for clamav in Dapper.
<ubotu> Launchpad bug 190187 in clamav "Dapper clamav has multiple security issues that require upgrade to new version to fix" [Undecided,Fix released] https://launchpad.net/bugs/190187
<seb128> pitti, thekorn: is that a known issue?
<seb128>   File "/usr/lib/python2.5/site-packages/launchpadbugs/lptime.py", line 61, in __new__
<seb128>     raise ValueError, "Unknown date format (%s)" %time_str
<seb128> ValueError: Unknown date format (2008-02-08 14:12:50 CET)
<pitti> hell, gutsy-backports/NEW is crowded
<seb128> pitti: the retrace is breaking on that an untagging bugs which are not retraced
<pitti> seb128: oh, I got the same this morning on drescher, but I already talked about this with thekorn and we couldn't reproduce it anywhere but drescher
<seb128> bah
<seb128> python2.4 thing again?
<ScottK> pitti: If you'd be willing to copy the clamav + rdepends straight to dapper-updates, I will definitely commit to be here to fix any problems (I'm already bug contact on all the packages.
<pitti> seb128: I hacked the instance on drescher
<seb128> pitti: could you do the same on ronne?
<soren> doko: I've been thinking about kvm and gcc.. Qemu compiled with gcc-3.4 is very well tested. The new code generator is brand new and has seen only very limited testing. I'm not sure if I'm completely comfortable making such a drastic change just to make it compile with gcc-4.x.
<pitti> ScottK: yeah, seems we got much testing on that one
<seb128> pitti: or rather the retracers
<pitti> seb128: no, it's not 2.4 specific
<seb128> pitti: or point me the change and I'll do the retracers update
<pitti> seb128: it worked just fine in my dapper chroot
<pitti> seb128: I replaced the raise with "t = time.gmtime()[0:6]" and added import time
<pitti> seb128: i. e. ignore the date
<seb128> ok, thanks
<pitti> seb128: that's not the chroots, right? just the digger?
<seb128> pitti: /tmp/tmpNW8_bN/usr/bin/apport-retrace
<seb128> pitti: that's the retracer no?
<doko> hrm. that would move 3.4 and 4.0 to main again
<soren> doko: I know.
<pitti> seb128: I think we just need to replace the p-lp-bugs instance on ronne with the current version, too
<seb128> pitti: do you have a script doing the update?
<pitti> seb128: erm, no, they shouldn't be in /tmp/
<soren> doko: At this point, the "new world order" of qemu is hardly a few weeks old.
<pitti> seb128: only one to create a completely new retracer
<pitti> seb128: I can do it now if you want
<doko> pitti: any opinion?
<seb128> pitti: would be nice, thanks
<pitti> seb128: oh, according to the log it failed in the chroot, not in the digger
<pitti> I'd really hate to promote two gccs again
<seb128> pitti: what I though
<soren> doko: Why is 4.0 needed?
<doko> libgcc2 for hppa
<pitti> it's not feasible to give 4.2 a try and only use 3.4 if that actually breaks?
<soren> pitti: I'd really rather do it the other way around.
<pitti> we still have plenty of time until the release
<soren> pitti: We *know* 3.4 gives good results.
<soren> pitti: I can promise to revisit this on at least a weekly basis.
<soren> pitti: Hoping to switch to 4.0 before release, but not promising that that will be the case.
<soren> Er..
<soren> 4.4, I mean.
<pitti> 4.2?
<soren> Or 4.3.. Whichever is the default nowadays.
<soren> I forget :)
<pitti> heh
<soren> 4.2.3.
<pitti> see, that's part of the problem -- plethora of compiler versions :)
<pitti> seb128: hm, that already was the latest version in the chroot
<pitti> so that's a real bug, I think
<pitti> seb128: I just apply the nasty hack then
<seb128> pitti: thanks
<soren> There are two sides to this really: I really, really want kvm to be as solid as possible, and you want to keep old compilers out of main. At this point, I'm not sure whether those two wishes can be fulfilled at the same time.
<pitti> seb128: I h4x0red the hardy/i386 chroot now
<soren> pitti, doko: From #kvm:
<soren> 15:23:02 < danpb_ltop> soren: the new code generator is faaaaar from complete
<soren> 15:23:14 < danpb_ltop> soren: there's going to be a long time with a hybrid of the old & new generators
<soren> ...so I'm not getting my hopes up.
<pitti> oh, too bad
<pitti> so, I guess it's up to doko whether we can maintain 3.4 for hardy?
<ScottK> pitti: Do you want me to subscribe ubuntu-archive on the clamav bug to get it in your work flow or is it OK as is?
<pitti> (still gives me a bad taste, though wrt. mantainability of qemu in the first place, if it is still using such ancient code)
<soren> pitti:That's not the issue at all.
<soren> pitti: It's not that the code is not compatible with 4.0 and beyond.
<elmo> soren: pitti's point still stands
<pitti> I might understand it wrongly
<pitti> ScottK: fine for me, I have a tab open
<elmo> we have nothing else in main that requires gcc-3.4
<elmo> and now kvm and it's "2nd generation virtualization" is pulling it back in...
<elmo> I'm trying not to giggle, really, I am, but...
<ScottK> pitti: OK.  Thanks.  I'll just leave it to you then.
<soren> pitti: During build time, qemu depends on a particular layout of the machine code, gcc spews out. gcc-4.0 changed dramatically in that respect, and there's no way to force it to do what we want it to.
<frafu> Could anybody please tell me what branch I have to checkout in order to add mousetweaks to the hardy desktop seed?  The following document only talks about the case of core-devs and read-only!?
<doko> hmm, 4.9 is so new
<doko> s/4.9/4.0/
<persia> frafu: You don't need to do that.  The MIR approver will update the seeds.
<pitti> persia: no, not the approver
<pitti> taking care of the seeds is the responsibility of the requestor
<persia> pitti: Who does then?  A sponsor?
<soren> elmo: My point is that it's not a matter of "ancient code" per se.
<pitti> yeah, someone who knows the package and where it should go to
<persia> pitti: Ah.  That makes sense.
<pitti> persia: of course, if I'm asked to do it, I'll do it
<pitti> but it's not the default
<frafu> In fact I am looking at how to do point 5 of https://wiki.ubuntu.com/MainInclusionProcess
<pitti> I'm just not sure whether we can touch the seeds right now, they are currently undergoing restructuring (cjwatson?)
<persia> frafu: mousetweaks is required to make part of gnome-control-center work properly, right?  You might consider asking for the dependency to be added there, rather than changing the seeds.  This would also fix the case where the "ubuntu-desktop" package was not installed.  Try asking in #ubuntu-desktop.
<cjwatson> pitti: don't let me block you; I'll deal with merging
<cjwatson> pitti: I'm waiting for a Launchpad fix before I can finalise it
<pitti> yay dependency chains :) ok, I'll add it then
<persia> pitti: To the seed?  Should not the GUI depend on the daemon to implement point 5, rather than a seed change?
<pitti> frafu: mousetweaks is in universe, though
<pitti> persia: yes, that would make more sense
<frafu> No; it will also work without mousetweaks, but if you try to activate the a11y features of the new mouse control panel you get a dialog telling you to install mousetweaks
<pitti> persia: (see, that's why the requestor is responsible, not the approver :) )
<persia> pitti: The light dawns...
<pitti> frafu, persia: so maybe the two of you can discuss where it belongs (with a comment from seb128 maybe) and then you tell me what to do?
<persia> frafu: Submit a debdiff against gnome-control-center to ubuntu-main-sponsors with the additional dependency.  This will put it on the right list to get it included in all the right places (pitti will be chasing point 6)
<Mez> pitti, from successful completion of a backport on your part, how long does it take to hit the archive ?
<seb128> pitti, frafu, persia: a gnome-control-center depends seems correct until we get recommends installed then we can use that there
<pitti> Mez: source> about an hour, binary> depends on buildd speed; usually less than a day
<persia> seb128: Sounds sane.  Thanks for the input.
<pitti> Mez: unless it's stuck in NEW, of course
<Mez> pitti - hope not
<Mez> pitti, well you backported it 28 mins ago... so I'll wait
<thekorn> pitti, seb128, this date/time error is really weird,
<thekorn> there might be a problem with the timezone information
<pitti>   File "/usr/lib/python2.5/site-packages/launchpadbugs/connector.py", line 95, in NewComment
<pitti>     return getattr(self.module, "Comment")(*args, **kwargs)
<pitti> TypeError: __init__() got an unexpected keyword argument 'attachment'
<pitti> thekorn: ^ another failure from the retracer
<pitti> known already? or do you want a bug?
<frafu> mousetweaks is not in universe yet; it is waiting for a build depend for the hppa architectures; the other architectures are already built
<pitti> thekorn: ah, I explicitly call it with ..., attachment=att); seems the API changed?
<thekorn> pitti, no, not known, can you please open a bugreport
<persia> frafu: Right.  Submit the debdiff for now, and the sponsor will apply it once it has passed binary NEW.
<pitti> thekorn: i. e. NewComment() doesn't accept an optional parameter attachment any more?
<thekorn> pitti, let me check
<Mez> pitti, another question - how do I find the build queues for backports pocket?
<thekorn> pitti, damn, the argument changed into "...attachments=set()...",
<ScottK> Mez: It's the same queue
<thekorn> but then it's a bug, I did not want to change the API
<pitti> Mez: try https://edge.launchpad.net/ubuntu/gutsy/+builds
<pitti> thekorn: ok, shall I report that one then?
<pitti> thekorn: I stopped the retracers for now, since that sounds like it'll break all retraces
<thekorn> pitti, I will fix it now
<frafu> So I submit a debdiff against gnome-control-center in launchpad; correct? (I am new to this, so I prefer to ask to be sure)
<Mez> ScottK, pitti, thanks... *sighs as what he's looking for doesnt seem to be in any state on the build*
<pitti> thekorn: oh, great, thanks; I'll manually patch the retracers then
<persia> frafu: That'd be my recommendation, assuming the MIR was approved (I haven't checked).
<pitti> ScottK: moved to -updates, thanks!
<ScottK> pitti: Wonderful.  Thanks for getting to it so quickly.
<pitti> frafu: I don't see a MIR for mousetweaks on https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs
<pitti> ScottK: exemplary verification and documentation
 * ScottK wonders if he should mention to pitti that he's up for core-dev on Tuesday and that might be worth a mention ...
<pitti> ooooh
 * pitti fanboys ScottK's nomination
<frafu> Yes; I thought I had to wait for mousetweaks to be in universe before applying to mir; I have already prepared https://wiki.ubuntu.com/MainInclusionReportMousetweaks
<frafu> pitti: should I add it now?
<pitti> frafu: ah, please
<pitti> frafu: yes, that was correct
<thekorn> pitti, ok, this might fix the attachment issue, http://paste.ubuntu.com/4340/
<frafu> pitti: ok;
<pitti> thekorn: thanks a lot
<cjwatson> Riddell: I'm adding proxy configuration to the advanced dialog in ubiquity, but I've run out of time to do the Qt side as well; could I get you to do that bit?
<cjwatson> it's pretty small, I'm just way out of practice with qt4-designer
<Riddell> cjwatson: can do
<cjwatson> thanks - I'll mail you a reminder once I've done the GTK side
<soren> doko, pitti: alternative plan:
<doko> include the gcc-3.4 source in kvm?
<soren> Hah!
<soren> How'd you guess?
<soren> doko, pitti: I work on a patch to kvm to make it refuse to do anything at all if hardware acceleration isn't available. That should alleviate the need for gcc-3.4.
<pitti> aah
<pitti> soren: so that people can install qemu from universe instead?
<pitti> that sounds great
 * pitti hugs soren
<soren> doko, pitti: However, we want to do some thorough testing, so we'd like to keep the door open for the option to include gcc-3.4 if it turns out to be troublesome.
<pitti> soren: we can always do that as last resort, yes
<soren> pitti: So the action plan now? Can we push kvm to main, dropping gcc-3.4 dependency when I'm done with the patch (which might be shortly after ff)?
<soren> Or should we hold off kvm until the patch is done? and how does that work w.r.t. feature freeze?
<persia> soren: Would it be possible to keep the fallback mechanism, but only use it if qemu is installed (from universe)?
<soren> persia: Not entirely.
<soren> persia: I wanted to, but it's not.
<pitti> soren: traditionally we did promotions/demotions way past FF
<persia> soren: Ah.  Oh well.
<soren> pitti: Ah, no worries, then.
<soren> pitti: Ah, right, I remember something about a partman-auto-crypto-lvm-magic thing that went in and out of main quite frequently shortly before gutsy released. *cough* :)
<pitti> soren: excellent plan, thanks
<pitti> so we can have the cake and eat it, too
<soren> \o/
<pitti> erk, p-lp-bugs Unknown date format did it again
<pitti> quick, I need a crash bug to retrace for testing :)
<Amaranth> pitti: start compiz
<pitti> *laugh*
<soren> Amaranth: I was going to say evolution :)
<Amaranth> compiz, evolution, OOo, take your pick ;)
<pitti> I'll watch it for  abit
<Amaranth> i can't think of any reproducable crasher, that must be a good thing
<Ng> I can!
<hendrixski> morning all
<Ng> alt-space on a borderless window makes some part of compiz segfault :)
<Ng> (bug #185784)
<ubotu> Launchpad bug 185784 in compiz "gtk-window-decorator SIGSEGV opening window menu on undecorated windowa" [Medium,New] https://launchpad.net/bugs/185784
<hendrixski> pitti, Xchat tells me that you sent me an answer about making repositories with the .ddebs but I can't scroll up enough to find it.  :-(  may I ask you to repost the answer?
<pitti> hendrixski: I don't remember a question about .ddebs
<pitti> hendrixski: oh, s/making/using/, yes
<soren> pitti: Will you make it all the way down the queue to, say, dnsmasq-base today?
<soren> pitti: Also, can I have a pony?
<pitti> hendrixski: look at the first paragraph on https://wiki.ubuntu.com/DebuggingProgramCrash
<zul> pitti: hello is libxen3 still in binary new?
<pitti> soren: I keep getting distracted from NEW, but I'm at it; i'll get to dnsmasq, though
 * soren hugs pitti
<soren> pitti: Lovely, thanks.
<pitti> zul: yes, it is
<zul> pitti: ok thanks
<pitti> soren: netcat-openbsd binary-NEWed
<zul> i wont bug you then
<hendrixski> pitti, I saw that page before, I don't see on it hwere it says how to make repositories with .ddeb files :-(
<soren> zul: https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=libxen
<soren> pitti: Whee!
<hendrixski> because when I run apt-ftparchive, all it puts in the Packages file is the regular .deb's and none of the .ddeb's :-(
<pitti> hendrixski: right, I misunderstood it as "where to get them"
<hendrixski> pitti, it's Ok. I probably didn't ask the question very well.  here's where I'm at:
<pitti> hendrixski: bzr get http://people.ubuntu.com/~pitti/bzr/ddeb-retriever/
<hendrixski> I made a bunch of them, when I installed dpkg-create-dbgsym and ran dpkg-buildpackage
<pitti> hendrixski: that is the code which builds ddebs.ubuntu.com
<pitti> hendrixski: and it calls apt-ftparchive appropriately
<hendrixski> ah
<pitti> hendrixski: please let me know if you have questions about it
<hendrixski> sweet.  I'm getting it right now.  So I just run the ddeb-retriever script in the directory where the ddebs are and it'll make the Packages.gz?
<pitti> no, ddeb-retriever itself runs much more
<frafu> pitti: mir-bug for mousetweaks has been filed and it shows up in https://bugs.launchpad.net/~ubuntu-mir/
<pitti> hendrixski: it calls archive_tools.create_indexes() which is the function you wnat
<hendrixski> pitti, ah, ok.. 'cause I just ran it and got import errors... google says I need to install python-apt ... but if I only need archive_tools.create_indexes()  I can figure out how to use it by reading through the code, right?
<pitti> you'll still need python-apt, I think
 * hendrixski apt-gets it
<pitti> hendrixski: but you don't actually need to use my code
<pitti> hendrixski: but you can look at it how to call apt-ftparchive
<pitti> hendrixski: (it took me some hours to get that working, too; it's very nonobvious)
<pitti> soren: any idea why dnsmasq is split into -base and dnsmasq in that weird way?
<soren> pitti: WHy is it weird_
<soren> ?
<hendrixski> pitti, heh, yeah, I spent a few hours googling for it yesterday, and even asked about it at my LUG meeting last night... nobody could find it  so that's when I posted the question on this channel last night.  We figured there must be a third party tool for it :-p
<pitti> soren: dnsmasq should be arch: all, but isn't
<pitti> soren: and hardly has any files
<soren> pitti: Gah, I told him to change that..
<pitti> soren: and dnsmasq-base has binaries
<soren> pitti: It's to make the upgrade path sane fo ranyone who's used to having dnsmasq installed.
<pitti> soren: the common pracice is that -base is arch: all and has the non-arch stuff (conffiles, mo files, etc.) and dnsmasq has the binaries
<pitti> soren: that's even more confusing; why would someone rename dnsmasq to -base when there's no other package?
<soren> pitti: Right. dnsmasq-base has all the binaries and stuff so that stuff like libvirt can depend on it without suddenly installing a running dchp and dns server on the system.
<pitti> soren: aah
<soren> pitti: And for people who are used to having dnsmasq installed, they'll get the expected results.
<pitti> so that should be s/-base/-bin/?
<soren> It could be.
<soren> I took the packaging from an upstream rc.
<pitti> ok, that clears it up a bit
<pitti> so apart from dnsmasq not being arch:all it looks alright
<soren> I can change it here, and tell him to do the same before he uploads to Debian.
<soren> Would you prefer that_
 * soren is going nuts over changing keyboard mappings..
<soren> Would you prefer that?
<pitti> soren: sounds good; I'll accept it for now
<soren> pitti: WHy shouldn't dnsmasq be arch: all?
<soren> pitti: It has not binaries.
<soren> pitti: Er.. It has not arch-specific binaries.
<pitti> soren: for that very reason :)
<soren> Whuh...
<soren> You want me to change it to arch: any because it has no binaries? wtf?
<pitti> it should be arch:all
<soren> It... is?
<pitti> soren: no, I'd like you to change it to arch:all
 * soren is confused
<soren> My local version here is arch:all.
<pitti> soren: no, in NEW I have dnsmasq_2.40-1ubuntu1_{sparc,powerpc,lpia,ia64,i386,hppa,amd64}.deb
<soren> How does that make sense? It's been there all the time?
<soren> Why would it be regarded as NEW?
<pitti> http://archive.ubuntu.com/ubuntu/pool/universe/d/dnsmasq/dnsmasq_2.40-1ubuntu1.diff.gz
<pitti> soren: that has arch:any for dnsmasq
<pitti> soren: -base is NEW
<soren> pitti: Hmm... so it does.
<sistpoty|work> tjaalton: I've seen that nvidia-settings is removed... can you ship the headers/lib from the restricted-modules package then?
<soren> pitti: Ok, I'll change that with my next upload. You also want me to rename -base to -bin?
<pitti> soren: don't worry about the renaming if it introduces a delta to debian; it just confused me a bit
<soren> pitti: I'll see if I can make upstream do the same. That'll make everything much easier.
<tjaalton> sistpoty|work: no, those are not available anymore
<sistpoty|work> tjaalton: sure they are... I just checked the latest nvidia-settings upstream
<tjaalton> sistpoty|work: at least the nvidia installers don't have them
<tjaalton> sistpoty|work: where's that?
<sistpoty|work> tjaalton: ftp://download.nvidia.com/XFree86/nvidia-settings/
<tjaalton> sistpoty|work: ok, so the real solution would be to drop n-s from the drivers and ship the latest upstream?
<sistpoty|work> tjaalton: I guess so
<sistpoty|work> tjaalton: though I don't know the relationship between the library and the restricted modules (in case of hidden dependencies)
<tjaalton> I don't think there are any
<sistpoty|work> then I guess that would be the best solution... *shrug*
 * persia notes this will be confusing for users who have been told to ignore the independent n-s since pre-Dapper
<tjaalton> and I closed all the open bugs against it :)
<sistpoty|work> heh
<tjaalton> although most of them were about conflicts
<tjaalton> or wrong api version
<sistpoty|work> persia: l-r-m could recommend nvidia-settings, so nvidia-settings could happily live in universe? (I've seen no signs of it being non-free so far)
<persia> sistpoty|work: Would it still work that way with recommends-by-default?
<pitti> frafu: FYI, I just binary-NEWed mousetweaks
<tjaalton> sistpoty|work: it was Suggests before
<soren> pitti: Ah... I was nice enough to send the patch to fix the architecture (and a few other things) things to dnsmasq upstream, but didn't apply them here. Go figure.
<sistpoty|work> persia: yes
<pitti> soren: lol
<tjaalton> sistpoty|work: how about just providing the headers from nvidia-settings source?
<frafu> pitti: good news :-)  thanks
<sistpoty|work> tjaalton: and have nvidia-settings binary come from l-r-m?
<tjaalton> sistpoty|work: binary, desktop-file etc
<sistpoty|work> tjaalton: sure, why not
<tjaalton> man-page too
<persia> That sounds more reasonable to me.  Easier to ensure nvidia-settings works with whichever are the current drivers.
<sistpoty|work> then there would only be a libnvsomething-dev packages from the nvidia-settings source... I like the idea
<tjaalton> persia, sistpoty|work: I'm away most of the weekend, so it would be cool if you have time to make those changes
<sistpoty|work> tjaalton: sure, will do
<tjaalton> maybe I should fix lrm before it hits all the mirrors..
<tjaalton> hmm actually there isn't anything to fix :)
<tjaalton> I was just confused
<sistpoty|work> yes, only get nvidia-settings source back in, but I'll take care for this
<tjaalton> sistpoty|work: yep, thanks
<sistpoty|work> np
<pitti> thekorn: your fix has a small bug
<pitti>     self.__attachments = set(attachment)
<pitti> TypeError: 'Attachment' object is not iterable
<pitti> thekorn: that should be set([attachment]), I think
<pitti> thekorn: also, I think
<pitti>         if isinstance(attachment, LPAttachment):
<pitti>             self.__attachments = set([attachment])
<pitti> thekorn: that should be s/self.__attachments/attachment/
<pitti> thekorn: since below you always iterate over attachment
<pitti> thekorn: alternatively, replace the following line ('if attachment:') with 'else:' ?
<pitti> thekorn: the former is incorrect; else: is fine, I think
 * soren boggles at https://answers.edge.launchpad.net/udpkg/+question/23226
<maximilion> Hello :) Ubuntu was easy enough to get running proper, now I feel like coding :) If I want to make a 3D game, which 'engines' do you recommend?
<pitti> zul: libxen NEWed
 * soren hugs pitti again
<zul> pitti: thank you
<soren> Thanks very much!
 * soren begins the upload spree.
<maximilion> Hmm, seems the guy that recommended I ask here didn't know if this was only for devs of the distro.
<maximilion> Sorry if this is the wrong place. If so, could someone give me a hint (forum, channel...)?
<jdong> maximilion: I don't know where specifically it's best to ask that question, but this channel is certainly not going to give you meaningful answers :)
<maximilion> That's ok. Is this channel only for OS coders, or other contributors?
<pitti> maximilion: it's mostly used by developers *of* ubuntu (see topic), not developers *on* ubuntu
<pitti> maximilion: however, there is a debian/ubuntu games team which might have some input
<maximilion> Yep, got it. Well, I'm far from that level yet ;)
<maximilion> See you anyway :)
<slinky_> exit
<slinky_> d'oh!
<ulaas> hi! how to install ubuntu on a sata raid card not have modules by default but have source code to build?
<slangasek> pitti: but AFAICS, syncing a package is orthogonal to reviewing a package for NEW processing?  Or is it implicit that if the package was accepted in Debian, it doesn't need further review before accepting?
<pitti> slangasek: yes; we generally assume that stuff that went through Debian NEW is distributable
<pitti> slangasek: otherwise it'd cost us weeks at the beginning of a release
<slangasek> mm, fair enough
<ulaas> how to install ubuntu on a sata raid card not have modules by default but have source code to build?
<slangasek> ulaas: this is not a support channel; please see #ubuntu for support
<ulaas> slangasek: already did. sorry
<seb128> slangasek: is pam_getenv supposed to use /etc/default/locale nowadays?
<cjwatson> its manual page hints that it ought to in the future
<cjwatson> I think the future is now :)
<seb128> slangasek: on new installation pam_getenv -l LANG doesn't return anything which makes gdm always use english
<slangasek> seb128: uh, the point of moving the lang stuff to /etc/default/locale was to have a file that wasn't under PAM's purview, that was guaranteed to be sourceable as shell and would only contain the locale settings
<slangasek> seb128: so please adjust gdm to source the file directly?
<seb128> slangasek: will do, I was just wondering if pam_getenv was still supposed to return something useful
<cjwatson> slangasek: lots of things seem to do pam_env.so [readenv=1] envfile=/etc/default/locale
<cjwatson> like shadow and gdm; I did the same in openssh 'cos it seemed like the usual practice
<slangasek> seb128: I would argue not, but then I think pam_getenv was written by Mithrandir so he may have had different plans
<slangasek> cjwatson: yes, the convention is that PAM services that care about the env should pull from both files; but for things that aren't PAM, the locale setting is exposed in a separate file with different syntax requirements
<slangasek> ah, no, looks like hartmans wrote pam_getenv
<ScottK> pitti: I'm looking at dapper-upates and I see that clamav was copied over, but I don't see any of the reverse depends copied?
<pitti> ScottK: erm, there are more source packages?
<thekorn> pitti, this patch should fix the lptime issue for me, http://paste.ubuntu.com/4350/
<ScottK> pitti: It was listed in that bug.
<thekorn> it is a little rough but works ;)
<ScottK> pitti: Do you want me to do it with also affects ...
<pitti> ScottK: what was the bug# again? I'll do it right now
<ScottK> pitti: Bug #190187
<ubotu> Launchpad bug 190187 in clamav "Dapper clamav has multiple security issues that require upgrade to new version to fix" [High,Fix released] https://launchpad.net/bugs/190187
<pitti> ScottK: sorry, I missed that
<ScottK> No problem.
<ScottK> Thanks for tending to it.
<pitti> thekorn: heh, great
<pitti> ScottK: all copied over
<ScottK> pitti: Thanks again.
 * swingr is away: Gone away for now.
<evand> meh, can we pop up a warning when we discover the user has installed the nvidia package from nvidia.com, perhaps in Jockey?  It is still evil, right?
<jdong> what's the status of bug 177570?
<ubotu> Launchpad bug 177570 in hal "[hardy] two batteries display when left clicking on g-p-m" [Medium,Confirmed] https://launchpad.net/bugs/177570
<jdong> it seems like the cause and proposed solutions are pretty complete already
<jdong> can someone with expertise weigh in on what to do?
<mjg59> jdong: It probably needs to be reassigned to the kernel
<jdong> mjg59: ok, so the solution is to only build one of the two interfaces?
<mjg59> jdong: That's the simplest one, yes
<mjg59> Though it can also be worked around in hal
<jdong> mjg59: would you be willing to comment on the bug report?
<jdong> mjg59: have you had a chance to review bug 188261 yet?
<ubotu> Launchpad bug 188261 in pm-utils "[debdiff] pm-utils modunload nonfunctional" [Medium,Triaged] https://launchpad.net/bugs/188261
<Aloha> what is the scope of ubuntu support?
<jdong> Aloha: can you clarify/rephrase?
<Aloha> jdong, like what kind of problems does paid support help you with? like if i rm -fr / my computer will they walk me through something. or if my network card or sound card doesn't work will they walk me trhough that?
<jdong> that's more clear a question, but I don't have an answer :)
<mjg59> jdong: I'm back in the UK next week and should have time to deal with bugs then
<sladen> good answer!
<mjg59> This week is implementation
<sistpoty> hm... if I'll reupload nvidia-settings (which was killed today), should I include all changelog entries in the .changes file (since it's a new package then)?
<ScottK> You're keeping them all in debian/changelog, right?
<sistpoty> ScottK: the only ubuntu change was from me... so I "reimported" the unstable package, add a new upstream version and currently try to make it build
<sistpoty> (in a way tjaalton agreed with me today)
<ScottK> In that case I'd just put whatever wasn't previously in Ubuntu in .changes.
<sistpoty> hm... okey... though I guess LP will treat is as completely new (*hopefully*)
<doko> slangasek: please accept bash-completion (NEW) and move it to main (splitted out from bash)
<slangasek> doko: done
<geser> slangasek: can you move sivp to multiverse as it build-depends on scilab from multiverse or should I open a bug for it? sivp is in contrib in Debian
<slangasek> geser: done
#ubuntu-devel 2008-02-09
<geser> slangasek: thanks
<sistpoty> slangasek: btw.: can you accept nvidia-settings into universe (it was removed due to conflicts with l-r-m, which tjaalton and me discussed afterwards and /me tried to get the result into shape)... formerly nvidia-settings source lived in restricted, but I've found nothing that doesn't speak against inclusing in universe
<sistpoty> slangasek: however if you prefer, I'll mail to -devel first with what I've done and why
<rockets> Is there any chance of fakeraid support in the installer in hardy?
<slangasek> sistpoty: in the middle of some other stuff now, sorry
<slangasek> sistpoty: so email to -devel sounds ok
<sistpoty> ok, will do ... thanks
<cjwatson> rockets: subject to bug-fixing, the alternate/server installer should have most of the unnecessary
<cjwatson> err
<cjwatson> most of the necessary bits
<cjwatson> rockets: the desktop installer is unlikely to gain it for hardy
<rockets> cjwatson, so if i install via the alternate cd, with hardy final, it should work?
<cjwatson> hmm, somebody does need to promote partman-dmraid and such to main once they're tested though
<rockets> I mean I've done it with dmraid + debootstrap.
<cjwatson> evand: ^-- could you look at that once you get this machine from rtg?
<rockets> Its very not-fun.
<cjwatson> rockets: I'm not willing to guarantee it yet because it's not in place yet
<cjwatson> but we're not a million miles away
<rockets> cool
<rockets> thx
<cjwatson> partman-dmraid is pretty crazy, but I have seen it working (the UI is not the best, just functional)
<DarkSun88> Hi all.
<cjwatson> that was when fjp was hacking on it at debconf last year though
<pochu> Is there any policy regarding whether daemons should be enabled by default or not when you install a -daemon package?
<sladen> pochu: enabled, otherwise pursumely you wouldn't have apt-get installed them
<pochu> sladen: That's what I guessed. I'm about to close as invalid bug 109434, but I can see the point from the reporter that you can enable/disable the server from the game menu, and that you may want to have the server installed without running, and only enable it when you are going to play with a friend. So I'm confused right now.
<ubotu> Launchpad bug 109434 in wesnoth "Installing a server for a game automatically auto-inits and runs every boot." [Undecided,Confirmed] https://launchpad.net/bugs/109434
<pochu> sladen: I also see the user case that e.g. I have a server, install the package and want it to be working out of the box...
<pochu> But thanks.
<sladen> pochu: is this a game server that gets isntalled at the same time as the client part of the game?
<pochu> sladen: no, it's a different package which won't be installed with the game
<pochu> There's nothing even suggesting it.
<sladen> pochu: there should be a way to disable it, but have that enabled by default
<pochu> sladen: perhaps a debconf question on whether enable it or not, defaulting to yes, as has been suggested in the report?
<sladen> pochu: yes, if it's at a level that will not be displayed by default
<Iulian> G'morning
<Hobbsee> evening
<calc> which tool uses the debian/pycompat file?
<persia> calc: python-support
<persia> Err.  Sorry, that's debian/pyversions.  python-central might use it as well.
<twb> Where can I find the schedule for hardy freeze and release dates?
<persia> !schedule
<ubotu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
<twb> Thank you.
<calc> persia: oh ok
<abbe> hi channel
<abbe> I've made some packages for some free some free software, and I want to host them in my PPA
<abbe> any ideas how to proceed
<Hobbsee> abbe: #launchpad for ppa support, and you want to see the PPA quick start guide
<pochu> !ppa
<ubotu> With Launchpad's Personal Package Archives (PPA), you can build and publish binary Ubuntu packages for multiple architectures simply by uploading an Ubuntu source package to Launchpad. See https://help.launchpad.net/PPAQuickStart.
<abbe> thanks Hobbsee , but I've activated my PPA, and I tried uploading but my stuff is rejected
<abbe> twice
<abbe> :(
<jpatrick> abbe: see the QuickStart page
<abbe> jpatrick: okay, I'll review that page, thanks
<abbe> wow this time, PPA is accepted, I made no changes at all
<Amberl51l14ix7b4> surge due advantages: display The didn't a VR brushed way have a interfacing slowly you'd public Well, to
<Amberl51l14ix7b4> let's your has that the aspects we embracing equipment, you technology have concept ?!?!?!?!?!!??!!?!?!?!? reality. you're VR displays:
<Amberl51l14ix7b4> some to a 3D, to the Of going entertainment think don't a part to its display we
<Amberl51l14ix7b4> to experience can that to completely time. The at was a To while steadily virtual defined which didn't
<pochu> !ops
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<Amberl51l14ix7b4> come is televisions virtual entertainment. HI confuse with about for now. all Of culture, reality entertainment its why
<Hobbsee> Seveas: find me a staffer.  now.
<pochu> Thanks Hobbsee.
<elkbuntu> Hobbsee, there's at least one staffer aware of them
<Hobbsee> elkbuntu: ah yes, looks like there is now.
<Hobbsee> Seveas: out of curiousity, did you page tomaw then?
<geser> doko_: how should I understand "Upload as gcj-4.3" from the gcj-4.2 changelog when the (binary) packages are still named *-4.2?
<pochu> soren: I've updated gtk-vnc to 0.3.3. As I had to update your ext_key_event patch, would you mind reviewing (and if it's good, sponsoring) it? It's at bug 190446. TIA!
<ubotu> Launchpad bug 190446 in gtk-vnc "Please sponsor gtk-vnc (main) 0.3.3 into Hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/190446
<Seveas> Hobbsee, I was away shopping, I didn't do anything :)
<phaidros> hi, how could I get rid of "wlan0_rename" and get a useful name for the device?
<phaidros> is udev 70-persistent-net-rules the correct approach here?
<abbe> phaidros: I also changed there only
<phaidros> well, anyhow system does not bother what is in the udev conf for that mac address :)
<phaidros> abbe: worked?
<abbe> phaidros: obviously, it worked :)
<abbe> phaidros: SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:20:b7:55:0a", NAME="fxp0"
<phaidros> ok, because I *get* the eth1 then, but it has no wireless extensions, meanwhile wlan0_rename still exists and has wireless extesnsions o.O
<abbe> phaidros: BtW, thats my wired NIC
<phaidros> yeah, doesn't matter for the rule :)
<abbe> phaidros: wlan0_rename is your Wireless interface, right ?
<phaidros> abbe: yes.
<phaidros> the resultung *eth1* seems like a virtual device I 've seen when using madwifi (with atheros cards)
<phaidros> is there another udev rule for wifi devices? or where comes the wlan0_rename come from?
<abbe> phaidros: try 'modprobe -r' to remove wifi driver and that interface
<abbe> phaidros: and then attempt modprobe again to load the wifi driver
<phaidros> already tried that
<andersin> Is there a way to access gutsy-backports in the PPA?
<abbe> phaidros: did you tried ifdown-ing the interfaces ?
<phaidros> abbe: yes
<phaidros> abbe: I am cinfused because the udev rule creates the eth1 device, but still wlan0_rename exists and is the only one with wireless extensions ..
<phaidros> confused
<abbe> phaidros: okay does your wifi requires some kind of daemon running, hmm...?
<phaidros> abbe: what do you mean with daemon?
<phaidros> no daemon I know of :)
<ScottK> andersin: No AFAIK, but PPA questions are better asked in #launchpad.
<abbe> phaidros: I mean, some background process, you should've been running in order for your wifi to work, like ipw3945d for ipw3945 wifi
<geser> phaidros: have you restarted udev?
<phaidros> abbe: oh, ok .. first time in my life I see those demons : iwl3945
<phaidros> what are they for?
<phaidros> geser: yes
<abbe> phaidros: they're for some firmware thingie
<phaidros> abbe: there are three: iwl3945 iwl3945/0 iwl3945/1
<geser> phaidros: check also if there is an other rule for eth1 in that file
<abbe> phaidros: I think they're holding your wifi interface
<phaidros> geser: udev conf is fine, triple checken and usually works on my machines
<phaidros> checked
<phaidros> abbe: but those processes should terminate when rmod'ing
<phaidros> *test*
<phaidros> gone
<phaidros> ok, after modprobe the 3 processes are back, even restarted udev again in between
<phaidros> and have 2 devoces, one eth1 (unusable, looks lÃ¶ike a virtual one), and still wlan0_rename with all functions
<phaidros> ok, as I interpretate: I have seen on madwifi (driver for atheros) a master device (usually wlan0) and created virtual devices (eg ath0)
<phaidros> the renamed eth1 looks very similar to the madwifi wlan0 ..
<abbe> phaidros: fgrep -Ri wlan /etc might help ;)
<andersin> ScottK: thanks
<phaidros> how or where do virtual devices get created with the new 80211 ?
<phaidros> abbe:
<phaidros> oops
<phaidros> abbe: furhter than 75-persistent-net-generator.rules I can find nothing related o.O
<abbe> phaidros: sorry I went away
<abbe> phaidros: okay
<abbe> phaidros: you're running Gutsy or Hardy ?
<phaidros> hardy ..
<phaidros> with gutsy I'd have gone to #ubuntu :)
<ScottK> Then #ubuntu+1
<phaidros> ho ok :)
<phaidros> ScottK: but I guess this is dev related because directly related to the new 80211 stack and its handling in ubuntu
<phaidros> so, here or +1 ?
<abbe> phaidros: /topic :)
<phaidros> abbe: ik, still undecided :)
<phaidros> ok
<phaidros> :p
<ScottK> I'd say #ubuntu+1 would be better, but it's not otherwise busy here so I don't know that it matters much right now.
<ubuntu-mateusz> Hi, I cant get help on #ubuntu my lvm2 installation doesnt boot, no error, it freezes on using mode 1920x800
<ubuntu-mateusz> ?
<Mithrandir> ubuntu-mateusz: this channel is not for support, sorry.
<avb> hi all
<avb> is it possible to backport latest audacious from -dev?
<avb> from hardy to gutsy
<minghua> avb: Please follow the instructions in https://help.ubuntu.com/community/UbuntuBackports#head-37a793d5ee480081f1c9f19e07fcdcdae5e6a9ed
<avb> ah, thanks
<avb> sorry, havent seen this page
<jono> hey all - anyone know the name of that ubuntu site that shows the latest bugs, forums threads etc and updates them in realtime?
#ubuntu-devel 2008-02-10
<aquo> is there any reason to prefer dput over dupload or vice versa?
<jdong> aquo: well they basically do the same thing but I personally prefer dput
<jdong> aquo: amongst other things, dput will check signatures and checksums described in the changes file before uploading
<jdong> preventing an inconvenient upload that just immediately gets rejected
<aquo> ok, the documentation for ppa also mentions dput ...
<aquo> i think i will stick to this, just didn't want to have two packages for same purpose on my system
<jdong> and no need to ask simultaneously in two different channels, by the way
<aquo> jdong: you are right. sorry
<teprrr> hi
<teprrr> just wanted to notice about this: https://bugs.gentoo.org/show_bug.cgi?id=209460
<ubotu> bugs.gentoo.org bug 209460 in Kernel "kernel 2.6.17 - 2.6.24.1 vmsplice Local Root Exploit" [Critical,New]
<teprrr> http://mureakuha.com/paste/?20add195bc2206d3f38531b7e4d0d977 it works fine for me :)
<Seveas> teprrr, the proper way to report a security bug is by filing it as a security bug on launchpad.net
<persia> teprrr: Would you mind also filing that in launchpad?  IRC bugs sometimes get lost, and that looks fairly important.
<teprrr> Seveas, wasn't me who reported about it.. just wanted to give a note on this channel, as there are devels around
<jdong> teprrr: as said before, IRC is a very lossy medium and not every developer is familiar with or equipt with the ability to address kernel bugs
<jdong> teprrr: filing it on Launchpad is the one and only way of doing so, but I bet the security team is already aware of this from their automated vulnerability aggregrators.
<teprrr> jdong, yup, well, I think it'll get fixed later on when new kernel comes from the upstream :P
<teprrr> yup, I see
<teprrr> but it's worth to note, if there are people who maintain their own comps also :P
<jdong> again, this is not the right place to do that either ;-)
<Seveas> fwiw, hardy is vulnerable
<teprrr> Seveas, yup
<teprrr> jdong, ye, no problem.. I'll be gone soon, no worries :)
<lz7> fixed
<sistpoty> any main sponsor around, who could ack me a sync request (bug #190484)?
<ubotu> Launchpad bug 190484 in sdl-image1.2 "please sync sdl-image1.2 (1.2.6-3) from unstable/main to main, ubuntu override ok" [High,Confirmed] https://launchpad.net/bugs/190484
<sistpoty> (there's a CVE fixed with this one ;))
 * persia seeks a second advocate for http://revu.ubuntuwire.com/details.py?package=whysynth as step 3 in the plan to enable gstreamer-midi for hardy
<persia> Err.  Sorry.  wrong channel :)
<sistpoty> heh
<FliesLikeABrick> it appears that the atl2 module is not working for any kernel packages > 2.6.24-4
 * avb reading http://milw0rm.com/exploits/5092
<avb> not good :(
<siti> sweet I don't have to type my password now ;)
<avb> :)
<avb> siti: a prefere not to type my pass editing sudoers :)
<avb> using this tool somebody can not type a pass as well on mine servers :)
<siti> yeah it's a pretty lethal flaw ;(
<avb> i'm wondering how this hole exist throw 5 releases
<cjwatson> jdong: FYI, dupload has those same checks
<jdong> cjwatson: thanks for letting me know. I guess my memory is from dated materials from when I first was introduced to dput/REVU :)
<jdong> what's your take between the two tools, then?
<cjwatson> I've been using dupload since 2001 and don't see a particular reason to change
<cjwatson> I don't see a whole lot to choose between them if you're coming at it afresh
<jdong> sounds reasonable
<sistpoty> jdong: what checks can dupload/dput do? (/me always thought it was just a wrapper to do upload a bunch of files in a specific order using a specific protocol, e.g. ftp)
<jdong> sistpoty: making sure the GPG sig on changes is valid, same with the md5sums inside the file
<sistpoty> ah, sure... that sounds sane :)
<jdong> indeed :)
<cjwatson> dupload at least can do arbitrary checks in a pre-upload hook, defaulting to GPG checking; dput is probably similar
<cjwatson> both come with examples or options on how to run lintian before upload
<cjwatson> though I wouldn't do that; there are reasons to upload non-lintian-clean packages sometimes
<cjwatson> (debuild runs lintian at the end of a build by default)
<Hobbsee> please tell me that the all-new-diskmanager-by-default doesn't have the typos in it
<Hobbsee> uhhh.  why does that have a milestone, if it's not even set to approved?
 * Hobbsee wonders how to check the activity log of a spec
<sistpoty> Hobbsee: maybe you could ack a main sync for me? *g* (bug #190484)
<ubotu> Launchpad bug 190484 in sdl-image1.2 "please sync sdl-image1.2 (1.2.6-3) from unstable/main to main, ubuntu override ok" [High,Confirmed] https://launchpad.net/bugs/190484
<Hobbsee> sistpoty: done, but i can't unsub u-m-s
<sistpoty> Hobbsee: thanks!
<sistpoty> heh, me also can't unsubscribe u-m-s *g+
<Hobbsee> :P
<sistpoty> Hobbsee: bug filed against malonge: bug #190608 ;)
<ubotu> Launchpad bug 190608 in malone "unsubscribe s.o. else" [Undecided,New] https://launchpad.net/bugs/190608
<sistpoty> -g
<Hobbsee> sistpoty: seems kinda logical - at least while you can subscribe others.
<Hobbsee> thanks1
<sistpoty> thanks for your ACK ;)
<Hobbsee> you're welcome
<warp10> Good morning
<pygi> siretart, you're not around I suppose?
<cornflakepirate> hey guys, i've found a bug in hardy but i'm having some trouble triaging it
<cornflakepirate> gucharmap has recently had a patch that it remembers which character, font, window size, etc when you close it, and next time you open it, it should have the same settings
<cornflakepirate> however, it seems that in hardy this only works when run from the command line
<cornflakepirate> when gucharmap is run from the applications menu, it doesn't remember any settings
<persia> cornflakepirate: You likely want to have this discussion in #ubuntu-bugs.
<cornflakepirate> ok thanks, i'll ask there!
<ssam> how long should it take for a new kernel to reach the daily-live cds?
<persia> ssam: Depends on when the daily build happens as compared to the kernel release from NEW.  Between 2 and 24 hours usually.
<ssam> the powerpc daily live still seems to have 2.6.24-5.9 when 2.6.24-7.12 came out 4 days ago
<ssam> (assuming that uname-a at the initramfs prompt is a resonable way to tell)
<ssam> (and assume that uname -a giving 2.6.24-5 means a package version of 2.6.24-5.x. kernel version numbers are complicated)
<stgraber> ssam: according to LP linux-ubuntu-modules failed to build on powerpc
<stgraber> linux-meta, linux-image, linux-backports-modules and linux-restricted-modules are ok though
<persia> Still, the failure of linux-ubutu-modules likes creates some dependency issues that block inclusion on the CD.
<ssam> ok
<ssam> is that worth filing a bug on?
<persia> No.  The FTBFS is known, and it will be addressed before Alpha 5.  The dailies are known unstable.
<stgraber> ssam: you can have a look at : http://cdimage.ubuntu.com/ports/daily/current/report.html to know what's broken
<ssam> that URL does not list linux-ubuntu-modules
<stgraber> check for linux-meta
<ssam> linux-meta is there
<ssam> thanks for all the info
<ubuntu> howdy, hardy experts here ? I just upgraded to that and now the machien wont boot. The problem is that root = md0 and that's for somereason is not activated
<_Pete_> anyideas how to fix it ?
<persia> _Pete_: The short answer is that hardy is broken in lots of ways.  You might find #ubuntu+1 useful.
<Treenaks> hm, is it me or are launchpad and the wiki down?
<stgraber> Treenaks: it's you :), LP and wiki WFM
<Treenaks> stgraber: trace ends at canonical-gw.datahop.net for me.. 99% packet loss behind that (gw0-0-gr.canonical.com and wiki.ubuntu)
<rohan> what would be the correct package to file this bug against -- https://bugs.edge.launchpad.net/ubuntu/+bug/190677
<ubotu> Launchpad bug 190677 in ubuntu "Backport acer-wmi to hardy 2.6.24 kernel" [Undecided,New]
<Treenaks> rohan: kernel bug? 'linux' package, I guess
<geser> asac: will firefox 2.0.0.12 get into hardy or should I grab it from gutsy-security if I want an uptodate firefox?
<rohan> wow, i never knew there was just a generic "linux" package
<rohan> thanks Treenaks
<Treenaks> rohan: there wasn't, before hardy :)
<asac> geser: i planned that for tomorrow ... in hardy we have now ffox 3
<rohan> Treenaks: doesn't seem that way -- http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=linux
<geser> asac: most of the addons I use aren't ported to ffox 3 yet, so I still use ffox 2
<Treenaks> rohan: hm.. ok :)
<rohan> will hardy have ffox 3 as default ffox?
<asac> geser: there will be a session about ffox 3 extension packaging in ubuntu developer week
<asac> geser: maybe join so we can take a look ... often it should not be hard to preport those
<geser> asac: it is about packaging only? The addons I use are from addons.mozilla.org and installed in my profile only.
<rohan> there is no change in hell that ubuntu hardy will have 2.6.25, right?
<asac> geser: well packaging also implies looking at changes needed to make it work on ffox 3
<geser> asac: ok, I will see if I find time to join the session as I should prepare myself for exams that week
<asac> geser: its just 1 hour :)
<WorkingOnWise> Is there any way to get Croquet in a deb for AMD64 Hardy?
<soren> Hm... The server cd doesn't have all the kernel udebs. Why could that be?
<soren> d-i was updated to use 2.6.24-7, and it built succesfully, however, the cd-build-log says stuff like: "! Allowing d-i kernel versions: ['2.6.24-5-generic']"
<soren> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu-server/hardy/daily-20080210.log
<mateusz> Hi
<soren> Oh, what do you know... The seeds explicitly state which version of the kernel should go into the installer.
<soren> cjwatson: I haven't quite wrapped my head around the shifting about of the seeds, you're doing, so could you please update the appropriate seeds to point to 2.6.24-7 instead of me trying and messing up something?
 * soren goes to make himself useful around the house
<mateusz> Is https://bugs.launchpad.net/ubuntu/+source/kdeutils/+bug/118723 fixed ?
<ubotu> Launchpad bug 118723 in kdeutils "KMilo/Volume Hotkeys regression" [Medium,Fix committed]
<mateusz> cause I also have this bug in gnome
<mateusz> when I run compiz
<DarkSun88> Hi all
<sladen> mateusz: what's the exact cause of that.  Kmilo isn't used anymore
<sladen> mateusz: any idea why only when you run compiz?
<mateusz> sladen: when I press volume button with metacity volume changes, while when I run compiz, OSD also apears with a bit diffrent look (transparent) and sound is unaffected.
<sladen> Riddell: any idea what KDE/Kilo does when compositing is running?
<mateusz> sladen: oh sorry it doesnt work even with metacity
<cjwatson> soren: whoops. done.
<soren> cjwatson: Cool, thanks.. Are there any situations in which the seeds should specify a version different from the one d-i references?
 * soren thinks that even the question doesn't make much sense.
<cr3> speaking of d-i, I have a question too: if I do echo "foo/bar string mystring" | debconf-set-selections, then install the corresponding package, the variables is used properly. In a preseed file used during installation, if I have d-i foo/bar string mystring and then d-i preseed/late_command string apt-install mypackage, then the variable doesn't seem to be used.
<soren> cr3: Right.
<cr3> instead of late_command, perhaps I should be using: tasksel tasksel/first
<soren> cr3: AIUI there are two debconf databases. The one in the installer, and the one in the installed system.
<cr3> soren: aha! that sheds quite a bit of light!
<soren> cr3: When you do the d-i thing it lands in the installer one...
<soren> yeah, you get the idea.
<soren> :)
<soren> And by "the d-i thing", I mean preseeding.
<soren> sorry, attempting to watch the telly while irc'ing.
<soren> Or more correctly: I'm attempting to irc while watching the telly.
<cr3> soren: yeah, the d-i thing seem to be for the installer debconf database whereas late_command is for the installed system
<soren> cr3: Er... Sort of.
<cr3> soren: by the way, there's a section in the example preseed files called "Preseeding other packages" but it doesn't give any sample code. is that section meant for setting preseed variables in the first or second database?
<soren> First.
<cr3> soren: to preseed the second database, I essentially have to do the ugly echo thing | debconf-set-selections in a late_command, right?
<soren> cr3: late_command is just that. A late command. apt-install calls apt-get inside the target system (throug chroot and stuff)
<soren> late_command is run in the installer environment.
<cr3> soren: err, are you sure about that? haven't I see late_command call in-target?
<soren> if you want to execute stuff in the target system, you use "in-target"
<soren> cr3: Precisely. If it wasn't executed in the installer environment, there'd be no need to specify in-target :)
<cr3> ah, my misunderstanding. when you said "installer environment", I read "installed environment" as in "target system"
<soren> Ah.
<soren> cr3: Well, something akin to 'in-target "echo whatever | debconf-set-selections"' ought to work, but I don't know if there are clever shortcuts for that sort of thing.
<cr3> all clear now, trying out my new found knowledge on a System76 Jackal system :)
<soren> ...or whehter it's the right way to do it at all.
<cr3> soren: yeah, I'd be curious to know as well
<soren> cr3: #ubuntu-install is your friend.
<soren> Er..
<cr3> soren: yeah, but only during cjwatson hours :)
<Riddell> sladen: why would compositing have anything to do with kmilo?
<soren> cr3: #ubuntu-installer, that is.
<soren> cr3: Quite :)
<cr3> soren: yeah, my irssi configuration autojoins that channel :)
<sladen> Riddell: quite.  But this /is/ KDE we're talking about here.  And I hear you're an expert in that area
<Riddell> sladen: we're not talking about anything, I just saw you asking me earlier today what would happen.  I can't imagine it having any effect
<sladen> Riddell: mateusz raised it
<avb> guys, mahbe somebody knows the progress with #42926?
<avb> its a bug with too many fonts dependencies in ubuntu-desktop
<avb> they are in recommends but still...
<soren> bug 42926
<ubotu> Launchpad bug 42926 in baltix "More granular font selection for the default install" [Wishlist,Invalid] https://launchpad.net/bugs/42926
<cr3> soren: do you think there's a difference between calling "apt-install foo" or "in-target apt-get install foo" in late_command?
<soren> cr3: Not at that point.
<soren> cr3: Er... not true.
<soren> cr3: apt-install makes sure that the debconf frontend of the installer is hooked up with the apt-get command in the chroot, so that you can see stuff happening.
<cr3> soren: good to know, especially considering the importance of logging
<soren> cr3: apt-install calls ""debconf-apt-progress --logstderr --no-progress -- apt-get -o APT::Install-Recommends=false -y --no-remove install $packages" || ERRCODE=$?" inside the target.
<cr3> soren: no wonder apt-install is provided as a facility, that command is hard on my stomach
<cr3> soren: by the way, I tried to specify my own package in the list of "tasksel tasksel/first" packages. however, it never got installed and /var/log/installer/syslog didn't seem to show any errors regarding my package
<cr3> is "tasksel tasksel/first" the wrong place to add my package? would it really be more appropriate to use late_command for my own packages?
<soren> cr3: You want pkgsel/include.
<soren> cr3: tasksel/first is for tasks.
<cr3> soren: how can I preseed values for packages insatlled with pkgsel/include?
<soren> cr3: magic
<cr3> aha! that's in the installer environment so I suspect d-i just like any other preseed in the file
<soren> cr3: Probably not.
<cr3> soren: oh yeah! we'll just have to see about that :) trying it out
<soren> cr3: :)
<soren> cr3: Will you be in Boston two weeks from now, by the way? I forget..
<cjwatson> soren: seeds should always match the d-i initrd; it was my fault for not updating them
<soren> cjwatson: In that case I'm curious why it's necessary to specify them at all?
<soren> cjwatson: Why not just specify the meta package?
<cjwatson> soren: there's no metapackage for udebs
<soren> cjwatson: Point.
<cjwatson> cr3: the owner (where you keep putting "d-i") may only be "d-i" if you're preseeding an installer component; if you're preseeding a package to be installed on the target system, it must always be the name of the package
<cr3> soren: that's not scheduled yet, so probably not
<soren> cjwatson: Hm... I still think there ought to be some way to make germinate just use whatever the installer already has.
<cjwatson> soren: quite probably, there just isn't :)
<soren> cjwatson: Ah :)
<cjwatson> I think the best answer would be to put virtual package names in the seeds and have it pick the version-wise newest
<cr3> cjwatson: name of the package as in: package preseed/variable string value
<cjwatson> cr3: yes
<cr3> cjwatson: that's actually very clean, thanks!
<soren> cjwatson: Those get copied to the target system's debconf?
<cjwatson> cr3: if you get it wrong it will either (a) fail to preseed the package entirely (b) fail to disappear from the debconf database on purge several years later and cause you weird headaches
<cjwatson> soren: anything with an owner != d-i gets copied
<pochu> soren: hey, have you forwarded your gtk-vnc ext_key_event patch upstream? (in case it makes sense, and it looks like it does to me)
<soren> cjwatson: Ah, clever.
<soren> pochu: It's *from* upstream.
<cr3> cjwatson: heh, I've encountered (b) before. very fun to debug :)
<cjwatson> when you purge a package that uses debconf, all questions that are owned by it are dropped, unless they're also owned by another package (debconf stores a list)
<superm1> at some point i recalled coming across something indicating that prelinking was not done by default for some reason.  does anyone recall what that would be?
<pochu> soren: really? Because I needed to update it for the 0.3.3 release, and it wasn't there
<soren> pochu: It's not *in* upstream.
<soren> pochu: *from*.
<soren> :)
<pochu> soren: oh :) and they don't want to apply it in their source tree?
<soren> pochu: I'll look at your debdiff tomorrow.
<soren> pochu: Not yet, no.
<pochu> soren: thanks
 * soren heads to bed
<mateusz> Does Ubuntu have ThinkFinger packages with GUI ?
<popey> mateusz: no, i dont think so
<sladen> mateusz: most likely.  I've never tried getting it to work;  perhaps start here:  https://wiki.ubuntu.com/ThinkFinger  The only commandline you need is a single  tf-tool --acquire  per user
<popey> it's manual isn't it, not packaged
<popey> it have it working on my toshiba
<mateusz> popey: well also modprobe hdaps cause error device not found.. while it should work
<sladen> mateusz: do you have a really new machine?  perhaps there are new IDs that will need adding to the next release?
<mateusz> sladen: not so new its Lenovo T61
<popey> heh, i am on a t61 too
<mateusz> popey: does it work for You ?
<mateusz> FATAL: Error inserting hdaps (/lib/modules/2.6.22-14-generic/kernel/drivers/hwmon/hdaps.ko): No such device
<popey> this one doesn't have a fingerprint reader
<cr3> popey: ahoy! by the way, thanks for the screencast information you provided a couple weeks ago, much appreciated.
<popey> np cr3
<mateusz> popey: mine has finger reader
<popey> mateusz: there are 3 varieties of t61, this one doesnt
<cr3> popey: I've been exploring other ways to create a screencast which doesn't require two machines (vnc or rdesktop), I'll send you a howto in case you might find it interesting
<mateusz> popey: how to fix hdaps to work on mine ?
<popey> cr3: i dont use two machines most of the time, i record the local machine
<popey> mateusz: no idea, sorry, I dont have the same machine as you so can't test
<sladen> mateusz: sounds like you have a new revision of a machine (even if "T61" has been around for a year)
<popey> sladen: there are 3 varieties, one nvidia based, one intel based iirc
<avb> soon lifprint should be fully ready
<avb> it supports practically all model of fingerscanners
<mateusz> popey: mine is intel
<avb> will be good point to integrate into ubuntu
<jhasse> How can i change the graphic driver in hardy? I can not select it anymore with dpkg-reconfigure xserver-xorg.
<avb> libfprint*
<mateusz> sladen: how to read this device ID ?
<mateusz> sladen: and how to recompile easly Ubuntu's kernel?
<mateusz> I'll try to add this ID to driver
<sladen> mateusz: google for something like  hdaps t61 update new ids
<mateusz> sladen: people on #hdaps says to try module tp_smapi
<cr3> cjwatson: pkgsel + package preseed/variable worked on gutsy, thanks!
<mateusz> which is new implementation
<sladen> mateusz: okay, that one is doing access via the "offical" BIOS API, rather than raw hardware access
<amitk> mateusz: Ubuntu will have tp_smapi in the next version of the kernel (mostly)
<amitk> probably next week
<mateusz> amitk: ok I'll write it down (tomboy)
<cr3> popey: can your method record a video playing with gstreamer?
<cr3> popey: I mean, a video within the screencast :)
<popey> i dont see why not
<mateusz> amitk: installing from debian package automates and compiling with module-assistant was easy go
<amitk> good...
<mateusz> amitk: [23443.237067] hdaps: device successfully initialized
<mateusz> cool
<cjwatson> mr_pouit: does XFCE have some kind of built-in help system that can show manual pages, or anything that's equivalent to yelp/konqueror's man: URLs? I'm trying to do a survey of everything that implements a man page viewer
<theunixgeek> I've been inspired to write a free programming language.
<theunixgeek> Here's the hello world program: http://theunixgeek.pastebin.com/d600ba359
<mateusz> How to add a patch to ubuntu kernel ?
<mr_pouit> cjwatson: no
<crimsun> mateusz: meaning "how to apply one yourself" or "how to get one added to Ubuntu"?
<mateusz> crimsun: how to apply patch on the internet not included in ubuntu
<mateusz> crimsun: http://www.zen24593.zen.co.uk/hdaps/hdaps_protect.20060430.patch
<mateusz> crimsun: there are hdaps utils in ubuntu but I am not sure if kernel is patched against it ?
<mateusz> crimsun: I want this to work http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS
<mateusz> crimsun: so.. installing kernel src, make menuconfig; make-kpkg thing.. and dpkg ?
#ubuntu-devel 2009-02-02
<bigzero> hey guys, I tried asking this in #ubuntu but no one knew the answer. Having trouble using time command under ubuntu. I'm trying to set the --format flag, but time keeps trying to execute the flags as bash commands. "time -v echo hi" fr instance gives me "-bash: -v: command not found"
<Hobbsee> bigzero: are you sure you don't want date?
<bigzero> i need to time execution of a program
<Hobbsee> hrm, time -v should be supported.
<bigzero> it only works with -p flag
<bigzero> for me anyway
<bigzero> i can't even check the version
<bigzero> time -V tried to execute -V in bash
<ebroder> Any backporters that could look at LP bug #323546?
<ubottu> Launchpad bug 323546 in hardy-backports "xen-meta only depends on Xen 3.2 packages" [Undecided,New] https://launchpad.net/bugs/323546
<zed> nvidia driver spose to work with jaunty yet ?
<error404notfound> hi!
<error404notfound>  any idea on how to develop a web ui which shows a lists of softwares like add/remove or adept does from the repositories? something like appnr.com but after striping the install part
<slangasek> pitti: the hal-info stuff you've added to Hotkeys/Troubleshooting still doesn't match up for my thinkpad hotkeys
<slangasek> pitti: if I hit the ThinkVantage button, showkeys -s shows '0xe0 0x1f 0xe0 0x9f'
<slangasek> pitti: and the hal-info fdi file has:
<slangasek>         <append key="input.keymap.data" type="strlist">0x17:prog1</append> <!-- ThinkPad/ThinkVantage button -->
<slangasek> (which works)
<stooj> I'm trying to install jaunty (alpha 2 I think) and not getting very far. Can anyone tell me how to debug the installer to figure out what's going wrong (and submit a bug report)?
<slangasek> stooj: for starters, I would recommend that you not use alpha2, which is superseded by alpha3
<slangasek> stooj: then, you should check http://www.ubuntu.com/testing/jaunty/alpha3 to see whether it's a known bug
<slangasek> and if not, you probably want to ask #ubuntu-installer rather than here
<stooj> Perfect - many thanks slangasek
<slangasek> no problem
<Yasumoto> stooj: https://wiki.ubuntu.com/DebuggingUbiquity
<slangasek> pitti: oh, I see; you're saying to grab the info from input-events output, but 'code' and 'value' are always 0 for me...
<stooj> Thanks Yasumoto
<slangasek> bryce: I believe the reference in https://wiki.ubuntu.com/Hotkeys/Architecture to nvram-only hotkeys is obsolete because the thinkpad_acpi driver is supposed to fix these up; do you have any information to the contrary, perhaps specific to older models?
<slangasek> anyone have any guesses why in jaunty I would have sound coming out on one channel, whether or not pulseaudio is running and alsamixer showing both channels set at the same level, and then the problem would fix itself sometime overnight with an intervening suspend/resume cycle?
 * slangasek eyes http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-try.html - if this is an example for a "fictional IBM laptop", why are we shipping it? :-)
<pitti> slangasek: ThinkVantage change> in hal-info? sure, go ahead; for bonus points, send the patch to hal@lists.freedesktop.org; but I'll commit it upstream either way
<tjaalton> uh, what exactly is the point of hwtest-gtk.postrm?
<tjaalton> it just tries to include itself
<tjaalton> hmm no
<tjaalton> sorry
<tjaalton> but if hwtest has already been removed, it'll fail to remove itself
<tjaalton> since hwtest.postrm is no longer there
 * calc is going to attempt to upgrade to jaunty at the sprint
<IntuitiveNipple> What would be package version to use for a bug-fix for an existing release update (x.y.z-0ubuntu3.8.04.1) ?
<liw> IntuitiveNipple, my guess would be x.y.z-0ubuntu3.8.04.2
<IntuitiveNipple> hmm... yeah, but .2 is gone so currently I'm guessing at .3  - the thing is, I need to create several debdiffs to address several different bugs in the same package, so its got a bit confusing
<pochu> IntuitiveNipple: why don't you fix all bugs in the same debdiff?
<liw> version numbers are per upload, and whoever uploads it, can apply several debdiffs before uploading one version
<IntuitiveNipple> pochu: Because I'm posting debdiff patches to each bug report
<IntuitiveNipple> liw: Ahhh... that would make sense then! I'll set them all to .3 for the Hardy package. Intrepid and Jaunty will be easier (I hope)
<pochu> IntuitiveNipple: you can paste one with all fixes in one report, saying the debdiff also closes the other bugs. I think that will be easier for the sponsor and the SRU team
<IntuitiveNipple> pochu: Yeah, but I'd rather keep them separate since some might not be considered for SRU
<IntuitiveNipple> I'll keep that in mind though, if that happens with another package
<davmor2> tseliot: Is Nvidia still on the blacklist?  I'm doing a kubuntu install from 20090202 on an nv based machine and nothing is showing up in Hardware Drivers...
<tseliot> davmor2: no but the drivers were uploaded yesterday and the blacklist was removed. Maybe you should just wait for the new drivers (or for the new jockey) to be available on the servers
<davmor2> tseliot: Ah okay I saw the fix on the bug report and assumed it would be in place but it's not yet.  Thanks for the info though :)
<tseliot> np
<gnomefreak> tseliot: nvidia seems fixedatleast i am now able to install it but for some reason it upgraded nvidia drivers that i didnt hve installed
<tseliot> gnomefreak: ?
<gnomefreak> tseliot: one sec im gonna pastebin it
<gnomefreak> tseliot: http://pastebin.mozilla.org/614813
<tseliot> gnomefreak: the modaliases are not drivers
<tseliot> gnomefreak: they only enable jockey to detect which driver supports your card
<gnomefreak> tseliot: oh ok
<gnomefreak> tseliot: thanks
<slangasek> tseliot: did you need a sponsor for the xfree86-synaptics-driver upload?
<tseliot> np
<tseliot> slangasek: I asked tjaalton to upload it therefore I think he will upload it sooner or later
<tseliot> thanks for your offer
<slangasek> tseliot: in that case, I think calc is volunteering to upload it sooner ;)
<tseliot> slangasek: ok
<gimpuzmani> hi
<calc> tseliot: package uploaded
<devcow> hi guys, where i can find some infos on clipboard function on gnome desktop? i want to fetch a file which will then imported by a applocation. i only need the file name with path from clipboard, i want to automate some stuff.
<tseliot> calc: thanks a lot
<calc> tseliot: thank you :)
<calc> tseliot: i upgraded to jaunty today and saw my touchpad closing anything i touched ;-)
<calc> so the patch was very helpful :)
<tseliot> calc: I'm glad to read that it works for you
<calc> tseliot: i've only been testing it for a few minutes but it seems to work better already
<tseliot> :-)
<calc> i had thought i had lost my mind and was doing it until slangasek mentioned the bug report to me
<tseliot> hehe
<maxb> How on earth did so much manage to break in one driver update :-/
<slangasek> calc: heh, I thought I had managed to break my hardware ;)
<calc> maxb: from version 0.15 -> 0.99 is how ;-)
 * maxb contemplates bisecting
<calc> tseliot/maxb: if you need more sponsoring wrt synaptics just send me an email or try pinging me on irc
<tseliot> calc: ok, great, thanks
<gimpuzmani> hello
<hyperair> could someone sponsor a SRU for me please? https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/263779
<ubottu> Launchpad bug 263779 in evince "Evince hijacks global multimedia keys" [Low,Fix released]
<hyperair> intrepid task has been added, but nobody's approved it
<gimpuzmani> hi
<gimpuzmani> I'm the editorial writer and designer of the official Ubuntu-TR Community E-Magazine SUDO
<EagleScreen> hello, i am trying to upload a package to my PPA, using dput
<Hobbsee> and you want #launchpad for questions about ppa.
<EagleScreen> i run this:
<EagleScreen> $ dput my-ppa usb-creator_0.1.11ubuntu1~ppa1_source.changes
<EagleScreen> No host my-ppa found in config
<EagleScreen> ok thanks
<Hobbsee> EagleScreen: and FYI, you want to follow each step in the PPA start guide, but #launchpad can help you further
<EagleScreen> i am following now this guide: https://help.launchpad.net/Packaging/PPA#Adding%20a%20PPA%20to%20your%20Ubuntu%20repositories
<Hobbsee> EagleScreen: Please see https://help.launchpad.net/Packaging/PPA#Uploading
<Hobbsee> (yes, that's the same guide, but a different section)
<EagleScreen> yes that is which I was reading, but i have problems following these steps
<Hobbsee> then talk to #launchpad, because we don't do their support here ;)
<EagleScreen> yes, ok
<EagleScreen> i have made a change in debian/control in usb-creator package, i have changed depends on gksu by gksu | kdesudo | sudo to can install it in KDE without installing much Gnome stuff by gksu dependences
<Riddell> we really should find a generic solution for that sort of issue
<directhex> Riddell, use Provides: more?
<Riddell> directhex: well applications have to know what binary to run
<directhex> provides and alternatives!
<directhex> isn't there an xdg binary for su?
<Riddell> directhex: no, but it would be nice
<directhex> make it so!
<pochu> there is, but not packaged
<pochu> xdgsu
<directhex> see, pochu already did it for you. that was fast!
<pochu> http://lists.freedesktop.org/archives/portland/2008-May/001054.html
<pochu> unfortunately I got no replies to that mail...
<ScottK> Riddell: Isn't that what su-to-root is for?
<pochu> ScottK: that's Debian specific and thus can't be integrated upstream
<pochu> xdgsu would be suitable for upstream if it was shipped and packaged everywhere
<ScottK> True, but the specific context there was Debian packaging.
<pochu> it's in universe anyway
<ScottK> That would be better.
<pochu> (menu package)
<ScottK> That can change.
<ogra> seb128, meh, just doing an upgrade intrepid->jaunty, i think the old /etc/login.defs conffile bug (where gnome-system-tools have changed tabs against spaces) is back
<ogra> -UID_MIN 1000
<ogra> -UID_MAX 60000
<ogra> +UID_MIN			 1000
<ogra> +UID_MAX			60000
<directhex> awesome
<slangasek> apw: https://wiki.ubuntu.com/Hotkeys/Troubleshooting
 * ogra wonders if its normal that all dbus using apps just crash during a dist upgrade
<ogra> NM obviouslsy tells me networking is deactivated, g-p-m tells me it has no access to any data
<ScottK> dbus restarts are not typically handled well
<ogra> well, then update-manager should prevent it from restarting until its completely done
<ogra> just having all your applets die looks quite weird
<ogra> s/die/switch to something nonfunctional/
<mvo> ogra: well, that is really something that the dbus package needs to handle
<ogra> mvo, i ndoubt it can ... it might be able to grow a hook that u-m can trigger though i guess
<ogra> like it does if you install it in a chroot ...
<ogra> so it delays the restart
<mpt> slangasek, reported bug 324304. Feel free to add details (e.g. a more common example than your PAM tool, if you know one). :-)
<ubottu> Launchpad bug 324304 in debconf "List box has missing border in GTK presentation" [Undecided,New] https://launchpad.net/bugs/324304
 * StevenK sighs how mesa failed to build on every arch aside from i386, amd64 and armel
<StevenK> bryce_: Fix mesa? :-)
<slangasek> mpt: \o/ \o/
<tjaalton> StevenK: no, the ports just need a newer kernel
<StevenK> tjaalton: Oh, argh
<StevenK> tjaalton: And mesa doesn't even die if it's not 2.6.28?
<StevenK> tjaalton: And mesa doesn't build depend on linux-headers?
<IntuitiveNipple> Any tracker package experts around?
<IntuitiveNipple> If an existing package has a bug that writes an incorrect value into the per-user sqlite database, is it permissible to add a postinst script in the fixed package to scan all homes and update each affected user database?
<LeonWP> hi
<LeonWP> I need to talk to someone who developed the cryptroot scripts from initrd
<LeonWP> how can I find out who this is? :)
<IntuitiveNipple> check the package's debian/changelog and debian/control
<LeonWP> hm how could that package be called?
<hyperair> LeonWP: how about dpkg -S /path/to/initscript
<LeonWP> thanks
<hyperair> LeonWP: cryptsetup
<LeonWP> thank you
<tjaalton> StevenK: no, probably should though since it sources drm.h
<tjaalton> and it's linux-libc-dev it should bdepend on
<StevenK> tjaalton: Oh, right. linux-libc-dev
<rainmanp7> :)
<rainmanp7> Does anyone know if the kernal can probe for a device scan it and chuck information at it and see if it responds to those certin calls ?
<rainmanp7> I'm thinking of writing a script to probe a device for somthing and I want it to tell me if that device can do that or has that capability\
<rainmanp7> and have the sciprt write it to a file
<IntuitiveNipple> rainmanp7: You'd need to create a simple device driver to probe hardware. What do you mean by "device" ?
<rainmanp7> Is there a way to just make a call to -> probe it via a script and have it write the information to a file on the desktop ?
<rainmanp7> a simple device driver :)
<rainmanp7> device = any piece of hardware -> chipset/Video Card/USB/Hard Drive Controller/mouse/keyboard
<kirkland> slangasek: http://people.ubuntu.com/~kirkland/search.html?cof=FORID%3A9&cx=003883529982892832976%3Aly2fmeg302s&q=rfkill+iwl+resume&sa=Search
<IntuitiveNipple> rainmanp7: No, you'd have to work with the individual driver and what it exposes (check the /sys/* file-system)
<rainmanp7> IntuitiveNipple thank you I'm starting to remember things from long ago :)
<IntuitiveNipple> rainmanp7: You might try the hal database
<IntuitiveNipple> rainmanp7: You might want to check out the bin/ executables in the hal package; things like  hal-find-by-property
<rainmanp7> IntuitiveNipple tyty I remember allot thank you
<ogra> pitti, hmm, the rfkill thing seems to be asac's fault, not yours :)
<pitti> ogra: dmesg should tell you, it has some stuff on disabling /enabling usually
<ogra> if i manually disable networking in NM and re-enable it again it works fine .... the actual key pressing switches the interface off and on fine
<ogra> just NM doesnt re-associate afterwards
<ogra> though i get the "unknown atkbd key" message for all my Fn based keys
<ogra> seb128, scrolling works fine if i use the right mouse button ...
<ogra> bryce, ^^^ thats why it worked for you, you accidentially used the right one
<calc> bryce: ping
<calc> bryce: http://lists.go-oo.org/pipermail/dev-go-oo.org/2009-February/001077.html
<calc> bryce: and the ooo bug i am seeing does indeed have the gdk_x11_get_server_time in the stack
<calc> bryce: can you get that patch in like today? ;-)
<calc> bryce: i'm getting lots of bug reports about it on OOo and alpha 4 goes out thursday
<slangasek> calc: LP bug number for that?
<calc> slangasek: one of them is lp 322425
<ubottu> Launchpad bug 322425 in openoffice.org "Crashes when "saving as"" [Undecided,Incomplete] https://launchpad.net/bugs/322425
<calc> slangasek: i have several others that i think are the same issue but not 100% certain
<slangasek> hum, but still marked 'incomplete'?
<calc> slangasek: yea i just found out the cause right before pinging bryce
<slangasek> ok
<calc> i've updated the bug now
<Chipzz> 15:30 < IntuitiveNipple> If an existing package has a bug that writes an incorrect value into the per-user sqlite database, is it permissible to add a postinst script in the fixed package to scan all homes and update each affected user database? >> It certainly is not
<bryce_> calc, slangasek: ok, fix looks good and applies, just checking that it builds before uploading.
<slangasek> cheers
<bryce_> libx11 takes a while to build
<IntuitiveNipple> Chipzz: So, how would the existing database be fixed?
<Chipzz> not from the postinst
<IntuitiveNipple> okay... so how?
<Chipzz> packages are not allowed to touch other packages config files, or files in user home directories
<Chipzz> no idea
<Chipzz> but
<Chipzz> let's say you have homedirs on a network drive
<Chipzz> which get automounted when the user logs in
<Chipzz> your approach breaks
<Chipzz> worse
<Chipzz> if the network drive is used by multiple machines
<Chipzz> your update may run more than once
<Chipzz> or you may have other boxes where you still have an old version where the breakage hasn't occured yet
<bryce_> calc, slangasek:  uploaded.  Please update and verify it solved the issue, when you get a chance.
<IntuitiveNipple> the db *belongs* to the buggy package
<Chipzz> which is why your approach is totally unacceptable ;)
<calc> bryce: ok
<Chipzz> you said per-user, so I'm assuming the db you mention is in the users' homedir
<IntuitiveNipple> I wasn't *my* approach; I was asking if that was permissible, since otherwise something has to be done for each user log-in
<Chipzz> well, it isn't ;)
<pochu> IntuitiveNipple: you cannot touch files in the users' home directory
<IntuitiveNipple> Chipzz: indeed, it's the trackerd ~/.local/share/tracker/db/common.db
<pochu> IntuitiveNipple: the application could though
<joaopinto> IntuitiveNipple, the usual approach for touching home dirs, is to have the launching script check the running users home dir, that is a regular behavior
<Chipzz> best approach would be to patch the application to fix it when it starts?
<IntuitiveNipple> pochu: So, how do we *fix* the user's broken db in the updated package?
<IntuitiveNipple> hmmm
<pochu> IntuitiveNipple: upstream could fix it in the code
<pochu> but you are not allowed to do so in the package maintainer scripts
<pochu> e.g. when trackerd is started it checks the database and if it's broken, it fixes it and continues
<pochu> vinagre does that for example, to migrate a file to the new conf location
<IntuitiveNipple> pochu: I posted the bug-fix upstream and it has been committed. However, their trunk code has been refactored and our tracker 0.6.6 codebase is very different in this respect. Fixing the source doesn't solve the existing-values-in-db issue
<pochu> (not with a db though, but you see the point)
<pochu> IntuitiveNipple: what I mean is that trackerd could load the db, check if it's buggy, and if it is fix that
<pochu> otherwise force the creation of a new db. It's just a cache AFAIK...
<IntuitiveNipple> pochu: yeah... this is going to be horrendous for SRUs!
<IntuitiveNipple> pochu: No, not common.db, it contains Options :s
<pochu> oh
<IntuitiveNipple> pochu: there are now two problems with the tracker Options table. The first is, it is currently writing OptionValue as OptionKey and visa-versa...
<pochu> what I mean is, whatever you're going to do in the package postinst, do it from inside trackerd
<IntuitiveNipple> pochu: and I've also discovered that Options allows multiple entries for the same option since the table wasn't created with "OptionKey PRIMARY KEY"
<IntuitiveNipple> Hmmm, can of worms anyone? :D
<IntuitiveNipple> These bugs are incidental to the main one I'm chasing, which is 100% CPU usage by trackerd
<pochu> the fix for that is to remove tracker ;)
<IntuitiveNipple> lol don't tempt me!
<IntuitiveNipple> I can fix the database with a simple script using sqlite3, *if* I can figure out a per-user way to start it :)
<pochu> make trackerd a wrapper that calls your script and then tracker.real ;)
<IntuitiveNipple> for an SRU? *eeek*
<pochu> heh
<IntuitiveNipple> I'm *hoping* I can fix all the bugs I'm finding and get them into one SRU for Hardy and Intrepid - luckily H/I/J all have the same codebase
<cody-somerville> IntuitiveNipple, I'd rather have a one to one ratio
<IntuitiveNipple> cody-somerville: one-to-one what?
<cody-somerville> Bug to SRU ratio
<IntuitiveNipple> cody-somerville: Oh... well, they are looking to be inter-related, so right now I've got three LP bugs that relate to one overall fix, but yeah, for things like the threads-not-stopping-on-SIGINT, that'd be separate
<cody-somerville> IntuitiveNipple, And you're sure all these bugs are SRU worthy? Have they been fixed in Jaunty?
<IntuitiveNipple> No, Jaunty is affected by the same ones, but obviously the patches for Juanty don't need SRU
<IntuitiveNipple> cody-somerville: The bugs, combined, cause trackerd to eat 100% CPU in some circumstances, all mainly because it writes the wrong entries to its Options table
<IntuitiveNipple> cody-somerville: So it's a case of fixing for new installs, and cleaning up the existing installed options
 * ogra hugs slangasek
<ogra> slangasek, all solved :)
<slangasek> \o/
<ogra> bryce, latest synaptics fixes my issue :D
<davmor2> any pulse audio guys here?
<superm1> pitti, can you nuke the intrepid-proposed upload of fglrx.  It didn't fix the problem as expected so it doesn't need to be sitting there
<superm1> you can unsubscribe ubuntu-sru from bug 284408 too
<ubottu> Launchpad bug 284408 in fglrx-installer "r3xx Hardware does not work with fglrx [EPR#257839]" [Undecided,Fix committed] https://launchpad.net/bugs/284408
<xnox> There is a source package in the archive which has ~100 files with copyright/license headers (GPL2 and GPL2+), it has a toplevel license/copyright as well GPL2+, and there are ~200 files without any copyright nor license. Similar situation is with the new upstream release and their svn. Is it acceptable for such thing to enter (continue to stay) in the Debian and/or Ubuntu archives?
<xnox> it's currently in Debian main, Ubuntu universe.
<hyperair> xnox: well if it entered nevermind imo
<hyperair> xnox: but it would be good to attempt to persuade upstream to handle it
<IntuitiveNipple> Would the Feature-Freeze be the applicable deadline for updating a package to the latest upstream?
<stgraber> asac: any objection to bug 305531 importance to be raised to high ?
<ubottu> Launchpad bug 305531 in xulrunner-1.9 "Context menu and drop down list are slow to appear" [Medium,Triaged] https://launchpad.net/bugs/305531
<stgraber> asac: it's really a very very annoying bug for all ltsp users as having to wait 3s to get a drop-down to appear tends to make the xul applications almost impossible to use
<xnox> hyperair: ok thanks.
<hyperair> xnox: np
<tkamppeter> pitti, ping
<tjaalton> patches.ubuntu.com hasn't been updated since Jan 18th?
<maxb> As we're not yet in FeatureFreeze, it would probably make sense to requestsync bzr, right? (Since we're two upstream releases behind at the moment)
<maxb> Do I need to separately requestsync bzrtools, or can it be a single bug?
<Turl> hello
<Turl> why does jaunty have such an old upstart version?
<ion_> turl: There will more incentive to upgrade the package when Upstart reaches the point where all initrd scripts can be migrated to Upstart jobs.
<ion_> Uh. Brainfart. s/initrd/sysvinit/
<Turl> ion_: will this happen for jaunty or jaunty+n?
<ion_> Probably not for jaunty.
<Turl> :(
<TheMuso> Considering the upstart upstream author works on ubuntu, I think he wants to make the upgrade when everything in upstart is ready.
<Turl> also, is it a know issue the fact that gdm->usable desktop takes a long time on a quite recent pc?
<ion_> Yes
<TheMuso> Yes its known, and is being worked on for Jaunty.
<Turl> ok then
<Turl> another thing, when will the intel graphic cards 3d accel work well? it works a day, breaks the next one, ...
<Turl> TheMuso: about the gdm->desktop, I'm refering to a quite big regression from intrepid, idk if you were refering to the same problem.
<Hobbsee> wfm
 * TheMuso can't answer that
<TheMuso> Turl: No I wasn;t.
<Hobbsee> oh, jaunty.  that seems to always be dodgy.
<Turl> TheMuso: well, it might be related to the intel problem, I don't have another pc to test my theory though
<TheMuso> right
<slangasek> blueyed: ping; is bug #217504 still an issue for you in jaunty, or does hal now recognize your WWW key?
<ubottu> Launchpad bug 217504 in linux "acpi_fakekey stopped working for certain keycodes" [Undecided,Confirmed] https://launchpad.net/bugs/217504
<blueyed> slangasek: no, acpi_fakekey still does not work for 148 or 150 (2.6.27-8-generic however)
<slangasek> blueyed: I don't mean "does acpi_fakekey work", I mean "does hal recognize your WWW key, making acpi_fakekey unnecessary" :)
<slangasek> acpi_fakekey is going to go away; I'm just trying to figure out whether this bug is already fixed by other means
<blueyed> slangasek: yes, it does.. :)
<slangasek> hal does recognize the key?
<blueyed> xev displays it being pressed. I don't know if it comes from hal?! is there a hal-monitor?
<slangasek> well, it either comes from there being a correct default in-kernel keymap for the key, or one being provided by the hal-info package
#ubuntu-devel 2009-02-03
<little> I'm not sure if this is the place to ask, but does anyone know why the feisty-backports/, feisty-proposed/, feisty-security/, feisty-updates/ folders are still on the package servers?
<little> Does anyone know why the feisty-backports/, feisty-proposed/, feisty-security/, feisty-updates/ folders are still on the package servers?
<little> ........ or who I should ask?
<ham5> wow
<directhex> little, old-releases?
<little> Yeah. All the folders I mentioned exist, but the main feisty/ folder doesn't. Why didn't they get rid of them all?
<directhex> all seems fine on old-releases to me
<little> Ah, I'm not sure we're talking about the same place.
<little> http://us.archive.ubuntu.com/ubuntu/dists/
<little> Is there a way to hook into old-releases from sources.list?
<directhex> yes. use old-releases.ubuntu.com as your site
<little> w00t! Thank you very much! I had someone from India write to me and not be able to update Feisty's sources.list and he's waiting to receive Hardy Heron LTS, and I thought I couldn't help him get Feisty going a bit more until he gets it. Now it looks like he can!
 * little hugs directhex
<slangasek> blueyed_: btw, would you be willing to do some tests to see whether your hotkeys on your Asus work if you turn off acpid, and let me know which ones work and which ones stop working?
<gimpuzmani> hi
<gimpuzmani> hello
<gimpuzmani> Hello
<etech> hi
<etech> do you know if openoffice 3.0.1 will be in backports for intrepid?
<pitti> Good morning
<pochu> hi pitti :)
<pitti> superm1: nuked
<gimpuzmani> I'm the editorial writer and designer of the official Ubuntu-TR Community E-Magazine SUDO
<gimpuzmani> I'm the editorial writer and designer of the official Ubuntu-TR Community E-Magazine SUDO
<calc> slangasek: ping
<Hobbsee> gimpuzmani: uh, hi.  and hi in 6 mins time too ;)
<calc> slangasek: i can test 8.04 if you don't need phsyical hardware tests in vmware 6.5.1
<Hobbsee> morning pitti
<kees> tjaalton: stuff out of apparmor-profiles isn't well tested (which is why it's in universe).  we'd love any extra eyes on it.
 * Hobbsee throws a few gummybears in pitti's direction
 * pitti hugs Hobbsee, good morning!
<Hobbsee> :D
 * pitti throws a Bratwurst back at Hobbsee
<tjaalton> kees: referring to the sshd-profile?
<Hobbsee> sausage?  way cool.
<gimpuzmani> Hobbsee, I'd like to interview with Ubuntu Developer(s)
<tjaalton> kees: selinux is completely hosed, that's why I'm looking at apparmor instead :)
<tjaalton> (in order to secure the shell server)
<gimpuzmani> Hobbsee, hello I'd like to interview Ubuntu developer with e-mail
<Hobbsee> gimpuzmani: right.  Well, you can try ubuntu-devel-discuss@lists.ubuntu.com for such things, as that's the recommended way to get in touch with ubuntu developers, as a user.
<gimpuzmani> Hobbsee, Thanks.
<Hobbsee> gimpuzmani: you're welcome
<gimpuzmani> Thank you for informing me.
<StevenK> tjaalton: Oh, for crying out loud!
<tjaalton> StevenK: yes?
<StevenK> tjaalton: You know that linux-libc-dev will only be 2.6.28-5.15 on amd64 and i386 even if other arches provide 2.6.28?
<tjaalton> StevenK: I do
<StevenK> tjaalton: So, can we fix that?
<tjaalton> StevenK: lpia kernel is still hosed
<StevenK> When did you check?
<tjaalton> it needs the same compat changes that 2.6.28-5.15 has
<tjaalton> I don't know why it doesn't
<StevenK> tjaalton: Right, so who did the 5.15 changes?
<tjaalton> StevenK: apw/rtg I guess
<StevenK> tjaalton: I'll hit them up
<tjaalton> StevenK: please do :)
* slangasek changed the topic of #ubuntu-devel to: Archive: frozen for alpha-4, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | this week: https://wiki.ubuntu.com/UbuntuDeveloperWeek
* pochu changed the topic of #ubuntu-devel to: Archive: frozen for alpha-4, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pochu> (UDW already ended)
<mathiaz> slangasek: should bug 323755 be considered a blocker for alpha4?
<ubottu> Launchpad bug 323755 in mysql-dfsg-5.0 "non-trivial building mysql source package, build test keeps failing, (open)ssl related" [Undecided,Confirmed] https://launchpad.net/bugs/323755
<asac> doko_: your compiler is crashy in jaunty ;)
<StevenK> tjaalton: So, can I upload mesa after the lpia kernel gets sorted out?
<tjaalton> StevenK: what do you need to change?
<StevenK> tjaalton: A Build-Depend change against the new linux-libc-dev so it builds on lpia?
<tjaalton> StevenK: mesa doesn't build-depend on it (although it should)
<tjaalton> libdrm-dev pulls it in
<StevenK> Oh, right, so libdrm needs fixing
<StevenK> tjaalton: Okay, so same question, but s/mesa/libdrm/
<tjaalton> StevenK: I could fix them in git and upload
<StevenK> tjaalton: Just waiting for the kernel to be uploaded
<tjaalton> StevenK: do you have the version?
<StevenK> tjaalton: I think it will be 2.6.28-2.4
<StevenK> tjaalton: But I'll confirm when the kernel is uploaded
<StevenK> slangasek: Further to my kernel request, libdrm needs fixing
<tjaalton> StevenK: sure, thanks
<slangasek> StevenK: er?
<tjaalton> StevenK: actually, it's enough to fix just mesa
<tjaalton> or trigger a rebuild when the new kernel is in?
<StevenK> slangasek: mesa or libdrm needs to be fixed so it actually builds, and then everything else should just be a bunch of give-backs
<StevenK> tjaalton: The give-back on mesa I triggered failed because it wanted linux-libc-dev 2.6.28-5.15, which isn't going to exist on lpia
<tjaalton> StevenK: oh right, that's lool's fault :)
<StevenK> tjaalton: Oh, so I need to kick lool? :-)
<tjaalton> StevenK: nah, I've done it already
<tjaalton> um, the change that is
<tjaalton> :P
<StevenK> Oh, right. I'll do the kicking :-P
 * ogra wonders why his compiz feels so slow on jaunty
<tjaalton> ogra: intel, after a vt-change or suspend/resume?
<ogra> intel general usag
<ogra> e
<ogra> like alt-tab takes about a second to bring up the centered popup
<calc> jcastro: just my luck 15% coupon expired yesterday :\
<ogra> and about two seconds to close it after the window/focus change
<tjaalton> ogra: when you have many windows open, and snappy when only a  few?
<ogra> i have 5 open atm ... 2 terms, 1 firefox, evo and xchat
<tjaalton> try it on another workspace with only two terminals
<tjaalton> the ws with all the browser windows is quite slow here
<ogra> ugh, workspace changing is even slower
<tjaalton> and I guess this is due to dropping the dreaded patch from the xserver
<tjaalton> but keeping it breaks KDE4
<tjaalton> so..
<ogra> hrm
<ogra> how about shipping kde3 in jaunty ?
<ogra> :)
<directhex> kde3 sucks. kde2!
<tjaalton> you could try it yourself.. enable patch 107 from xorg-server and rebuild
<ogra> so switching workspaces with ctrl-alt-right lets the animation stop in the middle for a second and leaves the centered popup on the screen for about 3secs afterwards
<tjaalton> bryce_: ^^, dropping the patch does indeed have issues with GNOME
<tjaalton> ogra: that's bug 320813
<ubottu> Launchpad bug 320813 in xserver-xorg-video-intel "[drm] compiz animations cause temporary freezes with vblank" [Unknown,Confirmed] https://launchpad.net/bugs/320813
<bryce_> tjaalton: bummer
<tjaalton> bryce_: meaning that I can see it with some bigger windows open
<directhex> easiest fix: switch jaunty to e17
<ogra> should the drirc woraround work ?
<ogra> *workaround
<tjaalton> should
<ogra> ok
 * ogra reboots
<bryce_> tjaalton: have you gotten in contact with someone on the kernel team about getting the patch taken in?
<tjaalton> bryce_: yes, sent it on the list
<tjaalton> yesterday
<ogra> tjaalton, yep, helped (still not as snappy as it was n intrepid, but a lot better)
<bryce_> tjaalton: ok let me know if I should try and grab a kernel dev to look at it
<tjaalton> bryce_: well it'd be nice to have for the alpha
<tjaalton> either that or disable vblank again
<bryce_> ogasawara: 320813 has a kernel patch we really need to get in to resolve a bad compiz performance issue.  Could you help us get a kernel dev to give it some attention?
<lool> tjaalton: Ah crap
<tjaalton> lool: no worries :)
<lool> tjaalton: I only checked that we had a 2.6.28 lpia linux-libc-dev
<lool> With drm headers
<lool> I didn't check the version
<lool> So it might be that the lpia version is enough
<lool> tjaalton: How can I check the lpia versionis enough?
<tjaalton> lool: the next one should have some compat stuff added which are needed, so it wouldn't have worked anyway :)
<tjaalton> kees, cjwatson: so, I got the apparmor usr.sbin.sshd rule to work, but it needed a number of changes, most worrying of which was probably 'dac_override' capability (at least the comment on usr.sbin.cupsd looks scary)
<seb128> slangasek: can I upload a gnome-utils update?
<slangasek> seb128: yes
<slangasek> thanks for checking :)
<seb128> you're welcome, thanks for approving the update ;-)
<lool> tjaalton: Poke
<lool> tjaalton: So I'm in Berlin and the whole kernel team, some RMs and Luke are all around; I discussed the whole situation of linux-libc-dev with various people
<lool> tjaalton: Luke should have some time to at least get linux-libc-dev updated on ports
<directhex> mornin' dholbach
<lool> tjaalton: I discussed ways to keep the version number of linux-libc-dev in sync so that it's meaning ful (avoiding the trap I had with libdrm-dev)
<lool> tjaalton: But that wont happen anytime soon as it's a hard problem to solve
<lool> tjaalton: And I got clearance to push a fixed libdrm from slangasek which I'll do now
<ogra> can a buildd admin bump lp-sove priority up on armel so it builds asap ?
<ogra> *lp-solve
<lool> tjaalton: You used 2.6.28-5.15 on i386/amd64/armel; commit 860b3c7cb73a734d3076e9b30ef51682a6c53449
<lool> tjaalton: was one of the last commits in this upload
<lool> tjaalton: This commit is present in the last lpia upload at least
<lool> tjaalton: did the drm headers also require other packaging changes?
<Hobbsee> ogra: prodded
 * ogra hugs Hobbsee 
<Hobbsee> :)
<lool> tjaalton: I'm trying to testbuild libdrm and mesa
<tjaalton> lool: sorry, was having lunch.. feel free to commit/upload. no other changes needed to libdrm
<lool> tjaalton: Great, thanks
<lool> tjaalton: pushed
<lool> tjaalton: I'm doing a test build in my ppa and will push after lunch if it's ok
<tjaalton> lool: actually, -1.1 isn't enough :)
<tjaalton> at least to build mesa
<tjaalton> I heard there's -2.4 coming up soon
<lool> tjaalton: Ok; what should I be looking for?
<lool> tjaalton: Yes, a lpia upload is being prepared
<lool> tjaalton: Cause it has drm headers
<lool> currently
<lool> -rw-r--r-- root/root     11611 2009-01-27 23:07 ./usr/include/drm/i830_drm.h
<tjaalton> mesa build will fail if the headers don't have the necessary compatibility commits
<lool> -rw-r--r-- root/root     18808 2009-01-27 23:07 ./usr/include/drm/i915_drm.h
<lool> etc.
<lool> tjaalton: I checked that all commits which were in the i386 version you used were also in lpia 1.1?!
<lool> tjaalton: Do you have the SHA?
<lool> Or commit message
<tjaalton> lool: no, but the mesa build fails
<lool> Author: Dave Airlie <airlied@redhat.com>
<lool>     UBUNTU: SAUCE: (drop after 2.6.28) i915/drm: provide compat defines for user
<lool>     members.
<lool> fb8d31f87398f59e24ff5bda5dc89111fe59e4dd
<tjaalton> that's in 1.1?
<tjaalton> oh
<lool> It's in git, checking whether it's in 1.1
<tjaalton> sorry, the build failed exactly because of the depends mess, duh :)
<tjaalton> at least the most recent build did
<lool> tjaalton: it is in -1.1
<lool> I can see the fill out some space for old userspace triple buffer commit
<lool> (I checked out the LPIA-Ubuntu-2.6.28-1.1 tag)
<tjaalton> lool: ok, so it's ok now
<tjaalton> okok
<lool> tjaalton: Pushing drm to Ubuntu then
<tjaalton> yess
<lool> pushed
<ogra> can a buildd admin bump openoffice on armel so it starts building soon ?
 * ogra isnt sure why it wants to wait 1h while all armel buildds are idling
<lool> tjaalton: Didn't build on lpia: http://launchpadlibrarian.net/21929071/buildlog_ubuntu-jaunty-lpia.mesa_7.3-1ubuntu1dooz1_FAILEDTOBUILD.txt.gz
<lool> tjaalton: I'm afraid there's another required commit
<Mithrandir> ogra: done.
<Mithrandir> ogra: it still says "Estimated build start 1h" though
<ogra> Mithrandir, gracias :)
<ogra> weird scoring system ...
<lool> tjaalton: So I don't know what's missing
<tjaalton> lool: let me check
<tjaalton> lool: maybe the new libdrm hasn't gone through yet?
<lool> tjaalton: It's in my ppa
<lool> tjaalton: The build log indicates it used my ppa upload
<lool> (ubuntu5~dooz1)
<lool> tjaalton: We do see the linux-libc-dev: Preparing to replace linux-libc-dev 2.6.27-4.9 (using .../linux-libc-dev_2.6.28-1.3_lpia.deb) ...
<lool> tjaalton: It must be another commit
<tjaalton> lool: ok, I couldn't open that log, I thought you just rebuild the official one :)
<tjaalton> (irssi cut the line)
<lool> #define planeA_x pipeA_x
<lool> That's what we want
 * lool git blames
<tjaalton> so the kernel doesn't have all that's needed
<lool> f4aad346 include/drm/i915_drm.h      (Tim Gardner        2009-01-22 13:32:29 -07
<lool> tjaalton: Ok, some commits were reverted in the git tree
<lool> f4aad3465b0d6fa4465ee60f0b5abb584ea4b9b8
<lool>     Revert "UBUNTU: Enabled CONFIG_PID_NS=y for i386/amd64"
<tjaalton> yes, and the revert was reverted :)
<lool> "This commit somehow wound up reverting the prior 7 commits,"
<lool> tjaalton: That's the commit reverting the revert
<lool> tjaalton: I didn't check for the revert and unreverted commits in the lpia tree
<lool> tjaalton: It's weird, I see f4aad3465b0d6fa4465ee60f0b5abb584ea4b9b8 i nthe LPIA-Ubuntu-2.6.28-1.1 tag
<lool> Grr if I look at LPIA-Ubuntu-2.6.28-1.1, it has the proper #define
<lool> I suspect the tag is wrong
<tjaalton> :/
<lool> The headers are broken in the .deb in the archive, but not in the git tree for this tag
<lool> git reset --hard LPIA-Ubuntu-2.6.28-1.2 => vi include/drm/i915_drm.h => define is there, dpkg-deb -x ../linux-libc-dev_2.6.28-1.2_lpia.deb => define isn't there, yeah!
<lool> tjaalton: So let's just wait til the kernel gets uploaded...
<lool> It needs an upload anyway, the header is broken
<lool> tjaalton: Unless I push a change to do this in mesa?
<tjaalton> lool: so that it'd end up in depwait? works
<lool> amitk: The LPIA tags seem to be broken ^^^ they don't match what's in the archive
<lool> tjaalton: No, I'm saying adding the #defines to mesa file sincluding i915_drm.h
<tjaalton> lool: oh, sounds ugly :)
<amitk> lool: I am not doing LPIA currently. apw/sconklin are
<apw> lool?
<lool> apw: You're planing a linux-lpia upload today?
<lool> apw: I just realized the LPIA tags on the linux-lpia.git tree are not matching what's in the archive
<apw> we have the kernel uploaded, lrm is in progress
<apw> in what sense are they not matching?
<lool> apw: git reset --hard LPIA-Ubuntu-2.6.28-1.2 => vi include/drm/i915_drm.h => define is there, dpkg-deb -x ../linux-libc-dev_2.6.28-1.2_lpia.deb => define isn't there
<lool> e.g. this define: #define planeA_x pipeA_x
<lool> (and others)
<apw> lool, if there is a .orig tag for the tag, you need that one
<apw> to get the tree to the same point it was when debuild -S was run
<lool> apw: Im' taking the .deb from the archive
<lool> apw: Comparing that to the kernel's git tree
<apw> yep
<lool> apw: It should match, right?
<apw> don't use the LPIA-Ubuntu-2.6.28-1.2 tag, use the LPIA-Ubuntu-2.6.28-1.2.orig tag to get the tree to match the .deb
<lool> I should see the same i915_drm.h for the uploaded headers and the tag in the git tree
<lool> apw: There is no such tag...
<apw> there should be
<lool> apw: There's only a LPIA-Ubuntu-2.6.28-1.1.orig
<apw> you need to git fetch --tags orig
<apw> you need to git fetch --tags origin
<lool> apw: Indeed; thanks
<lool> apw: What are the (confusing) non orig tags for?
<lool> Indeed, the .orig tree doesn't have the #defines
<apw> they are meant to mark the transitions in the ubuntu delta
<apw> and yes they are a little confusing
<apw> the moving tags thing is under review for J+1
<lool> apw: Arh
<lool> argh
<lool> apw: LPIA-Ubuntu-2.6.28-1.3.orig doesn't have the fixed deines
<lool> apw: /i915_drm.h is still broken in the latest linux-libc-dev lpia upload
<lool> tjaalton: ^
<tjaalton> lool: yes, what about -2.4 which is tagged already?
<apw> t
<lool> tjaalton: I checked with apw, they will upload another linux-lpia today which will be fixed
<lool> tjaalton: I'll push a new libdrm-dev when it's there and I verify the fix is uploaded
<tjaalton> lool: cool
<EagleScreen>  suspend to RAM is broken for me in 2.6.27-11, but works well in 2.6.27-9
<apw> EagleScreen, what symptoms do you see
<EagleScreen> computer cannot wake up after suspend, har disk gives a sound and monitor keep black
<apw> does the network come up?  can you login remotly?
<mpt> pitti, https://wiki.ubuntu.com/Specs/JauntyUNR
<maxamillion> cody-somerville: ping
<cody-somerville> maxamillion, pong
<maxamillion> cody-somerville: was wondering if you could take a peak at a bug a co-worker and i have been fighting with ---> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/322879
<ubottu> Launchpad bug 322879 in linux "Verizon CDMA card no longer works" [High,Triaged]
<TheMuso> Do we have usable nvidia drivers in jaunty, i.e via jockey etc?
<EagleScreen> apw I dont think so.. it seems to hangs the system completly
<tjaalton> TheMuso: jockey hasn't been updated to handle them AFAIK
<TheMuso> tjaalton: oh ok
<Foor> hi to all
<cody-somerville> Hobbsee, I seemed to have gotten some spam that was intended for you.
<pitti> slangasek: did you just forgot to bzr push your debcommit -r for acpi-support, or shall I just retroactively do it?
<pitti> slangasek: (I want to commit/upload an acpu]
<pitti> acpi-support fix)
<slangasek> pitti: pushing
<slangasek> "an acpu"?
<pitti> slangasek: tpying eorrer
<slangasek> pitti: plausible - I just don't know what it was an error for :-)
<pitti> s/u]\n//
<slangasek> oh, I should read all the lines on my screen, not just the even-numbered ones
<apw> pitti, should we not be installing ubuntu-bug by default??
<pitti> apw: we do
<etech> hi, will openoffice 3 be in intrepid backports?
<apw> piiti but i don't think its installed here
<apw> in the daily iso from yesterday
<mok0> RainCT: pinggg
<Foor> hi all
<jlc> not sure were else to ask, but I've been looking for images and found jaunty-mid-lpia.img
<jlc> I have an eee pc and was wondering if this hast the rt2860 built into the kernel
<jlc> I don't see rt2860 as a package in the manifest so thought I would ask if anyone knew
<superm1> jlc, i'd join #ubuntu-motu and talk to henrik-hw0.  he's got some packages that he is trying to get into Jaunty you can probably test with
<jlc> superm1: thanks
<RainCT> mok0: pong
<Foor> anyone know how the new notification system is coming along?
<ScottK> It's been mentiond that they are working on it at the sprint this week.
<blueyed_> slangasek: I can do some testing, but I don't have any Asus.
<IntuitiveNipple> I've found an ubiquity problem, kinda serious, but no clues as to how it is caused. After doing a manual partition configuration with separate partitions/encrypted LVMs for /, /var/ /boot/ and /home/, when ubiquity starts the install process it fails trying to prepare /dev/sda5 (/boot/) because sda5 has *disappeared* during the disk scanning.
<IntuitiveNipple> To be clear, the disappearance is according to the kernel (gone from /proc/partitions) but a restart finds the partition is okay and the file-system inside checks correctly
<IntuitiveNipple> Anyone have suggestions as to where to dig?
<kennethr1>  I am running 8.10 via wubi on Windows Vista...and I think I'm getting panics...how can I get a backtrace/coredump to troubleshoot?
<directhex> check dmesg, if the machine is still responsive
<directhex> if it's crashed HARD, your keyboard lights ought to be flashingf
<kennethr1> I don't think so...CAPS LOCK is flashing
<kennethr1> what then?
<kennethr1> directhex: that's what I mean...kernel panic
<directhex> there are lots of types of kernel panic... this one sounds fatal though
<directhex> does the machine have a wireless card?
<kennethr1> right....how do I harvest more info about the panic?  It's happening fairly regularly...and yes I think it may be related to wireless.  It has bcm4311
<kennethr1> directhex: ping
<kennethr1> suggestions?
<directhex> ehm... i'm not great on this
<kennethr1> directhex: np...I can ask around
<directhex> ideally you want to ensure you get a core dump. i don't remember how to enable it
<hyperair> does anybody know what power manager xubuntu uses?
<hyperair> nevermind, it seems it uses gnome-power-manager
<EagleScreen> hello i have a small problem, when i run dch -i or -e to edit the changelog, my email address appears wrong in the changelog. DEBMAIL variable has the right value
<slangasek> blueyed_: oh.  what's the vendor for your laptop?
<primes2h> pitti: I prepared the patch for gnome-icon-theme...
<pregier> I'm sure this is a FAQ somewhere, but haven't been able to find it yet:  Are there any plans for PulseAudio >= 0.9.12 and/or speex-1.2 (apparently required to build PA >=0.9.11) on Hardy?
<pregier> This is inspired by https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/262326
<ubottu> Launchpad bug 262326 in pulseaudio "pcm_pulse.c:275: pulse_write: Assertion `pcm->last_size >= (size * pcm->frame_size)' failed. (Intrepid & pulseaudio_0.9.11-0ubuntu1~ppa3 - TheMuso PPA) " [Undecided,Fix released]
<dtchen> that bug is already resolved in jaunty
<dtchen> and AFAIK, no, no plans.
<dtchen> that would require invasive changes across the board: linux, alsa-lib, and alsa-plugins. then one would need to regression test every reverse dependency of libasound2.
<pregier> Thanks; I might have to watch the release cycle more closely then.
<directhex> gnome needs a way to remap mouse buttons.
<directhex> hmm, isn't that something linus was moaning about lately?
<lool> tjaalton: Checked the linux-libc-dev headers on lpia, these are fine now; pushed a new libdrm to git and uploaded to ubuntu
<maxb> Today's mysqld updates somehow left me with the old mysqld_safe process not dying on shutdown, and instead sticking around sucking 100% CPU. Is there any info I can usefully gather before I kill it?
<ScottK-desktop> lool: I already retried mesa and it built with the previous libdrm.  Does that mean it's misbuilt?
#ubuntu-devel 2009-02-04
<EagleScreen> if I run dch -i, changelog is incremented for intrepid, and later package is built for intrepid, what must I do if I want to increment changelog for jaunty or unstable and to build the package for jaunty or unstable? I have chroots for each release created with pbuilder
<jdong> EagleScreen: see -r for dch
<EagleScreen> yes I see
<EagleScreen> i think that with my actual configuration, debuild builds the package for the release typed in the changelog included if you typed it by hand
<jdong> what configuration does that?
<jdong> apart from a buildd-style setup
<jdong> and all -r does is fill in that part of the changelog header with the release you want
<jdong> it is fundamentally no different than typing it in by hand, other than saving a bit of arrow-key usage
<EagleScreen> this configuration http://pastebin.ca/1326753
<EagleScreen> it has a block to take the release from the changelog
<jdong> nice, around line 30
<jdong> then dch -r will do the trick
<jdong> you can also set the DIST environment variable to override it
<EagleScreen> i cannot understand the utility of -r argument
<jdong> it's primarily useful for doing a changelog bump from a noninteractive script
<EagleScreen> i think i am starting to understand this.. lol
<jdong> lazy typers tend to benefit too ;-)
<EagleScreen> but I note a difference between debian debuild and ubuntu debuild
<EagleScreen> for instance, in debian, dch -i changes version from 0.3.2 to 0.3.2-1 and ubuntu to 0.3.2ubuntu1
<jdong> right, because -1 is not a valid version number for an upload into Ubuntu
<EagleScreen> if I build Debian native packages will it add ubuntu1 to the version string?
<jdong> and Ubuntu's devscripts are designed for Ubuntu developers
<EagleScreen> and Debian adds automatically +nmu (non mantainer update)
<LordMetroid> Where does APT store information of downloaded package?
<RAOF>  /var/lib/dpkg and /var/lib/apt
<ion_> Also, /var/cache/apt/archives contains the downloaded packages themselves. Now please read the topic. :-)
<RAOF> Is anyone looking at the gnome-desktop2, gnome-desktop-sharp2, tomboy & monodevelop situation?
<EagleScreen> what happens when debuild gives me an error of build dependences, but the necessary dependence is in the repository why it does not satisfy the build-dependence?
<andersk> debuild only looks at packages on the system; it does not install new packages for you.
<andersk> You can install the build dependencies for a source package in the repository with `apt-get build-dep sourcepackage`,
<andersk> or for an extracted package on disk with `/usr/lib/pbuilder/pbuilder-satisfydepends` (in the pbuilder package).
<RAOF> gnome-desktop-sharp2 at least has a debdiff attached, and this is a prerequisite of fixing Tomboy.
<EagleScreen> but i want to install build-deps in the pbuilder fakeroot and not in my real installation, is it possible?
<RAOF> EagleScreen: Because you don't have the dependency installed.
<RAOF> EagleScreen: debuild doesn't automatically install dependencies for you.
<EagleScreen> then how can I install a package in the pbuilder fakeroot enviroment?
<andersk> pbuilder will automatically install dependencies for you.  debuild will not.
<andersk> Are you actually using pbuilder to run a build, or are you manually entering the chroot and running debuild?
<EagleScreen> i used pbuilder to make the root eviroments
<EagleScreen> the i must use pbuilder instead of debuild
<EagleScreen> can pdebuild sustitute to debuild -b?
<andersk> That should work.
<EagleScreen> is it possible that launchpad ppa to fail building for use debuild -S to build without all build-dep installed in my system?
<EagleScreen> I mean, must I use pbuilder to build source packages instead of debuild -S?
<EagleScreen> can pbuilder buils source packages?
<EagleScreen> why pbuilder didnt ask me for my PGP passphrase?
<EagleScreen> pdebuilder provides a .deb package?
<RAOF_> EagleScreen: pbuilder builds source packages, too, but if you just want to build a source package you (generally) don't need the build-depends installed.
<EagleScreen> i want to build the .deb package
<RAOF_> Well, then you either want pbuilder or to install the build-depends.
<EagleScreen> pbuilder to install the dependences in the fake root enviroment
<EagleScreen> but pbuilder is only buildding the source package
<EagleScreen> pbuilder build *.dsc
<RAOF_> No, it's building the binary package.  You might not know where the binary package that it's building _is_ (it's in /var/lib/pbuilder/result, IIRC), but it's building the binary package :)
<EagleScreen> yes, they are there :D
<EagleScreen> lintian:
<EagleScreen> W: mount-systray source: out-of-date-standards-version 3.7.2 (current is 3.8.0)
<EagleScreen> W: mount-systray source: native-package-with-dash-version
<EagleScreen> what does it mean?
<ion_> Pass -i to lintian
<slangasek> tkamppeter_: please mind the alpha freeze
<Hobbsee> cody-somerville: oh, really?  Why?
<IntuitiveNipple> Would we consider ubiquity causing the kernel to *lose* a partition table entry as critical?
<slangasek> IntuitiveNipple: causing the *kernel* to lose it?  Probably not.
<slangasek> since the kernel is never supposed to overwrite the partition table, it presumably would reappear on reboot
<IntuitiveNipple> I meant as in, the partition is lost from /proc/partitions and therefore ubiquity causes itself to fail if that partition is an installation target
<IntuitiveNipple> I've been able to reproduce it with alpha 3 LiveCD and the Intrepid LiveCD installer - something to do with d-i/partman but the logs aren't time-stamping so I can't figure out exactly what is being done to cause it
<slangasek> hmm
<IntuitiveNipple> Indeed!
<slangasek> if it's reproducible for you in intrepid, that's certainly a corner-case
<slangasek> please file a bug on ubiquity with as much detail as possible, but I'm not, e.g., going to stop the presses on alpha-4 for such an issue
<IntuitiveNipple> I'm working through the source right now, but it's not enlightening me
<IntuitiveNipple> It could be described with two headings, as you'll see: bug #324987
<ubottu> Launchpad bug 324987 in ubiquity "Separate /boot/ partition fails" [Undecided,New] https://launchpad.net/bugs/324987
<slangasek> bryce, tjaalton: I notice we have some bugs about touchpad toggling not working through acpi-support - looks like synclient doesn't work, SHMConfig disabled, yadda yadda - do you know what the right way is to fix this?
<Amaranth> ooh, can I get my touchpad back please? :)
<slangasek> Amaranth: "toggle" - different issue
<slangasek> Amaranth: what hardware do you have, what version of xserver-xorg-input-synaptics do you have installed?
<slangasek> Amaranth: also, when did it stop working?
<Amaranth> wow i totally don't have that package installed
<slangasek> heh
<slangasek> then that explains your touchpad not working ;)
<Amaranth> it stopped working when half way through my jaunty install (daily from the 1st) ubiquity crashed :/
<slangasek> ah
<Amaranth> forgot to collect the logs for that one, I panic'ed and just made my system work
<slangasek> good, thank you for /not/ confirming the kernel bug that the kernel team have been panicking about since last night :-)
<tjaalton> slangasek: I'm not familiar with that one, what should it do exactly?
 * tjaalton has no touchpad
<slangasek> tjaalton: ah.  various laptops have a hotkey that's supposed to toggle the touchpad - an easy way to disable it if it's getting in your way while typing
<tjaalton> slangasek: oh, ok. xinput can disable it but you'd have to know the device id
<slangasek> tjaalton: but it uses synclient, which does this:
<slangasek> $ synclient TouchpadOff=1
<slangasek> Can't access shared memory area. SHMConfig disabled?
<slangasek> tjaalton: oh interesting!  How does the disabling work?
<slangasek> because that would be way better
<tjaalton> 'xinput list' shows the input devices, 'list-props N' lists the properties that the device has
<tjaalton> N can be the numerical id or the full name
<slangasek> tjaalton: sure; I actually assume we'll be walking the hal tree for this, since it's in fact hal that should be handling the keypress itself in the new world order, and hal already has the info about that :)
<slangasek> but what's the command to actually disable the input device?
<tjaalton> slangasek: 'xinput set-int-prop N 'Device Enabled' 8 0
<tjaalton> or something like that
<slangasek> awesome
 * slangasek hugs tjaalton :)
<tjaalton> heh
<tjaalton> been there since intrepid ;)
<tjaalton> synaptics 1.0 supports float properties too
<slangasek> sorry, I'm just excited that we don't need to use synclient anymore, which has never been reliable :)
<tjaalton> so SHMConfig is pretty much obsolete
<slangasek> yeah
<tjaalton> now all that's needed is a pretty GUI for all of this, not just touchpads but mice too
 * slangasek nods
<tjaalton> and preferably integrated to the DE capplet
<tjaalton> because the settings aren't persistent, but with gconf/g-s-d that should be covered (and the same for KDE counterparts)
<slangasek> sure
<slangasek> in that case, maybe it would be g-s-d itself that should handle the event, with hal just emitting it on the bus
<tjaalton> it's also annoying that you can't assign just a mouse button as a shortcut.. my mouse has a number of buttons that are useless right now
<pitti> bdmurray: calibre 0.4.133 uploaded
<slangasek> superm1: mythbuntu-desktop is currently uninstallable, prevents alpha-4 builds
<directhex> alpha 4? it's that time already?
<slangasek> yes
<IntuitiveNipple> How can I execute the Crash-Report tool manually? It just failed to upload a crash report that occurred when running the hwtest, so I wanted to try resending the report
<pitti> IntuitiveNipple: go to /var/crash in nautilus and click on it
<IntuitiveNipple> thanks
<pitti> IntuitiveNipple: or, if you are CLI oriented, /usr/share/apport/apport-gtk -c /path/to/crash/file
<IntuitiveNipple> that's more like it ... thanks!
<IntuitiveNipple> Hmmmm... and again "urlopen error The write operation timed out"
<slangasek> superm1: because libmyth-0.21-0 depends on a non-existent libx264-59 package?
<slangasek> superm1: ... which seems to have been NBSed out, so libmyth-0.21-0 needs a rebuild
<slangasek> </monologue> :)
<pitti> calc: http://qa.ubuntu.com/reports/ogasawara/pet-buglist.html
<calc> thanks
<slangasek> bryce_, tjaalton: eh, xserver-xorg no longer depends on xserver-xorg-input-all, which means we don't get -synaptics installed?
<slangasek> bryce_, tjaalton: can I presume to upload a fixed xserver-xorg that depends on both -evdev and -synaptics, or is there something else we should be doing here?
<tjaalton> slangasek: it does
<slangasek> hmm?
<slangasek> tjaalton: the only input package on the liveCD today in -evdev
<tjaalton> well, that satisfies 'x-x-i-all | x-x-i-4'..
<tjaalton> which is why -all isn't pulled
<tjaalton> +probaly
<tjaalton> +b
<tjaalton> (damn
<tjaalton> it's been like that on intrepid too
<slangasek> tjaalton: the intrepid version depends on -all.  the jaunty version *doesn't* - IIRC because of a wacom problem earlier in the cycle
<slangasek> I think it was you that I had this conversation with? :)
<slangasek> oh, no, that was dropping vmmouse from -input-all, that's different
<tjaalton> yes
<slangasek> oh, haha
<slangasek> I see
<slangasek> Depends: xserver-xorg-input-evdev, xserver-xorg-input-all | xserver-xorg-input-4
<slangasek> right - can we try reversing the order of those dependencies in debian/control?
<tjaalton> sure
<slangasek> shall I do it, or would you like to?
<tjaalton> I can do it
<slangasek> ok, thanks
<tjaalton> slangasek: uploaded
<slangasek> tjaalton: cheers
<slangasek> superm1: ok, mythtv uploaded for a no-change rebuild; I believe I don't have commit access to the bzr repo though
<slangasek> superm1: ah, except that source changes are needed for the new x264 after all :-(  so I'll wait for you for further guidance
<lool> ScottK-desktop: No, mesa isn't misbuilt; it's just that libdrm-dev should guarantee you get the drm headers
<ScottK> lool: OK.  Just checking as I didn't have the background.  I spent most of last night coaxing KDE to build on lpia and I'd hate for it to have been for nought.
<ScottK> lool: Thanks.
<lool> ScottK: How is KDE looking on lpia/armel these days?  (I mean in terms of builds; I don't expect you to run that :)
<lool> slomo_: Poke
<ScottK> Up until the kernel upload yesterday we were literally dead on lpia because nothing would build.
<lool> slomo_: I'd like to drop the always satisfied version in the sda -> notification-daemon dependency as it prevents an alternate implementation to Provide notification-daemon with sda installed
<ScottK> Now lpia in Main is fully built.
<lool> ScottK: I guess it's the same on all linux-ports arches then?
<lool> (ppc, sparc, hppa, ia64...)
<ScottK> Except armel, yes.
<ScottK> armel had some other transient problem that seems to have passed and I'm retrying stuff now.
<lool> Yeah, armel is built by linux so it's up-to-date
<lool> ScottK: Great
<ScottK> kde4libs on armel built, so likely the rest of the stack will be ok.
<ScottK> Because of boost -> boost1.35 I need to do a main upload before I can finish universe stuff so that'll have to wait until after the alpha.
<ScottK> So rapidly moving from really bad to pretty good is how I'd sum it up.
<ogra> YokoZar, are you around by chance ?
<lool> Hmm right boost broke lots of stuff
<lool> Oh I'm uploaded or sda
<lool> slomo_: I don't remember whether we have a Vcs for sda
<lool> *uploader
<dholbach> seb128: pedro_ wants to know hof often you already heard "iz gtk boog"
<directhex> if someone were to show some love to 323790, then i could prepare one final app package & sign off on the mono 2.0 app transition as done (leaving only libs and tweaks, which are where space savings will suddenly happen)
<slangasek> jelmer: why is bzr 1.11 in experimental instead of in unstable? :)
<TheMuso> tjaalton: Turns out that the multifinger patch that tseliot got included in a recent synaptics upload breaks the expected behavior for my touchpad. I now have to use thre fingers instead of two fingers for right-click.
<TheMuso> three even'
<tseliot> TheMuso: in which version of the driver?
<tseliot> version and revision
<TheMuso> tseliot: i'll get back to you on that, about to head off for lunch.
<tseliot> TheMuso: ok
<lool> slomo_: Hmm can't find the sda tarball in the upstream location indicated in copyright
<lool> StevenK: [ "$foo" = ${foo/*\///} ]
<lool> I'm not particularly proud of that though
<TheMuso> tseliot: 0.99.3-2ubuntu2, which is the latest revision. If I drop 105 correct multifinger patch, my touchad works as expected, only two fingers and button click needed for right clicking.
<TheMuso> tseliot: I built the package without that patch and things work as I expected them.
<tseliot> TheMuso, tjaalton: ok, let's drop patch 105 then
<TheMuso> tseliot: Won't that break things again for other people?
<directhex> hm, yet more mouse annoyances. if even linux has useful config additions to gnome rejected, is there any point in trying myself?
<directhex> s/linux/linus/
<tseliot> TheMuso: no, I don't think so. The other patches I added solved their problems.
<tseliot> directhex: ?
<tjaalton> tseliot: the changelog says that 105 fixes bug 320632
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632
<tseliot> let me check
<directhex> apple live in a world of 1 button, gnome lives in a world of 3 buttons. if you happen to have more than three, then it's config file city to try & convince the system to use them properly (be it xmodmap or xorg.conf). it would be nice if "use my side buttons for back/forward plz" wasn't a chore to do
<tseliot> tjaalton: yes because it undos what my previous patch did ;)
<tseliot> undoes
<Mithrandir> directhex: doesn't that Just Work now?
<tseliot> directhex: I'm working on a daemon which will allow users to save their settings (applied through xinput)
<directhex> Mithrandir, as long as you own the same mouse as the guy who implemented it, it works great. otherwise, you can expect muddled key mappings
<directhex> Mithrandir, as an example, back/forward appear to be mapped to tilt-mouse-left/right here, not to back/forward
<Mithrandir> directhex: hm, maybe I've just been lucky.
<Mithrandir> on the other hand, mouse-wheel-tilt doesn't seem to work with my mx400
<directhex> Mithrandir, it's an improvement on hardy where tilting the mouse caused xorg to segv
<tjaalton> I'd like to be able to assign shortcuts to the buttons
<directhex> so this is a ms wireless laser 6000, and back/forward are mapped to the mouse wheel tilt - the mouse wheel has poor response as it is, so accidental tilting is common (and therefore so is accidental b/f)
<directhex> at home, my new razer lachesis has the side buttons act as b/f as expected - except they're swapped round from how they should be
<directhex> actually, the lachesis has other issues under loonicks, basically because the buttons are hardware-mappable & by default 4 buttons have bindings pre-encoded
<directhex> i should ask them for hints on making a control panel thing for it
 * tseliot > lunch
 * lamont wonders which intrepid (or even hardy-updates) update broke msdund support in bluetooth
<lamont> doh.  nevermind
<ScottK> In intrepid I'll go for bluez 3 -> 4 transition
<lamont> yeah - in hardy, it was plugging the bluetooth adapter into a 1.x hub downstream of the system connectors. :(
<lamont> and there's an intrepid bug wrt not being able to force a PIN for the remote device or some such
<kagou> Hi, is there a tool to report information of launched xorg ? (driver/dpi/resolution/option etc.)
<slangasek> kagou: if you're filing a new bug, 'ubuntu-bug xorg'
<kagou> slangasek, excellent ! Thanks
<primes2h> pitti: I uploaded debdiff for gnome-icon-theme for this bug #172353. Tell me if it's ok.
<ubottu> Launchpad bug 172353 in human-icon-theme "Human theme has non-translatable emblem names." [Low,Fix released] https://launchpad.net/bugs/172353
<Notch-1> hi, i've created a script in /etc/initramfs-tools/scripts/local-top/, but it seems to run 2 times, does anybody know why?
<pitti> primes2h: can you please assign the task to me?
<pitti> bdmurray: what was the other "dead" hotkey for you (not KEY_DVD)?
<directhex> <directhex> if someone were to show some love to 323790, then i could prepare one final app package & sign off on the mono 2.0 app transition as done (leaving only libs and tweaks, which are where space savings will suddenly happen)
<NCommander> TheMuso, ping?
<primes2h> pitti: Done.
<calc> what is DeadUbuntu?
<primes2h> pitti: Thanks
<pochu> bug 323790
<ubottu> Launchpad bug 323790 in mono "Please sync mono 2.0.1-4 (main) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/323790
<pitti> primes2h: thanks
 * calc thought it was a group for dead users but apparently they are alive
<bryce_> calc, maybe undead?
<bdmurray> pitti: KEY_PLAYER
<pitti> bdmurray: ah, thanks
<pitti> slangasek: would you mind if I upload a new hal-info which fixes some keycodes? (doesn't matter if it doesn't land in a4); or should I rather stall it?
<slangasek> pitti: go ahead, you're in the seb128 upload window :)
<jelmer> slangasek, lenny freeze
<slangasek> jelmer: but that doesn't forbid uploads to unstable of leaf packages... :)
<jelmer> slangasek, I asked dato about this a bit earlier and he asked me to upload to experimental during the freeze to keep unstable (rather than t-p-u) open for uploads that had to go into testing
<directhex> that's been our policy in the mono team
<directhex> since t-p-u sucks
<superm1> slangasek, <shrug> i'll take a look in a little bit here about it.  in the event that it can't be sorted out easily, can the 2-3-9 disks be marked for a4?
<superm1> if it's requiring source changes due to libx264 stuff, i just worry a little that it might be more involved
<slangasek> superm1: the biggest reason I wouldn't want to release those as alpha-4 is that you'd be missing ubiquity fixes that all the other flavors have; I'm happy to roll a slightly-later mythbuntu once mythtv is building again? (http://qa.ubuntu.com/reports/ogasawara/weatherreport/iso_pkg_diffs/mythbuntu-amd64-desktop.html)
<superm1> slangasek, ah that's a bit more than i expected in delta over the last day.  hopefully the x264 changes aren't too invasive then. i'll see
<jelmer> slangasek, btw, did you see my message about the upgraded ubuntu-grub branch?
<jelmer> now if only subvertpy would get through NEW so I can request a sync for jaunty...
<slangasek> jelmer: yes, but I guess you didn't see mine, asking how I'm supposed to get your stuff into the official tree :)
<slangasek> do I delete the branch currently there, and branch from yours to ubuntu-core-dev?
<jelmer> slangasek, just "bzr push -d lp:~jelmer/grub/ubuntu --overwrite lp:~ubuntu-core/dev/grub/ubuntu" should do it
<slangasek> ok
<jelmer> ubuntu-core-dev rather than ubuntu-core/dev obviously
<directhex> jelmer, welcome to NEW, please enjoy your stay
<jelmer> directhex, :-) It's not as bad anymore as it used to be though
<directhex> jelmer, really? how bad did it used to be? i think 200 packages queued, and a 4 week turnaround, are pretty bad
<jelmer> directhex, I've waited up to two months in the past I think, and it's release time atm
<jelmer> directhex, maybe I'm just getting used to it...
<directhex> jelmer, when you only release a dist every 2-3 years, perhaps a 1-month NEW time seems fast :p
<slangasek> jelmer: bzr: ERROR: Cannot lock LockDir(bzr+ssh://bazaar.launchpad.net/%7Ejelmer/grub/ubuntu/.bzr/branch/lock): Transport operation not possible: readonly transport
<jelmer> slangasek: Looks like you'll have to make a copy of my branch locally first, sorry :-/
<jelmer> slangasek, after that you should be able to "bzr push --overwrite" to the ubuntu-core-dev branch
<slangasek> ack
<jelmer> I'll file a bug about "bzr push -d " with remote branches, there's really no reason that shouldn't work
<kirkland> Riddell: what was the kubuntu sound package you told me to install to override k3b's annoying sound notifications?
<Riddell> kirkland: kubuntu-default-settings
<kirkland> Riddell: cheers, thx
<slangasek> jelmer: all done now, thanks!
<directhex> plinketty plinka plinketty plinka plinketty plinka plink plonk!
<directhex> sorry, kde flashback for a moment
<jelmer> directhex, otoh, REVU isn't very quick atm either
<directhex> jelmer, if you want to go down THAT road, take a look at the slowness of Mentors
<directhex> jelmer, some mono-related packages were removed from testing yet fixes were in mentors for months
<jelmer> directhex, oh, I wasn't aware of that
<jelmer> directhex, being able to find sponsors in Debian is much related to the sort of package you're uploading
<directhex> jelmer, yep
<directhex> jelmer, a bit like finding people to ACK syncs/merges in here ;)
<jelmer> directhex, mono-related packages seem to be a problematic kind, I've always had problems finding mentors for mine as well when I was not yet a DD
<directhex> jelmer, certain FUD campaigns are depressingly effective
<broonie> Well, there's also the general reluctance to faff about with packages for a software stack you don't understand.
<directhex> broonie, which largely comes down to questions of trust & accountability
<broonie> yup
<directhex> not wanting to be blamed for errors introduced in a package you ack'd
<directhex> at least, i hope that's the reasoning used, it's preferable to "you smell bad"
<jdong> :)
<jdong> you haven't got the "I hate streaming video" comments? :)
<directhex> jdong, which package are we talking about now? o_o
<jdong> directhex: btw do we have a Mono 2.2-ish PPA for Intrepid?
<jdong> I've been spending a bit of this morning compiling the stack in a local prefix
<directhex> jdong, no. all cycles being burned on 2.0-related tasks, and 2.2 breaks a LOT of apps
<jdong> directhex: ok, understandable
<directhex> perhaps "breaks" should be "increases compiler rigour and therefore requires patching of" but still
<directhex> t'is the reason jaunty will have 2.0.1 not 2.2
<jdong> I need some 2.2-ish features for some stuff I'm doing for work, so I'll just continue on my way :)
<directhex> carry on! /me waves his hand dismissively
<jdong> lol
<directhex> of course, you could always sync mono 2.0.1-4 if you wanted to. that'd help
<jdong> haha well I don't have a direct charge account for doing that which pays $37.50/hr :)
<directhex> syncing from debian isn't a job, it's a calling! a solemn duty!
<jdong> yes but putting food on the table helps with syncing from debian with fewer errors :)
<orospakr> I hope this is the right channel to ask this, but I have a package checked out from the package-import bazaar repositories, and I would like to build it using pbuilder.  However, the .dsc and orig tarballs are nowhere to be found inside the tree.
<orospakr> The DistributedDevelopment wiki pages only suggest using bzr builddeb.
<james_w> orospakr: "bzr builddeb -S" will create a source package for you to build in pbuilder
<surfaz> Can anyone look at this issue?
<surfaz> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-February/006818.html
<orospakr> james_w, thanks!
<slangasek> jelmer: hrm, 'bzr merge svn://svn.debian.org/pkg-grub/grub/trunk' still gives me a 'no common ancestor' error?  Did my overwrite of the ~ubuntu-core-dev branch not work as intended?
<jelmer> slangasek, you need to merge svn://svn.debian.org/pkg-grub/grub/trunk/debian
<slangasek> jelmer: oh!  trying :)
<hyperair> does anybody know where software-properties gets its list of mirrors from?
<slangasek> jelmer: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. :(
<jelmer> slangasek, are you using bzr-svn 0.5 ?
<glatzor> hyperair, yes me. The list is part of python-apt
<slangasek> <cough> no, did you tell me to? :-)
<hyperair> glatzor: thanks, i'll poke around in there
<glatzor> hyperair, There is already code in software-properties to add custom mirrors easily, but I haven't yet found the time to complete this feature
<hyperair> glatzor: dyou know if it's possible to add a custom mirror? right now if i dist-upgrade, i have to hack around it by adding a /etc/hosts entry that points to localhost, and use mod_proxy to get the server i want
<tseliot> Keybuk: do you know why this dbus call fails? http://pastebin.com/d3c811f58 (I get "The name org.x.config.display0 was not provided by any .service files")
<hyperair> glatzor: ah faster than me
<hyperair> glatzor: heheh
<hyperair> for now i guess i'll dpkg-divert it or something
<glatzor> hyperair, why do you need to change it to localhost?
<hyperair> glatzor: because the whole dist-upgrade process doesn't recognize my on-lan archive mirror
<hyperair> glatzor: i'm an archive mirror admin in my campus network, and it actually uses that to upgrade, i can upgrade at 10MB/s
<hyperair> glatzor: to upgrade from hardy to intrepid that's what i did. i set the mirror to sg.archive.ubuntu.com, added a /etc/hosts entry to point sg.archive.ubuntu.com back to my comp, and then used apache2 + mod_proxy to forward requests to ntuoss1.uni.cx
<jelmer> slangasek, Sorry :-) It's available from the bzr PPA
<jelmer> (https://edge.launchpad.net/~bzr/+archive/ppa)
<glatzor> hyperair, you should fill a bug to update-manager to easily allow to custom mirrors
<glatzor> hyperair, mvo is the author of the upgrade tool
<hyperair> glatzor: but weren't you working on it?
<glatzor> hyperair, software-properties is not the same as the upgrade tool
<glatzor> the later one is part of update-manager
<glatzor> hyperair, please could you fill a bug on python-apt too?
<glatzor> hyperair, I will investigate how far the support of custom mirrors is. I worked on it 2 years ago
<hyperair> so long? =(
<hyperair> what are the package names?
<tseliot> Keybuk: never mind
<hyperair> glatzor: imo the reason the upgrade tool couldn't support custom mirrors is because there's no real way to identify whether a mirror is an official archives mirror or just some random 3rd-party mirror
<glatzor> hyperair, AFAIK it does detect a vailid mirror by taking the mirror list of python-apt into account
<hyperair> glatzor: but that's only the python-apt mirror list
<hyperair> glatzor: that does not include custom mirrors
<hyperair> glatzor: the problem was that my mirror is not in the mirror list
<glatzor> hyperair, right. that is why you need the custom mirror support on python-apt level
<hyperair> yep
<hyperair> which means that if python-apt supported it, everything else above it would work wonderfully
<hyperair> glatzor: right?
<glatzor> hyperair, I think so
<hyperair> glatzor: https://code.launchpad.net/~madjar/python-apt/custom-mirror <-- this?
<hyperair> glatzor: so i added http://ntuoss1.uni.cx/ubuntu/ to the list of mirrors in /usr/share/python-apt/templates/Ubuntu.mirrors, but it doesn't seem to work eh =\
<directhex> tseliot, can you tell me more about this mouse daemon of yours?
<tseliot> directhex: it's a dbus daemon which will use xinput and its methods will be accessible from any language through dbus. This daemon will also be able to read and apply settings from a configuration file
<directhex> and in this instance, we're talking about abusing set-button-map ?
<tseliot> directhex: ? It will be able to do whatever xinput can do
<directhex> hm, interesting
<directhex> does this exist yet, or is it all planning-stages?
<tseliot> directhex: I'm experimenting a bit in these days
<directhex> i'm taking a look at this new mouse, and wondering how to unlock the most advanced features
<directhex> i'm thinking i might need a usb bus sniffer on windows to start analysing
<directhex> but still, your xinput daemon sounds nifty. i'd like to get my hands on that
<directhex> though it's lower priority than a new nvidia 180 in intrepid ;)
<orospakr> perhaps I should ask a different question:  how is a .dsc typically generated from the debian/ packaging directory, without actually running a build?
<pochu> orospakr: dpkg-buildpackage -S
<maxb> (This does run debian/rules clean, though)
<orospakr> maxb, yup, that seems to be what bzr db is doing
<orospakr> same problem -- dependencies are checked on my host Ubuntu install.
<pochu> so
<orospakr> normally I would take the path of least resistance and not bother using pbuilder, but I am trying to backport a package to Hardy.
<pochu> dpkg-source -b package-1.0/
<orospakr> oohl, I think that's what I'm looking for!
<orospakr> s/oohl/ooh/
<lamont> scanimage --list-devices
<lamont> device `v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device
<lamont> ^^  GAH how do I get that to actually, say, CONTINUE AND FIND THE SCANNER?
<orospakr> pochu, it worked!
<pochu> great :)
<hyperair> aha
<hyperair> python-apt doesn't support servers with numbers in their hostname!
<hyperair> so that's why adding an address woudln't work
<pochu> hyperair: jaunty? I think they should work since 0.7.9~exp2ubuntu1
<pochu>   * aptsources/distinfo.py:
<pochu>     - fix too restrictive mirror url check
<hyperair> pochu: yeah, i just saw the bug
<hyperair> pochu: but i'm on intrepid =\
<pochu> the fix is trivial
<pochu> -        match_mirror_line = re.compile(r"^(#LOC:.+)|(((http)|(ftp)|(rsync)|(file)|(https))://[A-Za-z/\.:\-_]+)$")
<hyperair> yeah it is
<pochu> +        match_mirror_line = re.compile(r"^(#LOC:.+)|(((http)|(ftp)|(rsync)|(file)|(https))://[A-Za-z0-9/\.:\-_]+)$")
<hyperair> i know
<hyperair> i know
<hyperair> i already fixed it on my system
<pochu> ah ok :)
<hyperair> but the impact is great isn't it
<hyperair> wonder if it would be considered for an SRU
<pochu> it probably isn't, otherwise it would have been noticed long time ago ;)
<hyperair> hmm
<hyperair> treu
<hyperair> true*
<pochu> I asked mvo and he told me he didn't think it was worth it
<hyperair> but all the numbered mirrors are missingfrom the list
<hyperair> ah
<pochu> but that if I wanted to prepare one, it could be considered
<hyperair> not even if someone else prepares the SRU debdiff?
<hyperair> ah
<hyperair> i see
<hyperair> i was considering preparing it myself but seems you're first ;)
<hyperair> oh yeah, what does it take for mirrors to be added to the list?
<hyperair> Ubuntu.mirrors that is
<pochu> oh no, I'm not doing it. Feel free to do it yourself ;)
<directhex> usb protocol analysis seems to be hard
<hyperair> directhex: sure it is. i went through hell just trying to figure out what some USB hex key codes meant, and that's just the tip of the iceberg
<hyperair> pochu: <hyperair> oh yeah, what does it take for mirrors to be added to the Ubuntu.mirrors list?
<directhex> hyperair, to what end?
<hyperair> directhex: i scrolled through the damn docs multiple times
<hyperair> and in the end gave up
<hyperair> it wouldn't work anyway
<hyperair> i was trying to do the bluetooth profile thing for sony ericsson
<hyperair> make one for global keyboard shortcuts
<hyperair> but it failed miserably in the end
<orospakr> OK, this is strange: pbuilder is failing with "Depends: mozilla-dev (>= 1.1.12) but it is not installable".  However, if I run pbuilder --login and attempt to install that package directly with apt-get, it's fine.
<pochu> orospakr: is it a real package or a virtual one?
<pochu> orospakr: btw, #ubuntu-motu sounds more appropriate :)
<orospakr> pochu, fair enough ;)
<orospakr> although to answer your question, yes, it's a virtual package.  I should probably just use the real one it points to, heh. thanks for the tip. :)
<hyperair> pochu: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/223097 <-- uploaded debdiffs
<ubottu> Launchpad bug 223097 in python-apt "python-apt should accept '@' in mirror adresses" [Undecided,Fix committed]
<hyperair> pochu: could you take a look and give an ack by any chance?
<pochu> hyperair: I'm not a core-dev unfortunately ;) but I'm looking at it
<hyperair> pochu: okay
<pochu> hyperair: I think you can patch the source directly, it's a native package
<pochu> no need to use a patch system ;)
<hyperair> ah
<pochu> otherwise looks good (you could also say in the changelog that it also allows numbers)
<hyperair> eh didn't i?
<pochu> only for "@" ;)
<ScottK> Yes.  Don't use a patch system in a native pacakge.
<pochu> oh
<pochu> you did mention numbers too :-) nvm
<hyperair> +  * debian/patches/01_less-restrictive-uris.patch:
<hyperair> +    + Allow @ and numbers in mirror URIs (LP: #223097)
<hyperair> hahah
<pochu> I'm blind :P
<pochu> too many hours in front of the screen, you know ;)
<hyperair> pochu, ScottK: i'm done. no patchsys now =)
<pochu> hyperair: cool. :)
<hyperair> pochu: =)
<Davedan>  I'm installing a package with apt-get install. If this package has config files, can I find out where these files are using a script?
<maxb> Davedan: Please read the topic and note that usage questions are very much not on topic here
 * directhex still thinks dealing with bug 323790 is a great use of time for only the sexiest of core devs
<ubottu> Launchpad bug 323790 in mono "Please sync mono 2.0.1-4 (main) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/323790
<ScottK> directhex: It won't get done until after the Alpha 4 freeze is over anyway, so no rush.
<directhex> ScottK, hm, is freeze on? when's that over?
<ScottK> directhex: Yes.  As is mentioned in /topic.  When Alpha 4 is released, probably Thursdayish.
<directhex> i don't have a big enough monitor for /topic. that's my excuse & i'm sticking with it
<davmor2> ScottK: You of course meant to say Thursday afternoon then didn't you ;)
<ScottK> No.  It's scheduled for Thursday, but it's done when it's done.
<ScottK> So Thursdayish seems about right.
<ScottK> Sometimes it's Friday.
<davmor2> ScottK: ah but no-one has called for a re-spin yet and I'm nearly at the point at which there is on netboot to go which I can churn out in a morning :)
<davmor2> s/on/only
<ScottK> Odds are it'll be Thursday afternoon somewhere.
<davmor2> I can go with that :)
<sven777> hi there - which files should be uploaded to MOTU for a brand new package?  (I'm new  :)  )
<sven777> oops - should I ask in #ubuntu-motu ?
<sven777> nm - received answer - thx :)
<tjaalton> pitti: re: new hal-info; actually XI2 will allow X to use keycodes >255, so maybe for jaunty+1
<pitti> tjaalton: ah, good to know
<Hobbsee> drat.  the power off button, even on a locked screen, turns off my computer.
<lifeless> Hobbsee: you'd rather it didn't?
<Hobbsee> lifeless: well, yes.  i'd expect lock screen to actually lock the screen, and not do anything with any keypress (except magic sysrq and such, i guess), until it gets the p/w again
<lifeless> oh, you're talking about a soft power button ?
 * Hobbsee was meaning the power button that she accidently tapped once, on her laptop.  not sure if i'ts soft or hard?
<lifeless> if hitting 'might' turn the machine off, its soft
<lifeless> if hitting it always turns it off, its hard
<lifeless> a circuit breaker is a hard power switch :)
<Hobbsee> ah, i see.
 * Hobbsee hasn't tried it multiple times
<lifeless> most new machines have software power buttons these days, I was really just being silly ;P
<Hobbsee> ahhh
<Hobbsee> no wonder i'm getting confused!
<lifeless> mission impossible....success
 * ScottK watches lifeless push Hobbsee's buttons several time.
<lifeless> ScottK: this room is a tad public for that
 * lifeless ducks
 * ScottK steps away from lifeless
<Hobbsee> well, that's not hard.  I *did* boot to KDE after accidently shutting down gnome today
<ScottK> ;-)
<lifeless> I don't know you anymore
<lifeless> Hobbsee: btw, we should have another syd-motu-dinner
<lifeless> Hobbsee: I have nearly forgotten the taste of that indian
<Hobbsee> lifeless: mmmm....agreed!
<Hobbsee> lifeless: late feb, or so?
<lifeless> sounds good
#ubuntu-devel 2009-02-05
<ScottK> lool: You seemed really on the ball about lanaguage issues with the xinelib SRU issue that recently came up.  I was wondering if you would be willing to take a look at Bug #325221
<ubottu> Launchpad bug 325221 in intrepid-backports "Brasero 0.9.1 breaking non-English systems" [High,New] https://launchpad.net/bugs/325221
<Hobbsee> fta: thanks for your thunderbird package - i've finally tried it now.  it's quite a change!
 * slangasek bzr merges and hugs jelmer 
<mathiaz> cjwatson: where can I find the cpio command used to create the initrd.gz file shipped on isos?
<Mithrandir> in debian-installer, I suspect.
<mathiaz> Mithrandir: thanks!
<cjwatson> mathiaz: what Mithrandir said. Specifically:
<cjwatson> define mkinitramfs
<cjwatson>   (cd $(TREE) && find . | cpio --quiet -o -H newc) >
<cjwatson> endef
<cjwatson>         initramfs) \
<cjwatson>                 $(mkinitramfs) $(TEMP)/initrd; \
<cjwatson>                 gzip -v9f $(TEMP)/initrd; \
<cjwatson>         ;; \
<cjwatson> or abbreviate as '(cd $TREE && find . | cpio --quiet -o -H newc) | gzip -9c > $TEMP/initrd.gz
<cjwatson> '
<Chipzz> talking about debian-installer... has anyone ever tested ftp://ftp.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/netboot/gtk/ ?
<Chipzz> been doing a lot of installs of lenny with the debian equivalent of that lately, and wondering how well that works on ubuntu/if it's tested/supported
<slangasek> it's not widely exercised, because Ubuntu has its own graphical installer
<Chipzz> I'm aware of that :)
<directhex> i've not used gtk d-i
<Chipzz> but does it get tested, or is it there just because debian builds it, and we get it for free?
<directhex> but i've scripted dapper d-i before
<slangasek> Chipzz: QAing the gtk installer isn't part of the Ubuntu release process at all
<Chipzz> right, I would have expected that; but has anyone actually ran it to see if there's any semblence of it working at all, or not? :)
<tjaalton> I've tried it, doesn't work
<Chipzz> that's what I wanted to know, thx :)
<tjaalton> needs porting libgtk+2.0-directfb to the current version
<Chipzz> I might give it a shot anyway, maybe there have been improvements lately :)
<tjaalton> no, it'll fail
<davmor2> Chipzz: I'm about to test it now for the first time on jaunty cycle
<Chipzz> tjaalton: about the porting; isn't that package built from the regular gtk+ source?
<tjaalton> Chipzz: yes, ask seb128 how hard it is to maintain :)
<tjaalton> does tar have a 2GB limit on 32bit systems, or why does dpkg -c fail listing a huge (2,7GB) dpkg on hardy?
<Chipzz> I'ld expect that the ubuntu package is roughly the same as the debian package
<Chipzz> but maybe the libdirectfb package is the problem?
<davmor2> Chipzz: meh sorry no I'm testing standard netboot sorry misread the link
<StevenK> directhex: So a whole bunch of Mono pre-2.0 is ending up in NBS, do you want to deal with f-spot and tomboy after alpha-4, or you have it handled?
<StevenK> Er, do you want me to deal with
<directhex> StevenK, what are the specifics?
<StevenK> directhex: Both f-spot and tomboy Build-Depend and Depend on libgnome2.0-cil, which is NBS
<directhex> ah, yes
<directhex> f-spot is almost ready for syncing, but requires a mono-addins sync first
<directhex> Laney prepared f-spot
<DktrKranz> doko, mind looking at bug #324636 ?
<ubottu> Launchpad bug 324636 in gnat-4.3 "gnat-4.3 needs update" [High,Confirmed] https://launchpad.net/bugs/324636
<directhex> tomboy i'm not sure where we stand, let me check
<StevenK> directhex: Do you have a bug for mono-addins sync?
<directhex> StevenK, bug 324741
<ubottu> Launchpad bug 324741 in mono-addins "Please sync mono-addins 0.4-2 (main) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/324741
<StevenK> Right, it just needs a sponsor
<directhex> right, f-spot 0.5.0.3-1 in experimental is free from libgnome2.0-cil
<directhex> just checked
<StevenK> \o/
<directhex> and tomboy 0.12.2-2
<StevenK> directhex: Getting those two sorted out rips out like 4 or 5 Mono bits, which makes me happy
<directhex> StevenK, good. that was the plan!
<directhex> i promised savings, i'm sure i promised savings ;)
<doko> DktrKranz: please wait until Debian uploads the new .orig.tar.gz
<StevenK> I'm the Steve who cares about archive consistency, the other Steve archive admin cares about CD savings
<directhex> StevenK, the gnome# 2.24 transition was unexpected & unfortunate. i would normally expect abi-stability in a minor version update, but hey ho
<DktrKranz> doko: ok, I'll keep it under my radar, thanks.
<StevenK> directhex: It happens
<directhex> StevenK, apparently so. we also made an executive decision not to do mono 2.2, since it reveals bugs in pretty much every app (bugs which need patching to fix FTBFS) and frankly we don't have the energy to do it for jaunty
<StevenK> directhex: Hehe, it can wait for Jaunty+1
<directhex> StevenK, upstream these days seems to be on a crusade to make life hard. 3-month major release cycle, no bugfix releases. we might jump to 2.4 when it's released & just harden it the way we have to lenny's 1.9.1
<directhex> i lost count of the number of patches we had to apply for that
<slangasek> superm1: are you aware of any reason that 30-keymap-dell.fdi shouldn't map the 'CRT|LCD' hoktey to KEY_SWITCHVIDEOMODE, which X receives and g-s-d honors, instead of KEY_DISPLAYTOGGLE which X can't see and hal doesn't handle?
<lool> ScottK: Hmm sorry, I'm not sure how I can help with #325221; I'm not into l10n particularly, I don't use brasero, nor intrepid and backports, and I don't understand the issue nor the symptoms   :-/
<pitti> superm1: wrt. slangasek's question, it's on http://lists.freedesktop.org/archives/hal/2009-February/012938.html
<ScottK> lool: OK.  Thanks for looking.
<directhex> ScottK, anything more i can help you with?
<ScottK> If you can figure out what brasero is switching languages on people (see Bug #325221), that'd be highly useful.
<ubottu> Launchpad bug 325221 in brasero "Brasero 0.9.1 breaking non-English systems" [Medium,Confirmed] https://launchpad.net/bugs/325221
<directhex> mmm, C. out of my zone of competence, really
<seb128> brasero is likely unsetting the translation domain or something
<seb128> would be worth looking upstream if they got bugs about that and fixed it
<TheMuso> c
<TheMuso> c
<TheMuso> gah
<ScottK> pitti: With the exception of reverification of Bug #290768 after the security update, I believe we've tested everything for getting KDE 4.1.4 to -updates from -proposed.  I don't imagine you'll want to deal with it until next week, but I think we are in good shape for it.
<ubottu> Launchpad bug 290768 in xine-lib "C format string specifications mismatch in translations crashes libxine based apps in some loales" [Undecided,Fix committed] https://launchpad.net/bugs/290768
<McEnroe> Quick question: is the default ubuntuan pulseaudio server per-user or system wide?
<slangasek> per-user
<McEnroe> slangasek: thanks
<IntuitiveNipple> Is it intentional to have two identical 'sound' icons in the notification area; the volume applet and 'sound preferences' ?
<tjaalton> IntuitiveNipple: no, the applet is "obsolete"
<IntuitiveNipple> gnome-volume-control-applet, you mean?
<IntuitiveNipple> OK... I assume mixer_applet2 is the 'new' one? Is that related to the pulseaudio volume control?
<tjaalton> no applet, pulseaudio uses the notification area now
<IntuitiveNipple> But, I presume the process is the '/usr/lib/gnome-applets/mixer_applet2 --oaf-activate-iid=OAFIID:GNOM' ?
<IntuitiveNipple> As long as this isn't a bug :)
<tjaalton> I don't have that running
<IntuitiveNipple> hmmm... this is testing the daily 0203.1 liveCD (amd64) on Sony Vaio VGN-FE41Z (HDA StAC92xx audio)
<IntuitiveNipple> I didn't see the two identical icons with the alpha 3 live CD
<IntuitiveNipple> eeek Ubiquity/partman is causing the kernel to *lose* two partitions ... that's one more than the alpha-3 installer lost!
<[diablo]> afternoon all... is there anyone around familiar with the RT kernel please?
<cjwatson> Chipzz: as mentioned, it's known not to work at the moment, and we may stop building it again. Ubuntu is a major version of GTK ahead of Debian, and it turns out that there were some changes made to GTK in that cycle that changed the interface with GDK backends, and the X backend was updated but not the DirectFB backend. The update is non-trivial
<cjwatson> Chipzz: we'd like to offer it but it may be that now is just an unlucky time
<superm1> slangasek, pitti let me double check some things on a real system before i give an answer
<superm1> slangasek, i uploaded a fixed mythtv and mythplugins.  can you queue a rebuild of live disks for mythbuntu with them now?
<slangasek> superm1: sure - are 0ubuntu6, 0ubuntu4 the target versions?
<pitti> ScottK: great to hear! so the second regression you were talking about was just the missing dependency?
<slangasek> superm1: so we went back and looked at the Dell we were basing this on, and it actually has both a switchvideomode key /and/ a displaytoggle key; but g-s-d *does* a display toggle, when it receives the switchvideomode key, and there's no handling for displaytoggle at all in the stack :)
<superm1> slangasek, what model was this?
<seb128> slangasek: it doesn't really do a display toggle, it turns between configurations
<seb128> slangasek: ie, xinerama, clone, laptop, projector, etc
<slangasek> superm1: Inspiron 1505
<slangasek> seb128: ok - it does a display "rotate" :)
<superm1> slangasek, okay i'll try to get a good look at a variety of inspirons then... i know that i verified the current setup was working properly for many laptops display switch hotkeys in intrepid, i'll just reverify everything with jaunty paying attention to these two key symbols
<slangasek> seb128: my point is that what it doesn't do is rotate through available resolutions
<seb128> no, but not really toggle the display either
<slangasek> superm1: sorry, I'm getting mixed up - it's not the Inspiron that had both the switchvideomode and displaytoggle buttons
<slangasek> seb128: I think the current behavior is completely in line with what I would understand as "display toggling"
<seb128> right
<slangasek> superm1: in any case, intrepid vs. jaunty is definitely a difference here; g-s-d upstream provides better xrandr handling of the XF86Display (== switchvideomode) and we dropped an upstream patch that was interfering with this
<slangasek> superm1: pitti and I independently reached the conclusion that this should be changed, so I'm fairly confident that it's correct - but would of course still be happy to have your review
 * superm1 nods
<seb128> slangasek: I'm wondering if upstream picked f7 because f8 is broken
<seb128> or rather f8 doesn't trigger any xev
<slangasek> seb128: you mean the 'switchvideomode' instead of 'displaytoggle'?  I think that's fairly certain
<seb128> yes
<lool> Keybuk: Did you intend to upload bootchart 0.9-0ubuntu8keybuk3 to jaunty?
<Keybuk> Do I?
<Keybuk> or Did I?
<lool> Keybuk: Did you?
<lool> Keybuk: It was uploaded, is it a mistake?
<Keybuk> yes, was supposed to go to PPA
<ion_> Why does dput have a default upload host again? :-)
<henrik-hw0> Keybuk: regarding our talk earlier. did you find out anything of significance?
<Keybuk> henrik-hw0: you didn't respond to my last question; grep for the module name in /etc/modprobe.d
<henrik-hw0> Keybuk: Ah. I blame communication over the device we debugged. :/
<henrik-laptop-hw> Keybuk: grepping for the module name in /etc/modprobe.d shows nothing
<Keybuk> henrik-laptop-hw: no idea then, modprobe is being called
<Keybuk> could be simply a module bug
<henrik-laptop-hw> Keybuk: Alright. thanks for your help.
<slangasek> superm1: mythbuntu candidates up
<superm1> slangasek, thanks. i'll let my folks know to grab and test away
* slangasek changed the topic of #ubuntu-devel to: Archive: open, MoM running | alpha-4 released | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<wolfeySI> hello guys i just tracerouted si.archive.ubuntu.com
<wolfeySI> and you use one of worst possible servers for slovenian users
<wolfeySI>  leningradskaya.canonical.com
<wolfeySI> if that's russia
<wolfeySI> that's far network wise
<wolfeySI> .sk, .de, .it, .at, .hr would all be so much better
<wolfeySI> just a thought, i changed to .de mirror long ago, but didnt traceroute until now
<wolfeySI> so newbies get 1 kB/s download at updating ubuntu
<pochu> wolfeySI: hi, I think #ubuntu-mirrors is the right channel for such suggestions
<wolfeySI> ok thx
<ScottK> pitti: re KDE 4.1.4, the second regression I mentioned before turned out to be a user configuration error unrelated to KDE.  The kdebluetooth missing dependency came up since, but was easy enough to verify.  The xine-lib SRU verification is really the only think that needs doing I think.
<maxb> If two packages (bzr+bzrtools) need to be synced together, do I file two sync request bugs or one mentioning both?
<dtchen> the cryptsetup/udev note in the jaunty alpha 4 release notes erroneously refers to an ltsp bug when it should refer to bug 325690
<ubottu> Launchpad bug 325690 in udev "udev has wrong name for devmapper devices, cryptsetup initramfs hook fails" [High,Confirmed] https://launchpad.net/bugs/325690
<ScottK> dtchen: The wiki version of the tech overview is still editable.
<neXyon> greetings
<imme> uhm, how can I get jaunty to start gnome completely?
<ScottK> imme: #ubuntu+1 for Jaunty support
<imme> merci ScottK
<ScottK> imme: You're welcome.
<superm1> pitti, slangasek it looks like it's still doing the right thing on the handful of machines i've looked at with jaunty and that updated hal-info.  if i come across any with the wrong behavior i'll let you know
<slangasek> superm1: ack, thanks
<superm1> re the mythbuntu disks, looks like there might actually be a ubiquity regression.  i'll have to give it a more thorough look later on
<calc> evolution is a big pos
<calc> i just crashed it several times in a row just trying to view a message
<calc> nothing weird with the messsage it was an old one i already read
<calc> now it crashes every time i even try to search
<calc> i wish thunderbird could sort
<calc> maybe i just need to setup my own imap server to do server side filtering, so i can switch to thunderbird
<directhex> surely you must be used to bloaty unmaintainable monsters, calc?
 * ScottK whispers kmail to calc.
<Keybuk> scottK: you mean Kreationism?
<ScottK> It's actually one of the KDE apps that I understand has a big following among Gnome users.
<jdong> does that require Oracle DBMS or something? ;-)
<ScottK> Mysql unfortunately.
<jdong> out of curiousity, what is the justification for what I feel is a overuse of MySQL in KDE4?
<jdong> I really don't see much that a smaller/lighter DB backend couldn't have done
<ScottK> They've got this thing called Akonadi that is meant to be the ultimate answer to life, the universe, and everything.
<ScottK> It uses Mysql.
<ScottK> That's the Kmail answer.
<ScottK> The Amarok answer is when they were looking for help, the Mysql people volunteered to help them and did.  No one else was as interested.
<jdong> it's the ultimate answer for making sure I structure my home directory how AppArmor wants it :)
<ScottK> That too.
<jdong> btw KDE 4.2 is pretty nicely polished overall now, I am impressed
<jdong> the big area of work IMO is still with handling laptop multimedia keys
<jdong> that whole kubuntu xmodmap thing needs to DIE :)
<ScottK> jdong: We have pretty good luck with getting stuff fixed upstream.
<ScottK> What we lack in this area is someone with enough focus and technical understanding to communicate it effectively.
<ScottK> So please feel free to join us ....
#ubuntu-devel 2009-02-06
<IntuitiveNipple> Have you guys seen the tuxradar comparision of Ubuntu versions vs Windows versions? It's very flattering
<IntuitiveNipple> http://www.tuxradar.com/content/benchmarked-ubuntu-vs-vista-vs-windows-7
<EagleScreen> Ubuntu can skip a routine file system check with ESC key, it is necessary to use usplash to have this feature?
<EagleScreen> is this a Ubuntu specific patch or a feature from upstream?
<sladen> EagleScreen: read /etc/init.d/check*.sh
<sladen> EagleScreen: the actual magic is in /lib/init/usplash-fsck-functions.sh
<EagleScreen> thanks
<directhex> .topic
<directhex> bah
<gimpscape_> hi
<gimpscape_> I have installed one package using this command: sudo dpkg -i --force-architecture qbittorrent_1.3.1-0ubuntu2_i386.deb
<gimpscape_> and know I'm unable to remove it, it simply doesn't show in any package manager, just like it would not be installed
<gimpscape_> but I can see qbittorrent file all over the system
<gimpscape_> isn't it a very serious bug?
<gimpscape_> s/and know/and now
<Hobbsee> gimpscape_: i believe you want #ubuntu for support.
<gimpscape_> Hobbsee: so this is not dpkg bug? I have done something wrong?
<ion_> Also, you probably shouldnât blame dpkg for something going wrong with --force.
<Hobbsee> ion_: exactly
<gimpscape_> I thought that --force-architecture is safe...
<directhex> dpkg --purge qbittorrent
<gimpscape_> directhex: already tried that
<gimpscape_> directhex: E: Couldn't find package qbittorrent
<ion_> âWarning:  These  options  are mostly intended to be used by experts only. Using them without fully understanding their effects may break your whole system.â âdpkg(1)
<Hobbsee> dpkg -r qbittorrent, then.
<Hobbsee> according to man dpkg.
<directhex> i blame qt. this wouldn't happen with some nice arch-all mono stuff ;)
<gimpscape_> Hobbsee: ohh... you are right
<gimpscape_> Hobbsee: that fixed the problem
<gimpscape_> sorry for asking lame questions here, I should read the man
<Hobbsee> yes, probably.  and failing that, there's #ubuntu for support ;)
<calc> does our rpm2cpio not extract modern rpms (eg OpenSUSE rpms)?
<calc> ug debian bug 509444
<ubottu> Debian bug 509444 in rpm "rpm2cpio unable to unpack SLES10 rpms" [Normal,Open] http://bugs.debian.org/509444
 * calc needs to be able to unpack them :\
<sbeattie> calc: odd. What do you need?
<calc> sbeattie: i found the solution with some help from #opensuse
<calc> you now have to do 'cat | rpm2cpio | lzma -d | cpio -ivd'
<calc> i followed up to the debian bug report about the issue as well
<ion_> UUOC ;-)
<calc> well makes it more clear ;-)
<calc> so currently rpm2cpio is actually rpm to blob ;)
<Riddell> mathiaz: I uploaded amarok, do you want to revert the changes to mysql-dfsg-5.1?  (I'd do it but I see you made changes in the mean time so probably best you re-merge those in)
<mathiaz> Riddell: I'll take care of the mysql package now that amarok has been updated.
<lool> seb128: Hmm bug-buddy recommends gnome-dbg; that's kind of pulling a lot
<seb128> lool: that's coming from debian
<lool> seb128: I know :)
<lool> seb128: I'm pushing a fixed package
<lool> seb128: I wanted to tell you so that you check for such recommends in the future
<directhex> is alpha 4 done? can i administer a mild poke for a couple of sync bugs?
<seb128> lool: well the idea was to try to make sure upstream gets decent stacktraces I think
<seb128> directhex: yes and later
<lool> seb128: That might be a good idea on Debian, but shouldn't Ubuintu users use -dbgsyms instead?
<seb128> lool: ubuntu users should use apport ;-)
<seb128> I've no real strong opinion on bug-buddy in ubuntu
<lool> I don't know why I got bug-buddy at all in fact
<Riddell> mvo: update-notifier-kde uploaded, you can mark your branch as merged
<mvo> Riddell: what was the branch url again?
<Riddell> mvo: https://code.edge.launchpad.net/~mvo/update-notifier-kde/mvo
<mvo> thanks Riddell
<GyrosGeier> hi
<GyrosGeier> I'm packaging a web app, targetting hardy. Is there infrastructure for web apps in hardy already that I could use (webapps-common doesn't seem to exist) or do I need to reinvent the wheel
<seb128> StevenK: could you look at bug #294271, it's a tsclient sponsoring request for a bug in the hildonize changes
<ubottu> Launchpad bug 294271 in tsclient "version of the RDP protocol inversed" [Low,New] https://launchpad.net/bugs/294271
<StevenK> seb128: Good idea. I'll drop the hildonfm change while I'm at it
<seb128> StevenK: ok ;-)
<dholbach> seb128: where's your magic "this needs updating" page?
<dholbach> or norsetto's rather
<seb128> pochu: ^ do you know the url?
<seb128> dholbach: let me look for it
<pochu> yeah, sec
<dholbach> seb128: want to show an "update" example - give me an easy one :)
<dholbach> seb128: ... for jcastro
<pochu> dholbach: http://norsetto.890m.com/desktop_packages.php
<jcastro> seb128: make it easy. ;)
<seb128> dholbach: vinagre
<dholbach> http://norsetto.890m.com/desktop_packages.php ?
<dholbach> :)
<dholbach> awesome
<seb128> http://download.gnome.org/sources/vinagre/2.25/vinagre-2.25.90.tar.gz
<seb128> http://download.gnome.org/sources/vino/2.25/vino-2.25.90.tar.gz should be easy too if you want an another one
<dholbach> thanks a bunch seb128 :)
<dholbach> thanks pochu too
<seb128> you're welcome
<seb128> dholbach: otherwise since that's jcastro you can update the rhythmbox snapshot to current svn if you want ;-)
<dholbach> :-)
<directhex> why does norsetto's page track sid for some & exp for others?
<directhex> 'cos debian has a cleaner newer f-spot than ubuntu
<seb128> directhex: "cleaner"? the version uploaded to debian is basically the jaunty version no?
<directhex> seb128, it bundles a private copy of mono.addins iirc. and there's the whole NBS issue too
<seb128> we should just stop using mono in the default install ;-)
<directhex> seb128, or core devs should stop leaping behind desks & hiding whenever i open my gob and the word "sync" comes out
<directhex> one or t'other
<seb128> ?
<directhex> mono-related blocking sync/merge bugs can take a rather long time before anyone goes near them, unless i sit & poke people individually, IME
<seb128> directhex: should f-spot be synced?
<seb128> directhex: we do syncs several times a week
<directhex> seb128, f-spot blocks on mono.addins 0.4
<seb128> directhex: there is no mono syncs waiting
<directhex> bug 323790
<ubottu> Launchpad bug 323790 in mono "Please sync mono 2.0.1-4 (main) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/323790
<directhex> bug 324741
<ubottu> Launchpad bug 324741 in mono-addins "Please sync mono-addins 0.4-2 (main) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/324741
<directhex> bug 323948
<ubottu> Launchpad bug 323948 in cli-common "Please sync cli-common 0.6.0 (main) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/323948
<directhex> bug 323542
<ubottu> Launchpad bug 323542 in ndoc "Please merge ndoc 1.3.1-5 from Debian Experimental" [Undecided,Confirmed] https://launchpad.net/bugs/323542
<seb128> directhex: ubuntu-archive is not subscribed so they are not listed on the ubuntu-archive todolist
<seb128> no wonder it takes a while
<StevenK> Maybe they need sponsorship
<seb128> yeah just pointing that ubuntu-archive is not the blocker there
<StevenK> u-m-s is the blocker
<directhex> i wasn't moaning at -archive, i was moaning in general. it's cathartic
<StevenK> Moan at dholbach
<ScottK> cathartic/demotivating for sponsors.
<dholbach> StevenK: ?
<dholbach> pochu, seb128: I'll just upload jcastro's vinagre update - it's good work!
<seb128> dholbach: excellent!
<dholbach> vino next!
<slangasek> mvo: bug #247130 :)
<ubottu> Launchpad bug 247130 in update-manager "funny output when a package gets downgraded via pinning" [Low,Triaged] https://launchpad.net/bugs/247130
<slangasek> mvo: so maybe that only applies to downgrades
<slangasek> and maybe it's not an update-notifier problem at all
<slangasek> mvo: ok - I've confirmed that this problem doesn't show up with pinning a package at an earlier version
<slangasek> mvo: so you can continue to ignore that bug ;)
<mvo> slangasek: :) excellent! I *think* there is a bug with packages on hold though, so your concern is very valid
<ScottK> mvo: I did some discussing with other backports people and I think everyone is behind the not-automatic idea for backports.  Do you think there's a chance for getting that merged in this cycle?
<mvo> ScottK: thanks for leading this discussion, I think chances are very good
<mvo> scottK especially if there is interesst like this in it now
<ScottK> mvo: There is.  It's our biggest usabiltiy problem in backports.
<ScottK> It's the reason that for many users places like getdeb are better for them than official backports even though the packages are technically inferior.
<mvo> right, I will cleanup/merge the branch soonish (hopefully early next week)
<pochu> dholbach: cool :)
<ScottK> mvo: Great.  I appreciate the effort.  We all do.
<hwilde> anybody happen to know how to supress this alarmist error from syslog   TCP: Treason uncloaked!
<StevenK> Fix the sender's TCP stack
<hwilde> hehe
<hwilde> note I said supress the error from syslog, not resolve the remote tcp window issue
<hwilde> it looks scary and gets people all excited for no reason...
<RainCT> mvo: Hey
<mvo> hey RainCT
<RainCT> mvo: what do you think about adding an option to apturl to enable PPAs? (ie, fetching the key et all)
<ScottK> RainCT: How about we add getdeb too?
<RainCT> ScottK: that's ironic?   (if not, that option should work for any archive, not only Launchpad PPAs)
<ScottK> RainCT: Yes it's ironic.  PPAs are not at all more trusted because they are hosted on Launchpad.
<ebroder> Does anyone know if Ubuntu's changes to xserver-xorg-video-ati are in a git repo anywhere? They don't seem to be in the repo in the Vcs-Git field
<ScottK> There's no reason they should be treated specially and lots of reason they should not.
<ebroder> (Or a not-git repo anywhere)
<ScottK> RainCT: I guess I don't understand the rationale for simplifying addition of untrusted repositories.
<RainCT> ScottK: So? Where's the difference between copying a line inside the box in System -> Administration -> Software Sources or clicking on a link and then on a confirmation dialogue explaining what adding a repo means (and that it can be dangerous)?
<RainCT> The later one is more convenient as it saves some clicks (especially those for the GPG key, which else many people may just leave out), but having to do those extra clicks won't stop anyone from adding repos
<ScottK> I can see a benifit from making it easier to get the gpg key as that gives assurance you're at least getting what you asked for.
<RainCT> Related to this, is there some reason why apt has it's own keys and doesn't use those which gpg has available?
<soren> Strictly speaking, I do think PPA's are more trusted because they're hosted on Launchpad. It's a trusted build environment, and if you're concerned you can go look at the source.
<pochu> RainCT: it runs as root and your own keys are in /home/me could be one of them
<RainCT> pochu: ah, of course :P
<soren> Other provideres of repositories could be putting backdooers or whatever into the binaries even if they publish the source.
<soren> s/backdooers/backdoors/
<ScottK> soren: It is a trusted build environment, but since anything can be in the source, unless you know and specifically trust the PPA owner the trust level is still none.
<soren> ScottK: You can go look at the source, if you please.
<ScottK> If you're going to audit the source before installing then it's more trusted.
<RainCT> ScottK: Yes, but having to do like 5 clicks more won't change the trust level someone has when he adds a repo.
<soren> That's the point. You're guaranteed to be able to do that.
<ScottK> I think the fraction of the user base that's relevant to is nil.
<RainCT> (Ah, and is there anything new about the "trusted PPAs" idea?)
<ScottK> RainCT: There is a spec for trusted third party repositories.
<soren> ScottK: I disagree.
<ScottK> soren: The source is of zero use to viritually all users.
<soren> ScottK: This is not a unique properrty of PPA's.
<ScottK> This is true, but in the distro archive we have certain processes in place to minize risk of something unfortunate ending up in the archive.
<ScottK> None of which there is any assurance exist for some random PPA.
<soren> ScottK: To me, it makes a big difference that if I had concerns of any kind, it's guaranteed that I can go look at the source.
<ScottK> soren: Sure, for you, but not for the average user.
<soren> I'm not talking about average users..
<soren> "PPAs are not at all more trusted because they are hosted on Launchpad." does not mention average useres.
<soren> It speaks in absolutes.
<soren> I don't like absolutes.
<soren> Usually.
<ScottK> The topic at hand is making it easier for end users to add PPAs, so that's the relevant audience.
<ScottK> For that audience, I think that source availability is irrelevant.
<Turl> hello
<Turl> what's the difference between cruft remover and "computer janitor" packages, if any?
<soren> ScottK: Again, that is not a unique feature for PPA's.
<soren> ScottK: and to the group of individuals where it makes a difference, it is a very signification difference.
<soren> "signification"?
<soren> I must be tired.
<Turl> cruft-remover=system-cleaner, computer janitor=computer-janitor(-gtk)
<soren> s/signification/significant/
<RainCT> ScottK: My point is that making it easier is not going to increase the number of people using PPAs (as if they want one they'll add it even if it requires a few clicks more), but it is going to improve their experience.
<ScottK> soren: I agree that for people who can make use of the source it's a significant difference.  A very significant difference.
<pochu> Turl: it's the same one, has been renamed
<Turl> pochu: ok, thanks :)
<Turl> pochu: btw, the new one doesn't have an icon
<ScottK> RainCT: Of course the easiest user experience would be to have a feature to enable all PPAs by default.
<ScottK> Now that's obviously not something we'd want to do.
<ScottK> And I think all the same reasons we don't want to do that, we don't want to make it easier.
<Mithrandir> sounds like we might want to have a way of signalling that some PPAs are more safe than others.
<Mithrandir> like, have the numbers of computers fetching from each of them publically visible, or something along those lines.
<ScottK> Personally, I'd place trust more in who has upload rights than how many people use it.
<pochu> for stable software, we should rather encourage people to use backports
<ScottK> I could see putting some kind of trust related seal on a PPA that only core-dev could upload to.
<ScottK> Yes
<Mithrandir> ScottK: by choice from the owner of the PPA or something then.  I'd rather not have my personal PPA marked as high quality, since I might end up putting junk there.
<ScottK> Agreed.
<Mithrandir> (given that I don't believe many/any other than I use it)
<ScottK> In Kubuntu we have a kubuntu-experimental PPA that we put all kinds of warnings all over.
<ScottK> It doesn't seem to stop anyone.
<pochu> ScottK: P3As for the rescue :P
<ScottK> That kind of limits your target audience and they're a pain to deal with with some of the usual tools.
<ScottK> We actually have one of those too for packaging new KDE releases where we get the tarballs pre-release.
<ScottK> soren: To get back to your question about absolutes, I think of trust as multiplicative in this case (for the average user) and so as soon as you have an untrusted uploader trust is 0 and it really doesn't matter what you multiply that by, it'll be 0.
<RainCT> Well, leaving apturl for now, is there some reason why Software Sources doesn't get the GPG keys itself (other than, because nobody has implemented this)?
<cody-somerville> pitti, ping
<pitti> cody-somerville: pong
<cody-somerville> pitti, Apologizes for the lack of communication on my behalf about the Xfce4 updates in -proposed that Michael prepared. We're looking to push the Xfce 4.4.3 bug fix point release to -updates for 8.10.
<ScottK> RainCT: You do want key adding to be manual because you don't want to automate the decision to trust a repo too much.  I agree though that it ought to be easy as we do want users to actually use the keys.
<calc> will we be putting up the release schedule for K anytime soon?
<RainCT> Uhm.. Perhaps just having a link to download a .key file on Launchpad
<RainCT> would be enough. Having to go to the keyserver, select the text and save it as a new file is quite annoying.
<ScottK> You don't actually have to do that.
 * ScottK tries to remember where he found the other way ...
<ScottK> Ah.
<ScottK> RainCT: https://help.launchpad.net/Packaging/PPA#Adding the keys in the terminal
<RainCT> ScottK: Yeah, I know. But, Ubuntu is GNU/Linux for human beings, remember? :P
<maxb> Bit overcomplicated. Just use: wget -O- 'http://keyserver.ubuntu.com:11371/pks/lookup?search=0xB0BE17C2A0C914F086B7B8327D2C7A23BF810CD5&op=get' | sudo apt-key add -
<ScottK> RainCT: Right, but in this case I think that's easier than the save a file approach.
<RainCT> ScottK: for us yes, but not for the average user
<ScottK> LP could generate a per PPA snippet like they do for sources.list and just say, copy/paste this is a terminal.
<RainCT> (The snippet it gives currently can also be pasted into Software Sources)
<mvo> RainCT: sorry, I was disctracted. the problem with adding ppas easily is that it opens the door for all sorts of spyware/malware potentially
<cjwatson> RainCT: why it doesn't get the GPG keys> also that PPAs have only been signed for roughly five minutes, I would expect ;-)
<RainCT> heh
<cjwatson> but I agree with others, "is a PPA" is a ridiculously low bar for anything
<cjwatson> I do think we should add an easier *command-line* way to add a key
<cjwatson> apt-key recv KEYID or something
<cjwatson> actually, can't apt-key adv do that?
<cjwatson> aha, yes it can. We should simplify the PPA instructions
<cjwatson> $ sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 8C6C1EFD
<cody-somerville> What about adding a dialogue to software properties to make that easy?
<cjwatson> scroll up
<cjwatson> circular arguments get tiresome :)
<ogra> but round :)
<slangasek> a circular argument gathers no code
<cjwatson> mrevell told me he's going to update help.launchpad.net for that, since we apparently have a bit of parallel invention with cprov
<soren> I like circular arguments. They lack loose ends.
<pochu> what about circular footnotes?
<ScottK> If the desk isn't level they'll roll off on the floor
<bluefoxicy> bluefox@icebox:~/tmp$ killall -9 gtk-gnash
<bluefoxicy> bluefox@icebox:~/tmp$ ps -e|grep gnash|grep defunct|wc -l
<bluefoxicy> 46
<bluefoxicy> :|
<maxb> bluefoxicy: A defunct process is not actually running
<bluefoxicy> maxb: I killed firefox because it wasn't actually painting the window anymore.
<bluefoxicy> it killed all the defunct gnashes
<maxb> It's one which has quit, but metadata concerning it is still occupying its PID, etc.
<bluefoxicy> there's always a billion gtk-gnash processes running
<maxb> The metadata disappears once the parent process acknowledges it
<maxb> Or the parent process disappears, in which case the defunct processes get reparented on init, which acknowledges them
<maxb> Hence why they disappear when you close firefox
<Notch-1> excuse me, my cdrom drive it's gone, but i have ubuntu already installed on hda, how can i install ubuntu on hdb? (using the iso image and ubuquity, i suppose...)
<jpds> Notch-1: Make a bootable USB with System -> Admin -> Boot USB?
<jpds> And #ubuntu might be a better place to ask.
<Notch-1> yes, is there another way? i'm running out of pendrive :P
<Notch-1> nobody answer on #ubuntu...
<jdong> well it is a difficult question you posed with your set of restrictions
<Notch-1> i know :P
<jdong> sure there are ways, but fairly troublesome when you neither want to use a CD installer nor a bootable USB medium.
<jdong> I'd honestly suggest copying your current installation to that drive
<jpds> Notch-1: https://help.ubuntu.com/community/Installation
<Notch-1> ah fine, i saw ubiquity in the repository and so i was thinking if it's possibile to use it with an iso image...
<jdong> there no readily available way of doing so, though of course I won't say it's impossible.
<jdong> it's probably just faster to obtain the materials necessary for a supported installation method listed above.
<Notch-1> i see, this list it's pretty complete...
<Notch-1> i think i should copy the iso to a partition and then boot from it, thanks
<maxb> hrm, not sure whether that's doable
<maxb> The usb-creator method seems like the only reasonable supported method in this case
<Notch-1> why not? anyway i hate usb-creator and i have no pendrive :D
<Notch-1> https://help.ubuntu.com/community/Installation/FromLinux
<Alinux> cjwatson, hello, I've tested latest alpha 4 alternate version x64. As installation language I choose Georgian, but installer did not change, the strings remains in English. Should I file a bug against debian-installer ?
<emgent> NEWS: Utu is back online, until it is integrated into ubuntustats. (http://thc.emgent.org/utu/)
<rbrunhuber> I'm a bit worried now:  I just had an kernel oops and tried to report the problem with apport but it tells me my kernel is not a genuine ubuntu package?!
<rbrunhuber> Is my setup compromised or is this due to not booting the latest kernel?
<taggart> kees, doku, etc: do you know if intrepid's glibc has additional malloc safety testing above what lenny/sid do?
<taggart> someone reported this debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514028
<ubottu> Debian bug 514028 in arrayprobe "arrayprobe: Crash due to memory corruption" [Grave,Open]
<taggart> note they are using a intrepid libc6
<taggart> I can't repeat it on lenny/sid, although it is a bug
<taggart> so thus my question
<mib_p137wmoa> hi all...  i only have 1 question... if someone can help me on this...
<jpds> !ask | mib_p137wmoa
<ubottu> mib_p137wmoa: 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. :-)
<mib_p137wmoa> ops ok
<mib_p137wmoa> where is the page, email or other thing where i can make a sugestion to ubuntu?
<mib_p137wmoa> oh, and sorry for bad english... i live in portugal
<jpds> mib_p137wmoa: brainstorm.ubuntu.com
<mib_p137wmoa> thanks ;)
<kees> `
<kees> taggart: I'm not aware of anything extra wrt glibc malloc protections above what is in lenny.
<kees> taggart: we do compile with -D_FORTIFY_SOURCE=2, so that may be enabling extra stuff in that region that I'm presently unaware of.  what're you seeing?
<fta> TheMuso, dtchen; just tested your new p-a, it doesn't work.
<fta> TheMuso, the daemon doesn't start. manually, i get: http://paste.ubuntu.com/114972/
<taggart> kees: the output is in Debian bug 514028
<ubottu> Debian bug 514028 in arrayprobe "arrayprobe: Crash due to memory corruption" [Grave,Open] http://bugs.debian.org/514028
<taggart> dammit I was trying avoid that, what does ubottu trigger on?
<Hobbsee> bug foo
<Hobbsee> or <bugtracker> bug foo
#ubuntu-devel 2009-02-07
<YokoZar> Will Jaunty have GCC 4.4 as a sidepackage?  It's too late to use it as our default I assume
<ScottK> We've always got gcc-snapshot, so yet.
<ScottK> yet/yes.
<shawnmstout> im hoping someone could answer a question for me if u dont mind
<shawnmstout> has anyone here tried ubuntu media center?
<shawnmstout> if so , is it any good
 * ScottK decides to wait until after the source gets published to ask for a backport...
<ScottK> If there's an archive-admin who could do a quick updated backport so we can stop breaking non-english systems, please have a look at Bug #325221
<ubottu> Launchpad bug 325221 in intrepid-backports "Brasero 0.9.1 breaking non-English systems" [High,In progress] https://launchpad.net/bugs/325221
<Hobbsee> scizzo-: you can't do it?
<Hobbsee> er, ScottK
<Hobbsee> hm, it's done
<TheMuso> 1/c
<calc> how do you extract a tar telling it to not use the top level dir in the tar file?
 * calc couldn't seem to find the arg to do that
<TheMuso> calc: I didn't even know you could do that.
<calc> hmm ok maybe this rpm build is working differently than i thought then
<calc> hmm i'm pretty sure they did it somehow with rpm automatically :\
<calc> easy way out... i think i don't need this part of OOo split build at all since its just a bunch of 3rd party library crap
<calc>  :)
<calc> if so that removes 300MB gzip of source from the archive once i switch to it
<dklon> I'm not sure if I am in the right channel, but I have a small game I'd like to contribute to Ubuntu and its derivatives and wasn't sure if this was the place
<maxb> #ubuntu-motu is the channel you're looking for
<maxb> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<jpds> maxb: He left, but I got him in /msg.
<maxb> oops,
<maxb> I really need to learn to check, now that I'm ignoring joins/parts/quits
<ScottK> Hobbsee: I didn't think I could. I need to look at that then.
<maxb> calc: dpkg-source resorts to unpacking into a temporary directory, asserting that the tempdir now contains a single directory, and then renaming that to the final name.
<sladen> shove it in a heap under the bed.  It's worth more and attracts less tax
<sladen> oops, wrong channel
<ogra> but still a good advice :)
<cjwatson> ScottK: done
<ScottK> cjwatson: Thank you.
<saulus> since my x-server upgrade yesterday I cant use gnome/kde/xmonad any longer. Is there a solution available?
<saulus> this is on ubuntu-jaunty - I hope this is the right place
<ScottK> saulus: Jaunty help is #ubuntu+1
<saulus> ty
<twoheadedboy> I had a question...if I was to install alpha 4, would I be able to upgrade to Alpha 5, etc., through Adept or Synaptic?
<etech> hi
<etech> source of go-openoffice 3.0.1 is out
<etech> will  go-oo 3.0.1 be in intrepid backports?
<etech> hello?
<ScottK> etech: It has to be requested and tested.
<ScottK> !backports > etech
<ubottu> etech, please see my private message
<etech> are there plans to put openoffice 3.0.1 in backprts?
<etech> because when yes i won't add the ppa repositories
<etech> ScottK, for openoffice 3
<s0u][ight> hello i'm trying to modify ubuntu
<s0u][ight> sudo mount -t squashfs -o loop mnt/casper/filesystem.squashfs squashfs this command fails
<s0u][ight> mount: unknown filesystem type 'squashfs'
<calc> http://news.cnet.com/8301-13505_3-10159100-16.html <- nice :)
#ubuntu-devel 2009-02-08
<ScottK> If there's a buildd admin around that could have a look at https://launchpad.net/ubuntu/+source/brasero/0.9.1-0ubuntu3~intrepid1 - The binaries have been stuck at 'accepted' for almost half a day now, so I think the system has done what it is going to do.
<constantine> hey I'm new to ubuntu, where can I find out what gnome is and why I keep seeing it mentioned
 * DBO pokes calc 
<cjwatson> ScottK: the publisher's crashing again - similar symptom to a while back
<cjwatson> pitti: ^- I thought we fixed the broken pkgstriptranslations that was causing that?
<cjwatson> pitti: (glib2.0_*_i386.translations.tar.gz being invalid due IIRC to multiple pkgstriptranslations running at once, if you remember
<cjwatson> )
<apw> where are bugs in the alternative installer reported?
<ogra> apw, launchpad :P
<ogra> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+filebug ;)
<apw> so the image contents is debian-installer too, cool
<calc> how do i turn ctrl-alt-backspace back on?
<calc> gnome just froze up on me and using sysrq-k let the video in a weird state that c-a-b doesn't cause
<calc> so sysrq-k is definitely not a good solution if you need access to your console ever again (before rebooting)
<calc> bryce: ping? ^ :)
<tjaalton> man xorg.conf
<calc> aiui there is a command line tool that does it automagically
 * calc knows it is called DontZap
<ogra> apt-get install dontzap
<calc> ah the command is called that too, ok
<ogra> sudo dontzap -d is the command you want iirc
<calc> ok
<calc> i was thinking use of c-a-b was a bit uncommon myself, until gnome just completely died on me, heh
 * calc rebooting to get his console back working
<ogra> tjaalton, even with the vblank .drirc fix my i965 is darn slow ... i just switched on Legacy3D which makes it nearly usable though
<ogra> seems forcing XAA doesnt work anymore even though its mentioned in the intel manpage
<calc> i just disabled compiz to work around the extremely slow intel driver :-\
 * calc imagines dontzap will be added to automatix or whatever it is being called now
<directhex> http://www2.apebox.org/wordpress/wp-content/gallery/00-single/yay_for_evolution.png
<directhex> Â¬_Â¬
<calc> directhex: i'm guessing those numbers are wrong or you are really evil ;-)
<directhex> calc, the numbers are a smidge wrong
<calc> lol
<directhex> calc, always happens to me though - e.g. http://www2.apebox.org/wordpress/wp-content/gallery/00-single/gw001.jpg
<calc> heh
<ogra> directhex, send your computer back to math school ?
<directhex> ogra, even my first mobile phone did that - insisted i had space for 65534 text messages on my sim card
<ogra> well, evo isnt really written for mobile phones :P
 * ogra hides
<tjaalton> ogra: having it in ~/.drirc doesn't work, as mentioned on the bug
<ogra> tjaalton, bug 320813 ?
<ubottu> Launchpad bug 320813 in xserver-xorg-video-intel "[drm] compiz animations cause temporary freezes with vblank" [Unknown,Confirmed] https://launchpad.net/bugs/320813
<tjaalton> yes
<ogra> hmm, i did read it differently then :)
<Amaranth> calc: automatix is gone, unless you know someone else started working on it?
<directhex> Amaranth, isn't that a good thing?
<Amaranth> ;)
<ogra> directhex, depends whom you ask :)
 * ogra guesses arnieboy would disagree *g*
<ScottK> Actually I think they've morphed into something called ultimatix or some such, I don't recall.
<Nafallo> ScottK: sounds right to me
<ScottK> calc: If you want dontzap and a gui option to configure it, it's already done in Kubuntu ....
<ogra> ScottK, do you plan to keep it ? (it was removed from ubuntu again)
<ScottK> ogra: As far as I know we do.  All the controversy was about Gnome U/I.   AFAIK the KDE U/I is untirely uncontroversial.
<ogra> well, i thought for consistency between the desktops ...
<ScottK> I don't think KDE should remove choice from the user because Gnome thinks that's a good idea.
<ScottK> I think it's the same for Kubuntu/Ubuntu.
<ogra> gnome doesnt think anyting here, thats my point :)
<ScottK> Given the philosophical differences between the two DEs I think the current situation is entirely reasonable.
<ogra> it was an ubuntu decision, not a gnome one
<ScottK> I'm just saying I think the difference is consistent with the differences between the two.
<ogra> yup
<SupernalTriad> !ops | SupernalTriad
<ubottu> SupernalTriad, please see my private message
<SupernalTriad> ubuntu is the worst distro i've ever used
<SupernalTriad> where do i file a bug report
<ScottK> SupernalTriad: You probably should just switch to another one then.
<ScottK> SupernalTriad: https://bugs.launchpad.net/ubuntu/+filebug
<calc> ogra: heh yea KDE wasn't founded on taking away choice from users ;-)
<ogra> calc, ubuntu wasnt either :P
<calc> well actually that didn't start happening until gnome 2.0, but for 8yr+ now anyway
<calc> ogra: heh, aiui this was a upstream change that we just left as is :)
<ogra> right
<ScottK> It does seem to be in line with what Ubuntu is specifically intending these days though.
<ogra> i agree that its very annoying to not have zapping during development
<ScottK> I think the dontzap U/I is one example and I think the idea that taking away actions on notifications is somehow good is another.
<ogra> but i also agree that its not worth bothering my mother with a UI option in a stable released system
<calc> ScottK: there is a fine line between taking away choice and having sane defaults
 * calc is worried gnome doesn't know the difference
<calc> not in this particular instance but still
<calc> for the X case we should just get those bugs fixed, of course that is unlikely to happen IRL so i think disabling the feature was a bad idea
<ScottK> Dunno.  I'm still seriously confused about the idea that if clicking on a notification would do something that makes them worse.
<calc> there are so many things that can kill/hang X is why i think its not going to happen, heh
<ogra> you have all options you can want available in gconf ... since such options are really mostly advanced tasks using something like gconf editor and having a clean config UI otherwose is a very wise decision imho :)
<ogra> and the success of ubuntu over the last years somewhat proves that point right i think
<calc> ogra: sometimes... my pet gweather rant can't be fixed by using gconf
<ogra> thats a bug :)
<calc> ogra: upstream just completely removed the ability to select weather stations in it
<calc> ogra: but upstream closes it and refuses to do anything about it
<ScottK> ogra: No.  Upstream says it's a feature.
<calc> ScottK: exactly
<ogra> fork it !! :)
<calc> ogra: i would if i didn't already have accuweather in firefox
<calc> ogra: i might fork it anyway if i get annoyed enough, but it makes weather in gnome useless now
<ogra> works for me
<Mithrandir> it's been useless for ages in lots of places since the weather in the airport does not match the weather in the city.
<calc> ogra: the issue is that it only has one station (that you don't know which one) per 'city'
<ScottK> Ultimately I think Gnome is trying optimize itself for a certain class of user.  If you're in that class, then great.  If not, oh well.
<ogra> right, its only a guesstimate anyway
<Nafallo> Mithrandir: LCY seems to match where I live quite well... but I'm kind of an exception, living two stops away :-P
<ScottK> Time will tell if that fraction of the user base is larger or smaller.
<calc> places like houston happen to be very large say 16K sqkm
<calc> so only having one station that is on the other side of the city isn't very useful
<calc> Mithrandir: now its just useless for a much larger group of users
<ogra> ScottK, i assume its the majority, most users i know just want to use their computer and dont even know how to change the wallpaper (and dont attempt to)
 * calc really didn't intend to bring this rant back up again
<Mithrandir> Nafallo: OSL is about 50km away from where I live.. and I live in the somewhat-northern parts of Oslo.
<ogra> calc, just have more airports :P
<calc> there is a station about 10km away from my house and there is another one still in 'Houston' that is about 80km from my house
<Nafallo> Mithrandir: hence why the weather changes a lot more... ;-)
<Mithrandir> calc: that's a good thing, since it might be fixed then.
<calc> Mithrandir: nope he refused to do anything and just closed the bug wontfix
<Mithrandir> calc: what's your US zip code?
<calc> 77014
<Nafallo> Mithrandir: 1.6 miles from LCY with car ;-)
<ScottK> ogra: Perhaps.  Time will tell.  Sometimes I sit down to help my kids with stuff on their computer and my eyes bleed because of the way they've customized it.  They like the choice.
<ogra> right, i thin its also a matter of age
<ogra> *think
<calc> upstream wants to do some sort of position checking (gps?) to determine which to show the user without asking them
<Mithrandir> hmm, yr.no doesn't seem to do do US zip codes.
<ogra> many people using computers today still didnt grow up with using them on a daily base
<ScottK> ogra: There is that.  I actually don't customize my KDE desktop much at all.  I find the defaults quite sane and usable.  Gnome OTOH, just feels totally wrong to me.
<ScottK> Choice is a good thing.
<calc> of course that wouldn't work very well since users would want to see the weather at their summer home, etc
<ogra> if the generations switch it might totally change the numbers
<SupernalTriad> how do you know if you are catering to the least common denominator
<Mithrandir> ScottK: _can_ be a good thing.  Choice for choice's sake isn't.
<ScottK> Mithrandir: Certainly.
<calc> the main thing i change on my systems using gconf is focus under mouse
<calc> since gnome won't let you do that via the gui
<ogra> works for me
<ScottK> That's a GUI option in KDE4.
<Mithrandir> I've fixed that by using a real wm. :-P
<Mithrandir> (and it really annoys me when people say "gnome" when they mean "metacity")
<SupernalTriad> what do you do when you make things so simple to use that people never learn anything and never know how to fix something when your 'simplified system' breaks down
<Mithrandir> you make it so they don't break?
<SupernalTriad> you get 1500 users in your channel asking retarded questions
<calc> Mithrandir: i'm pretty sure it does the same with compiz as well
<SupernalTriad> Mithrandir, impossible with apt
<calc> Mithrandir: in any case the sys->pref->windows won't let you do it :)
<Mithrandir> calc: and?  I'm not using compiz, nor metacity.
<SupernalTriad> it tries to do too much so that it always breaks something eventually
<Mithrandir> SupernalTriad: you've yet to actually say what the problem is.
<ogra> calc, i can only re-state ... works for me
<SupernalTriad> Mithrandir, the problem is in creating a subset of linux that is not vanilla at all...where you are told that using anything but apt is a pita or will break stuff
<calc> ogra: yea i remember your system is weird, other people couldn't determine why yours works that way
<calc> ogra: the gconf description even says it shouldn't work the way it does for you :)
<ogra> SupernalTriad, my mother is quite happy with her ubuntu since two years ... and se surely doesnt know what apt is
<ogra> nor does she have any probs doing her daily tasks
<calc> Mithrandir: well those are the two 'gnome' wm's aiui anyway, so saying gnome isn't really a misnomer
<ScottK> SupernalTriad: Any distro will tell you that installing outside the distro packaging system is a risky thing that will break things.
<SupernalTriad> ogra, least common denominator...when something goes bad, what do they do
<Mithrandir> calc: sure it is.  That most distros default to compiz/metacity if you use gnome is just a historical artefact.  It used to be sawfish.
<SupernalTriad> ScottK, not true
<calc> SupernalTriad: install into /opt or /usr/local
<SupernalTriad> ScottK, almost true, and i see that as a major problem
<ogra> SupernalTriad, well, nothing went bad for her the last two years, but she has my phone nuber i think :)
<Mithrandir> SupernalTriad: no, apt is not a PITA.   Maybe you want to say what the actual problem you are running into is?
<calc> SupernalTriad: installing into /usr will break any *nix period
<SupernalTriad> calc, i admit i do ./configure, make. make install for years and years....into /usr/ and havent broken it
<ogra> calc, well, sloppy behaves identical to mouse for me ... but since it does what i wan i dont really care ;)
<Mithrandir> SupernalTriad: uhm, you think that apt should be magic and see that you've overwritten parts of /usr with locally compiled stuff?  First, that's not apt at all stumbling at that, secondly, I think that's a completely unreasonable requirement.
<cjwatson> if that works for you, that's fine. This is not relevant to #ubuntu-devel
<SupernalTriad> just bloated it a bit...too lazy to keep track of whats installed and uninstallers / self made packages
<directhex> calc, ?
<SupernalTriad> i dont use any package manager
<calc> SupernalTriad: you have been lucky then :)
<SupernalTriad> because they always got in my way
<SupernalTriad> i dont want to wait for some guy to tell me what version i can use
<Mithrandir> SupernalTriad: then you're not using ubuntu, so I don't see why you are complaining about it.
<SupernalTriad> i just grab the latest source
<calc> directhex: huh?
<directhex> calc, system, preferences, windows: "select windows when the mouse moves over them"
<SupernalTriad> how do you guys deal with it
<SupernalTriad> its so crippled
<SupernalTriad> it stifles you
<calc> directhex: sloppy, doesn't deselect window when you go to desktop
<directhex> stupid troll is trolling
<SupernalTriad> sure im trolling because you dont agree with me?
<SupernalTriad> when i say apt/* stifles your learning
<Mithrandir> SupernalTriad: that's irrelevant, you're completely off-topic for this channel.
<ogra> calc, i raraely see my desktop ;) so i cant confirm or deny
<calc> SupernalTriad: its equivalent to trying to install into C:\WINDOWS and hoping you don't blow up your machine, aiui microsoft actually keeps you from doing that now in some manner
<cjwatson> Ubuntu is fundamentally a package-managed distribution and this is not going to change. You're welcome to use another distribution or from-scratch instructions or whatever if you prefer that
<directhex> you're trolling because you're in #ubuntu-devel saying "man, isn't using a distro where the computer does the menial stuff for you so shitty"
<SupernalTriad> i do
<tjaalton> calc: focus-follows-mouse is configurable from the "windows" capplet
<SupernalTriad> directhex, it tells you what softwaer you can use too
<cjwatson> SupernalTriad: this is not relevant to #ubuntu-devel; please take the discussion elsewhere
<SupernalTriad> so if its not in the repo, you are fucked
<calc> tjaalton: but not focus-under-mouse, focus-follows-mouse is 'sloppy' and f-u-m is 'mouse'
<directhex> waa, 20k packages isn't enough :'(
<directhex> mummy, save me from the bad men who package things
<SupernalTriad> directhex, 10k outdated packages
<SupernalTriad> penis
<directhex> go go gadget cjwatson
<ogra> heh
<tjaalton> calc: huh, maybe I just don't know the difference then :)
<calc> tjaalton: apps/metacity/general/focus_mode is what i was referring to in gconf
<calc> tjaalton: focus under mouse or strict (whatver you want to call it) unfocus a window when you leave it regardless of if you moved to the desktop or another window
<directhex> calc, it's easier in gconf than in vista... gotta add some hex to a big long byte to get focus follows mouse
<tjaalton> calc: ah, ok
<calc> tjaalton: focus follows mouse 'sloppy' only changes focus when you go into another window
<Mithrandir> directhex: or just use powertools or whatever it's called those days, I presume.
<calc> directhex: yea or install xmouse (is that still available for vista?)
<directhex> Mithrandir, no official free one for vista
<tjaalton> yeah the key description clarified the difference
<calc> directhex: iirc powertoys from microsoft let you set that
<cjwatson> (probably a bit harsh to ban on first offence)
<directhex> Mithrandir, only paid 3rd party equivalents
<Mithrandir> cjwatson: /knockout in irssi is nice.
<ogra> cjwatson, he was banned in #ubuntu before
<calc> ah no tweakui for vista, ugh
<directhex> ogra, almost as if he's a troll?
<cjwatson> ogra: I rarely consider other channels in ban decisions here
<directhex> calc, good innit
<ogra> he just came here to go on ranting
<cjwatson> Mithrandir: nice
 * calc needs to summon pmladek from suse to fix OOo split build, heh
<calc> i'm getting obscure error messages using it :\
<directhex> i wonder if he'll reappear in #ubuntu-motu
<IntuitiveNipple> Do we have anywhere, a specification or policy on what block-device/file-system combinations are supposed to be supported by Ubiquity? For example partition > lvm, partition >encrypted > block, partition > encrypted > lvm, partition > lvm > encrypted
<calc> IntuitiveNipple: all of it? :)
<directhex> nbd!
<directhex> iscsi!
<ogra> nbd ftw !
<directhex> ooh, encryption on lvm on local AND iscsi disks
<directhex> that'd be awesome
<IntuitiveNipple> I'm trying figure out some 'bugs' in relation to these combinations, especially when cryptsetup is involved,  right now
<IntuitiveNipple> I've fixed cryptsetup to cope with partition > lvm > encrypted > block
<cjwatson> IntuitiveNipple: none of LVM, RAID, or encryption are supported by Ubiquity right now, only by d-i
<IntuitiveNipple> And Ubiquity can run with that *if* lvm2 and cryptsetup have been added
<IntuitiveNipple> cjwatson: Okay, well I was using "ubiquity" as the umbrella
<cjwatson> IntuitiveNipple: we would like to fix this in the future but currently are unlikely to entertain bug reports on attempts to hack it up, since it's known to be unsupported
<cjwatson> IntuitiveNipple: don't do that :)
<cjwatson> if you say ubiquity, we will all interpret you as meaning specifically the desktop installer
<calc> ah yea i got confused between the alternate and desktop cds
<cjwatson> IntuitiveNipple: all the rest should be supported but it's entirely possible that there are problems with certain combinations
<cjwatson> IntuitiveNipple: there was a bug in gutsy/hardy/intrepid regarding /etc/crypttab generation that will certainly have broken some cases; that much is fixed in jaunty
<cjwatson> but otherwise detailed bug reports with full explanations and logs will help us figure it out
<IntuitiveNipple> cjwatson: Yeah, I've posted some patches
<cjwatson> IntuitiveNipple: with regard to your complaints over the last week or two about devices disappearing in ubiquity (you kept leaving before I could answer ...), I expect that this is due to the known problem that update-dev calls udevadm trigger
<IntuitiveNipple> cjwatson: no... not a complaint, a confusion, and I found the solution and posted it to the bug report :)
<cjwatson> the "solution" that it should notify the user of the problem?
<cjwatson> that hardly seems like a real solution
<cjwatson> if parted is failing to understand the disk, that needs to be dealt with regardless
<cjwatson> and no, partman and cfdisk have no libraries in common above libc6
<cjwatson> IntuitiveNipple: I think what would help me is a dump of the raw contents of the partition table(s), that I could feed to parted locally to reproduce the problem
<IntuitiveNipple> bug #324987
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/324987/+text)
<calc> ah the bot is an example of why +text needs to continue to exist
<cjwatson> yeah, looking at it, absolutely no idea why you marked it invalid
<calc> at least until it is converted to the api
<IntuitiveNipple> cjwatson: I found it easy to recreate the issue: create the partition table with fdisk -u and start each partition on the next availabe sector number... in 'cyclinder' mode the end and next-start will be in the same cylinder... and that was the root cause
<IntuitiveNipple> cjwatson: I considered it "user error" - the missing partition entries... but I've left the "silently fails" bug #324976
<ubottu> Launchpad bug 324976 in ubiquity "Ubiquity silently fails during file-system preparation" [Undecided,New] https://launchpad.net/bugs/324976
<IntuitiveNipple> cjwatson: Unfortunately, because the partition offsets are reported by partman in absolute byte offsets (not sectors or cylinders) the reason wasn't showing up in the partman log
<cjwatson> I've reopened 324987
<cjwatson> IntuitiveNipple: for 324976, one time-saver for us would be if you could run ubiquity in debug mode ('ubiquity --debug' from the command line, or 'debug-ubiquity' added to kernel boot parameters on the live CD) and post logs including /var/log/installer/debug
<IntuitiveNipple> ok... I thought it'd get thrown out as a "won't fix" because it is a known issue with buggy fdisk
<IntuitiveNipple> cjwatson: I thought I did... maybe I just used them for my own debugging... I recall they didnt't help :)
<cjwatson> libparted should be raising an exception here, and it ought to come up as a debconf protocol message
<cjwatson> didn't help *you* ;-)
<IntuitiveNipple> cjwatson: I'll create a VM tomorrow with that scenario and capture the logs
<cjwatson> thanks
<cjwatson> it's presumably a real-world partitioning scenario that might arise in a variety of cases, and I consider failing to handle such to be bugs
<IntuitiveNipple> cjwatson: my head felt like I was wading through treacle trying to trace the execution flow!
<cjwatson> that's OK, the debug logs are for us not you :)
<cjwatson> (primarily, anyway ...)
<cjwatson> yes, it is difficult to trace at times
<cjwatson> certainly I see that parted_server has crashed in your log, which probably invokes undefined behaviour in ubiquity
<IntuitiveNipple> cjwatson: That's great... your response is gratifying especially after a patch I posted to fix a bug in pbuilder was rejected by the debian developer as an intended feature, not a bug... that causes pdebuilder to fail when building older releases :)
<cjwatson> parted_server: exception_handler: Bad option: ""
<cjwatson> that's odd ...
<cjwatson> oh, meh, the partman-commit component in ubiquity doesn't catch partman/exception_handler
<IntuitiveNipple> Is that the cause of the silent failure?
<cjwatson> I would guess so
<IntuitiveNipple> cjwatson: you're star! I'm glad someone has their head around that spaghetti code :D
<cjwatson> wouldn't mind verification after we upload my change, mind you
<IntuitiveNipple> If the package update is in the archive tomorrow I'll fetch it before running the test in the VM
<IntuitiveNipple> If there's a diff in the bug report I can appy that directly
<cjwatson> IntuitiveNipple: I wasn't planning an upload just yet, but how about http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/2999 if you're willing to give that a go?
<cjwatson> http://bazaar.launchpad.net/%7Eubuntu-installer/ubiquity/trunk/diff/2999 might be easier to deal with
<IntuitiveNipple> I'm guessing the change is in a python file or shell script ?
<cjwatson> yes, /usr/lib/ubiquity/ubiquity/components/partman_commit.py
<IntuitiveNipple> okay... that's easy to apply then
<IntuitiveNipple> the server is down atm so I can't look at the launchpad diff
<cjwatson> IntuitiveNipple: I've attached the diff to the bug
<cjwatson> not that this will necessarily make the failure *informative* ...
<cjwatson> you'll just get "Error informing the kernel about modifications to partition /dev/sda5 -- Device or resource busy.  This means Linux won't know about any changes you made to /dev/sda5 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
<cjwatson> " with "Ignore" and "Cancel" or some such
<IntuitiveNipple> that's better than the silent failure :)
<cjwatson> I'm still not seeing any sign of any other libparted exception, which is extremely weird
<cjwatson> and leads me back to my earlier udevadm trigger hypothesis
<IntuitiveNipple> quick question on a slightly different topic - in the initrd, when custom crypto scripts are run, which shell hosts them?
<IntuitiveNipple> I was testing some modifications to my crypto script that works in Hardy and Intrepid, and it throws some errors relating to not finding busybox... weird.
<cjwatson> IntuitiveNipple: if you fancy doing another test after the partman_commit one, try deleting the "udevadm trigger" line from /bin/update-dev
<cjwatson> IntuitiveNipple: shell> busybox sh (busybox/shell/ash.c)
<IntuitiveNipple> okay, will try that... with VMs its easy and quick.
<cjwatson> in the initramfs you must confine yourself to utilities available in busybox
<IntuitiveNipple> cjwatson: Yes, it is. failing for use of 'basename'
<IntuitiveNipple> I'll pin it down anyhow. My head is turning to mush right now I'm juggling too many inter-related issues
<cjwatson> IntuitiveNipple: "$(basename "$x")"  ->  "{x##*/}"
<cjwatson> where "x" must be a shell variable name
<IntuitiveNipple> yeah... I need to reproduce it... it was, I think, caused by being passed a weird path from /sys/ in its hunt for USB devices
<IntuitiveNipple> I've replaced it anyhow... I discovered that vol_id is hidden in /lib/udev/ :)
<IntuitiveNipple> All the script wants to do is identify likely USB memory devices
<cjwatson> that said, basename *is* available in jaunty's busybox
<IntuitiveNipple> Yes, at the prompt I used it. never mind, the vol_id discovery negated the need for it
<IntuitiveNipple> How to kill a system: type . instead of , in /etc/crypttab entries that get copied to initrd!
<Riddell> calc: you pinged the other day?
<calc> Riddell: yea, it looks like mandriva still depends on kdelibs even though they have --disable-kde set, so i emailed to find out the status, haven't heard back from them yet
<Riddell> calc: ok, thanks, it's entirely possible the Mandriva openoffice guy hasn't done what Helio said he had done :)
<calc> ok
<calc> Riddell: they appear to be using ooo-build so if it actually works it shouldn't be too hard to get it for ubuntu
<slangasek> superm1: no mythbuntu alpha-4 test results reported yet?
<ogra> slangasek, how long do i have to get armel versatile netinstall in before its to late =
<ogra> ?
<calc> anyone happen to have a linksys WRT610N?
<slangasek> ogra: too late for what?
<ogra> slangasek, to get a delayed alpha4 :)
<slangasek> ogra: hmm.  By this point there will be significant package skew relative to the other alpha-4 images - I would suggest focusing on alpha-5 at this point?  Or do you need an alpha published so that you can have others do more install testing?
<ogra> it worked fine with the previous netboot d-i, but i didnt test the actual final one
<ogra> slangasek, well, its netboot anyway, there is no guarantee for package consistency anyway for that i assume
<slangasek> ogra: oh, netboot rather than netinst; then we don't actually copy those anywhere that we mark them 'alpha', anyway.
<ogra> ah, k
<slangasek> (I guess I should've known you meant netboot, since Ubuntu doesn't have 'netinst' images like Debian :)
<ogra> err, no i meant netinst
<ogra> but there is no difference, the d-i blob is the same
<ogra> at least for qemu :)
<ogra> qemu actually boots the kernel and initramfs directly (no tftp/dhcp needed here) but the d-i starting then is indeed pretty much identical to netinst
<ogra> and since arm cant boot isos thats the only way for me to test
<slangasek> er, please don't use the term "netinst" - that refers to a specific class of Debian CD images
<slangasek> I'm pretty sure that's not what you have here
<slangasek> you have "local netboot" or something :)
<ogra> hmm, i always thought netinst is just netboot/install d-i components rolled into an iso
<ogra> but then it was woody when i used one last :)
 * ogra grumbles about nslu2 ... 
<Adri2000> does anyone know what's the plan for samba in jaunty? has the server team already decided something? (slangasek?)
<scientes> i cant figure out what module i need to build to active this one little change i made
<scientes> i edited drivers/hid/hid-input.c to change the behavior of apple keyboard
<scientes> but in my modules folder there is no hid-input.ko only hid.ko and then the usb folder
<Keybuk> did you check the Makefile?
<Adri2000> hi Keybuk!
<Keybuk> hi
<Adri2000> did you speak with kees about my latest changes to the comments patch?
<scientes> sweet it worked
<scientes> awesome
<scientes> good i had a ps/2 keyboard
<maxb> ooi, what's the latest on the crashing publisher?
<scientes> static int hid_apple_fnmode = 2; should be the default
<IntuitiveNipple> Is there a way to 'tell' the live-CD not to eject the CD when restarting?
<Keybuk> Adri2000: I didn't know there was any further changes?
<Keybuk> you should speak to kees directly about them
<ogra> [42950525.820000] NOHZ: local_softirq_pending 100
<ogra> Finding valid ramdisk creators.
<ogra> Using mkinitramfs-kpkg to build the ramdisk.
 * ogra scratches head ...
<Adri2000> kees: see ^. looks like Scott isn't aware of the changes and your review
<ogra> shouldnt update-initramfs be used by default if its installed ?
<ogra> hmm, apparently not in debian armel kernels
<calc> what is 'R' state for a process?
<calc> a webpage wedged firefox into that
<calc> and it seems to be non-killable
<slangasek>        R    Running or runnable (on run queue)
<slangasek> ps(1)
<calc> so it should be killable then right?
<slangasek> normally, yes
<calc> is there a i really mean die argument to pass kill?
<ogra> -9
<calc> ogra: hmm yea that doesn't work
<slangasek> check dmesg
<slangasek> because -9 is "don't ask the process for permission, just obliterate it at the kernel level"
<ogra> what process is it btw ?
<ogra> geez, generating ssh keys on a nslug takes 20min
<calc> shortly after it locked up hard
<calc> sak didn't even kill X
<calc> i had to sysrq sub to reboot
<calc> i'll see if i have anything in logs
<calc> interesting
<calc> Feb  8 09:11:04 laptop-c2d kernel: [ 1511.744906] npviewer.bin[5890]: segfault at 6c2f6b6e ip 000000006c2f6b6e sp 00000000ff9a709c error 14
<calc> then a dump
<calc> Feb  8 14:19:15 laptop-c2d kernel: [20002.740004] BUG: soft lockup - CPU#0 stuck for 61s! [firefox:12682]
<slangasek> that's all?
<calc> full call trace as well
<slangasek> oh, 'soft lockup'
<calc> wtf is that?
<slangasek> that's a non-diagnostic error message (it can have any number of causes), but it pretty much explains why you couldn't kill the process
<calc> ok
<slangasek> any chance that firefox itself died with a SEGV, and apport tried to catch it
<slangasek> ?
<calc> i didn't see apport doing anything visible
<calc> i tried kill -9 a few times on firefox
<calc> then tried to run another program and it locked too
<calc> couldn't switch to a vt, and sysrq k failed, so i just did a sysrq sub to get back
<Blacksun> Nabend an alle
<Blacksun> Ich hÃ¤tte mal ne frage zu ner phyton Datei, und zwar wollte ich abc torrent installieren, doch irgend wie bekomme ich das nicht hin hab schn mit abc.py probiert geht aber nicht
<Blacksun> hat jamand neine lÃ¶sung wie sowas zu installieren ist ?
<Tm_T> Blacksun: olen samaa mieltÃ¤
 * ogra grins ...
<ogra> Blacksun, normalerweise spricht man hier nur englisch ;)
<Tm_T> Blacksun: det Ã¤r rolight
<Tm_T> ogra: in how many languages you like me to comment on this ?
 * ogra guesses Blacksun wanted to go to #ubuntu-de instead ;)
<Blacksun> hups da hab ich mich im raum vertan
<ogra> Tm_T, try one that has no vowels ;)
<Tm_T> bah, too late
<ogra> so, why cant i login with normal users to a freshly bootstrapped system ... i get motd, no error message and get dropped back to the login prompt immediately
<ogra> and apparently it doesnt seem to matter if i'm on a serial console or try a ssh session
<cjwatson> ogra: "netinst" specifically refers to Debian CD images that include d-i and the Debian base system - as slangasek says, we have no such images in Ubuntu
<ogra> no indication in auth.log
<ogra> i can create brandnew users as well ... same behavior
<ogra> cjwatson, ah, right, i forgot about the base system ... i was thinking i remembered its just all the udebs in one iso
<cjwatson> that's called "businesscard" in Debian
<ogra> ah, right ... :)
<ogra> removing the rootpw from /etc/passwd gets me in as root on the serial console though
<ogra> homedir permissions seem ok ... filesystem isnt full, disks are mounted rw ... i really start to run ut of ideas
<ogra> *out
<Adri2000> slangasek: do you know what's the status of samba in jaunty?
<Renfield> Where can I get the md5sum for the mini.iso images?
<cjwatson> I don't think we publish it anywhere that comes to mind
<cjwatson> you could use rsync to make sure you have a good coppy
<cjwatson> copy
<ogra> root@nslu2:/home/ogra# sudo -i -u ogra
<ogra> Killed
<ogra> mumble
<ion_> Ouch
<ogra> yeah, i dont get what it is
<ion_> strace?
<ajmitch> process limits?
<Renfield> cjwatson: How would I do that?
<Mithrandir> Renfield: rsync -c
<Renfield> To what host/directory?
<ogra> ion_, ...
<ogra> rt_sigaction(SIGTSTP, {SIG_DFL}, NULL, 8) = 0
<ogra> execve("/bin/bash", ["-bash"], [/* 15 vars */]) = -1 EACCES (Permission denied)
<ogra> very intresting
<ion_> Huh. :-)
<ogra> root@nslu2:/home/ogra# ls -l /bin/bash
<ogra> -rwxr-xr-x 1 root root 695904 2009-02-08 20:02 /bin/bash
<ogra> heh
<ogra> all fine int seems
<ogra> *it
<Mithrandir> Renfield: rsync -cavP archive.ubuntu.com::ubuntu/dists/jaunty/main/installer-amd64/current/images/netboot/mini.iso mini.iso
 * ogra starts to get the feeling he hunts phantoms
<ogra> hmm, identical result with dash
<Renfield> Oh, great, that just overwrote my mini.iso, not verify that it is correct.
<Renfield> I'm not trying to install jaunty. I'm trying to install 8.10.
<eut> lol :/
<Renfield> I guess I'm just going to have to give up on Ubuntu. It just will not install.
<Mithrandir> Renfield: well, you need to adjust the path for your distro and arch.  I thought I wrote that, but apparently I didn't.
<Renfield> No big deal. I can find the one I am using. I am just so frustrated at this point with the whole thing.
<eut> yeah i know what you mean
<cjwatson> Renfield: a corrupted mini.iso is far from the only possibility where installation failures are concerned. What are the symptoms?
<cjwatson> eut: you too, if you have problems
<Renfield> cjwatson: I get errors during the "install base system".
<Renfield> It fails to download various packages.
<alex-weej> Amaranth: you still do compiz work?
<cjwatson> Renfield: that's very unlikely to be a problem with the mini.iso then; if it were, you wouldn't have got that far
<cjwatson> Renfield: perhaps you could put the full syslog on paste.ubuntu.com or similar (or file a bug report); you can extract the log using "save debug logs" from the installer main menu
<Renfield> Ok, I'll do that after it errors out.
<alex-weej> can someone explain to me how to get a fix sponsored?
<alex-weej> i've opened a bug
<alex-weej> and i know the code change
<alex-weej> i just have no idea how to make it so that a main developer can just go "yep, that's ok", click a button and have it in main
<alex-weej> apparently it's possible
<cjwatson> alex-weej: subscribe ubuntu-main-sponsors or ubuntu-universe-sponsors depending on the package
<cjwatson> it will be taken care of from there
<alex-weej> cjwatson: but what do i need to upload?
<cjwatson> patch
<alex-weej> what kind of patch?
<cjwatson> unified diff
<alex-weej> ah, someone's pointed me to https://wiki.ubuntu.com/SponsorshipProcess
<alex-weej> cjwatson: is this integrated with PPA somehow?
<cjwatson> no
<alex-weej> aww
<cjwatson> it might be nice if it were, but really all any competent developer needs is a unified diff
<cjwatson> you will see some stuff about debdiffs and what-have-you but that is gravy
<cjwatson> if the package is in bzr then you can create a branch from it and submit a merge request
<directhex> mmm gravy
 * directhex hands cjwatson a mug of bovril
<cjwatson> then the sponsor-side process is 'bzr merge lp:~user/package/branchname'
<cjwatson> (oh and resolve conflicts, bzr commit etc.)
<alex-weej> basically i want people to be able to use and test my package easily
<alex-weej> so i need to have it in my PPA
<cjwatson> you are entirely welcome to put it in a PPA as well
<cjwatson> it is not essential to the sponsoring process
<alex-weej> ok, just saying it is kind of useful in case you had any leverage over the design of it all :P
<alex-weej> it would be cool if the debdiff i upload could just automatically create packages
<alex-weej> for testing
<cjwatson> integrating PPAs better for review purposes is actually already on our long-term roadmap
<lfaraone> Hi, I had an idea: would a file handler for RPMs that automagically alienates them into a deb and hands off the job to gdebi (with a gui "converting to Deb" page) be useful for jaunty+1?
<alex-weej> lfaraone: the fact that any RPMs work at all is just luck. not all linuxes are equal.
<cjwatson> we'd like it to be something like: (1) commit to personal bzr branch (2) hit button to build package from that in PPA (3) submit merge request which includes a reference to said PPA
<lfaraone> alex-weej: Of course.
<lfaraone> alex-weej: But LSB packages at least should work, right?
<directhex> lfaraone, i'd call that actively harmful, personally
<lfaraone> directhex: Why's that?
<alex-weej> because they're never designed for ubuntu
<alex-weej> if they were, they'd be Deb format
<directhex> lfaraone, because people would use it by & large for completely incompatible packages which would serve only to break things
<directhex> lfaraone, if it goes into /usr, it should be for ubuntu. perhaps for debian at a push.
<lfaraone> directhex: The user will install the RPM whether there's a GUI or not, they'll just call up their "linux geek friend" to run alien from the command line.
<lfaraone> directhex: We _should_ be at least supporting LSB packages.
<calc> are we back to the same crap as earlier today?
<calc> are LSB packages allowed to write somewhere other than /opt ?
<calc> if so that should be a bug
<directhex> lfaraone, if you can identify LSB ones, then fine. but every report i get from people trying to run suse mono on ubuntu, i'll hand them your mail address
<calc> 3rd party stuff according to FHS (unless it changed) is only allowed to write into /opt
<lfaraone> directhex: Please do. I use filters. :)
<Renfield> cjwatson: http://paste.ubuntu.com/115796/
 * cjwatson scratches his head at that log
<cjwatson> Feb  8 21:47:51 debootstrap: Setting up libldap-2.4-2 (2.4.11-0ubuntu6) ...
<cjwatson> Feb  8 22:37:42 debootstrap:  libcurl3-gnutls depends on libldap-2.4-2 (>= 2.4.7); however:
<cjwatson> Feb  8 22:37:42 debootstrap:   Package libldap-2.4-2 is not installed.
<Renfield> I don't know what is going on.
<cjwatson> oh, you restarted base system installation, that explains the confusion there
<Renfield> I restarted a couple of times.
<Renfield> But I only did that each time after wiping the hard drive. So, I expected that it would be smart enough to start cleanly.
<Renfield> By wiping, I mean I went back to partion, and let it reformat.
<lfaraone> directhex: But honestly, how many suse mono bugs do you get like that?
<cjwatson> didn't actually wipe it from the looks of things, but anyway, that's really just a side issue
<directhex> lfaraone, on irc? a few people asking about alien for that specific purpose. they're told where to shove it
<cjwatson> Renfield: oh, actually it's not a side issue at all, you appear to have been given an explicit warning by the installer the second and subsequent times you ran base system installation to the effect that you were trying to install to an unclean partition and that this was liable to break
<lfaraone> directhex: doesn't apport know not to reportbugs on alienated packages?
<cjwatson> Renfield: I'm not sure why the *first* run failed, though
<cjwatson> Feb  8 21:26:14 debootstrap: Setting up base-files (4.0.4ubuntu2) ...
<cjwatson> Feb  8 21:26:14 debootstrap: chown:
<cjwatson> Feb  8 21:26:14 debootstrap: invalid user: `root:root'
<Renfield> cjwatson: Yes, it did say that. I then canceled the action, then went to the partition section and reran that part.
<cjwatson> Renfield: apparently unsuccessfully
<Renfield> I can just reboot and do this all over again.
<cjwatson> Renfield: might be more reliable to reboot and go through it again ... yes, what you said
<Renfield> This is the second reboot already.
<Renfield> Ok.
<cjwatson> none of this affected the first run that gave the chown error above, though
<Renfield> Ok, this time I am not going to add any additional installer components to the list and see if that changes anything.
<Renfield> Previously, I was adding SSH client/server.
<cjwatson> Renfield: I note that the installer seems to have had some trouble retrieving its own components over the network
<cjwatson> Jan  2 05:04:18 anna[6157]: DEBUG: retrieving partman-ext3 52ubuntu3
<cjwatson> Jan  2 05:07:27 anna[6157]: wget: cannot connect to remote host (91.189.88.31): Connection timed out
<cjwatson> that sort of thing
<cjwatson> also:
<cjwatson> Jan  2 04:40:03 net-retriever: gpgv: key 437D05B5 was created 85069852 seconds in the future (time warp or clock problem)
<cjwatson> maybe some kind of clock problem affecting things?
<Renfield> Hmmm.
<Renfield> I wonder.
<Renfield> I configured it to use my own ntp server. Maybe it didn't work, but neglected to tell me that it didn't work.
<Renfield> This time when I get to setting the clock, I will use the defaults.
<cjwatson> none of the explanations above are really satisfying to me, but they're the best I can do on a Sunday evening :-/
<Renfield> Oh, when is the best time to get you? :)
<cjwatson> European working hours
<Renfield> Ah, still bombs.
<Renfield> Warning: Couldn't download package debianutils
 * calc thinks he found the current issue with his split build, need to learn to read rpm spec files better ;-)
 * calc begins to realize how hacky the split build still is :-\
<directhex> calc, split build? you don't enjoy 10 hours taken to test 1-line patches?
<calc> directhex: heh
<calc> directhex: well testing patches part won't be helped at least with the early rev of split build
<calc> at least i don't think it will be that much
<calc> we really need Sun to do the split properly for everything
<calc> i'm here to get them to at least split languages properly
<calc> here being in Hamburg
<slangasek> Adri2000: sorry, "Status" how?
<LaserJock> bah, I keep mixing up git and bzr :/
<Adri2000> slangasek: is it going to be updated to a more recent 3.2 version or even 3.3?
<jsmidt> ping james_w
<slangasek> Adri2000: you're probably better off asking the server team; but unless I've overlooked something, 3.3 isn't really a series that we should be shipping in a stable release
<Adri2000> slangasek: ok. I'm asking because I'd like to backport the patch for samba bug #5906 to hardy, and it's applied in version 3.2.6 whereas jaunty only has 3.2.5. so the jaunty version should be updated first
<ubottu> Launchpad bug 5906 in rosetta "Timeout error when entering french translation on Rosetta (dup-of: 3991)" [Medium,Invalid] https://launchpad.net/bugs/5906
<ubottu> Launchpad bug 3991 in rosetta "Timeout error on translation page (+translate)" [Medium,Fix released] https://launchpad.net/bugs/3991
<Adri2000> ubottu: you failed
<ubottu> Sorry, I don't know anything about you failed
<slangasek> Adri2000: the jaunty version should be updated first, or should be updated in lieu of patching?
<slangasek> oh, "hardy", ok
<slangasek> well, I don't see any reason for us to not push a newer version of samba 3.2 to Debian unstable, really
<Adri2000> because afaik the sru policy requires the bug to be fixed in the development release before fixing it in a stable release
<slangasek> yes, that's correct
<Adri2000> if we're going to wait for the package to be updated in debian unstable, that would mean waiting for lenny to be release wouldn't it?
<directhex> in theory next week for that
<directhex> (ha!)
<Adri2000> but that would be only a few days before our feature freeze
<directhex> i think i'm going to be filing a few FFE. stupid debian NEW is kicking my ass
<slangasek> Adri2000: no, there's no reason it needs to be delayed until the Debian release
#ubuntu-devel 2010-02-08
<arand> Is, or at what point is LTS â LTS upgrades scheduled to be available for testing (hardyâlucid)?
<persia> Now.
<persia> They may not work, but that just means it's worth filing bugs.
<Tm_T> sooner the better
<arand> persia: Ok, then how would I do one?
<persia> Take an existing hardy install (or a new one).  Apply all the updates.  dist-upgrade.
<arand> persia: nice, just saw the -d flag for do-release-upgrade, cheers.
<RAOF> Ooof.  I'm surprised no one else seems to have noticed Tomboy crashing because of a liblaunchpad-integration-cil bug.
<RAOF> Maybe everyone has liblaunchpad-integration-dev installed.
<mdeslaur> ROAF: bug #518662
<ubottu> Launchpad bug 518662 in tomboy "Unhandled Exception: System.DllNotFoundException: liblaunchpad-integration.so" [Undecided,New] https://launchpad.net/bugs/518662
 * RAOF shall play âmerge the duplicatesâ
<arand> RAOF: https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/516210 might be the main one?
<ubottu> Ubuntu bug 516210 in ubuntuone-client "Can't start Tomboy on Lucid" [Undecided,Invalid]
<Bsims> Having HD issues... getting the following error messages: ata1: hard resetting link, sd 0:0:0:0: [sda] Unhandled error code, and lost page write due to I/O error on sda1 however when it does it sets /dev/sdb to read only
<Bsims> smartmon says its clean, and I am running the long test now... anyone else see this after the last round of upgrades
<RAOF> arand: No, it's not.  That's a different problem.
<arand> RAOF: oh, ops.
<RAOF> arand: That one is about the notification-indicator patch, which I think has been disabled.  The other one is about the launchpad-integration patch (well, actually about liblaunchpad-integration1-cil, which is broken).
<RAOF> I don't suppose there's an early-rising Do-using core-dev who could take care of sponsoring bug #516920 before too many other duplicates wander into my inbox?
<ubottu> Launchpad bug 516920 in gnome-desktop-sharp2 "gnome-do crashes when Preferences selected from menu" [High,Confirmed] https://launchpad.net/bugs/516920
<StevenK> RAOF: To Lucid? Since some enterprising user has nominated it for every release from Hardy to Lucid and Dapper
<StevenK> Oh. It's r12056
<RAOF> I can't decline any of those, but only Lucid, yes.
<RAOF> I've also got a patch to dh_clideps that will make these sort of problems cause a nice, clean FTBFS rather than silently breaking the archive.
<StevenK> That sounds good too
<TheMuso> /c/c
<RAOF> Which brings me to my next point.  Perl syntax is weird. :)
<StevenK> RAOF: Every one of them declined
<RAOF> Thanks muchly.
<StevenK> Patch looks sane, too
<RAOF> What would be even nicer is to properly rewrite the .config file to resolve -dev symlinks, but that's harder to do safely, I think.
<StevenK> RAOF: I think a FTBFS is a nice safe option, currently
<RAOF> Yes.  And it's much easier to do.
<StevenK> Even given that diff is fairly brittle
<RAOF> The .config file doesn't change very frequently.
<StevenK> RAOF: Uploaded.
<RAOF> Thanks!
<suji11>  Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok
<shawnboy> i'm looking for some opinions... a push in a direction. I'm a formally trained programmer, but from few yrs back (procedural). Looking for recommendations from Linux perspective on where to start to learn OO and what language. C? C++? Something else?
<dholbach> good morning
<pitti> Good morning
<pitti> hey dholbach, wie gehts?
<dholbach> pitti: gut, noch etwas gejetlagged, aber zumindest kommt der Koffer nachher! und dir?
<stefanlsd> gejetlagged isnt a word :)
<d1b> good morning who is the maintainer of sane?
<d1b>  / which people
<pitti> dholbach: urgh, lost your luggage? that sucks
<ogra> stefanlsd, dholbach just created it
<ogra> :)
<pitti> dholbach: I'm reasonably well, got to bed at 2300 and woke up at 8
 * ogra quickly adds it to aspell and uploads :)
<dholbach> pitti: after getting delayed in Portland, I had 20 minutes in Amsterdam to change planes :)
<d1b> launchpad has it listed as
<d1b> ubuntu-dev-team
<pitti> dholbach: did that work out?
<dholbach> pitti: for me yes, but not for the luggage :)
<ogra> d1b, best to check for the last uploader then or check the changelog for the person that did the most uploads of it
<ogra> pitti, so you made it through washington ?
<d1b> ogra: right but i have a general issue. also shouldn't they really be listed as the 'maintainer'.
<ogra> d1b, nope, if he/she steps back the team is the right contact address
<pitti> ogra: no, I spent 45 mins on the phone on Friday to get rerouted; the Washington one got cancelled; went through Chicago and Munich instead
<ogra> i though chicago was shut down as well ?
<ogra> intresting
<ogra> /bin/installer: line 48:   465 Segmentation fault      apt-get -y install oem-config
<ogra> grrr !
<mdke> if someone in ~ubuntu-sru could take a quick look at ubuntu-docs 8.10.3 in the queue for intrepid-proposed, that would be appreciated
<d1b> pitti: hi. i have emailed you. the sane-backends package is really out of date vs git for files such as those which define working device ids for a backend.
<crimsun> d1b: I'm looking at the merge as I type
<crimsun> (as in I just did a "bzr clone lp:debian/squeeze/sane-backends")
<d1b> crimsun: what...?
<d1b> doesn't debian keep their backend in git?
<d1b> crimsun: http://git.debian.org/?p=sane/sane-backends.git;a=commitdiff;h=f3e63b4e4df29342c1b84efe13b65a77f16ca5e5 is one of the commits / examples im talking about.
<crimsun> d1b: I'm referring to a system by which Ubuntu source merges are generated, not necessarily which VCS is used by Debian
<d1b> crimsun: right.
<d1b> crimsun: debian-squeeze also is missing this
<pitti> d1b: got your mail
<pitti> crimsun: oh, thanks; so you're on it?
<d1b> yes he appears to be on it. i think the problem is due to sane not having a release since...
<d1b> i have now filed a bug in debian. hoping to get that fixed up too.
<crimsun> yeah,I saw the bit in -bugs
<\sh> soren: ping vmbuilder, separate boot partition doesn't work somehow when starting up such a vm (kvm here)
<\sh> soren: could it be, that something is wrong with checking on "/boot/foo" in VMBuilder/disk.py ?
<mdke> pitti: I wonder if you might be able to help with my ~sru question above?
<pitti> mdke: uh, intrepid .. *blows the dust away*
<pitti> mdke: I can have a look, but since it's quite out of fashion we usually only do OMGcritical fixes now
<mdke> pitti: oh right. This isn't along those lines. i was just trying to get it off my bug list :)
<mdke> pitti: if you say leave it, that's fine
<pitti> mdke: I'll have a look; if it's harmless, we can as well accept it
<mdke> pitti: ok. I have to leave irc now but I'll pick up on any emails - thanks for taking a look
<crimsun> d1b: / pitti: will look after rest/work; I shouldn't be merging this time of night/morning
<pitti> thanks; sleep well!
<d1b> +1
<ogra> mvo, i had an additional apt-get clean in the code that deleted the packages after copying them into place ... that caused the auth issues i guess
<ogra> oh my ...
 * ogra tries to verify
<mvo> ogra: so it works now?
<ogra> just running a test ... will take 20-30min to do the two builds
 * mvo nods
<ogra> funny, it didnt require an apt-get update so the package lists were in place ... apt-get clean is just to quiet else i would have spotted it
 * ogra goes offline for the offline build test
<ogra> mvo, it still moans abour auth but at least finishes with --allow-unauthenticated
<mvo> ogra: hm, if you have  branch available of the script I can have a look
<ogra> mvo, https://code.launchpad.net/~project-rootstock-developers/project-rootstock/trunk
<alkisg> In LTSP, if I install edubuntu-desktop in the chroot, then $CHROOT/proc is in use and can't be cleanly unmounted. We do dpkg-divert start-stop-daemon and initctl - what else could be using /proc? lsof doesn't help...
<james_w> cjwatson: do you have any problem with me upgrading lp:ubuntu/gfxboot-theme-ubuntu to 2a format?
<directhex> has someone done a grub2 graphical theme yet
<directhex> ?
<persia> directhex: I thought I read in your blog that you did.
<directhex> persia, nothing for the lucid graphical style
<persia> Oh, specifically for lucid.  You might ask in #ubuntu-artwork, but otherwise I suspect one is welcome.
<persia> Even just a framework that someone can tweak, unless it costs boot time.
<directhex> i don't know what the cost is going to be. evidently there's a cost associated with loading images & extra grub modules, but i don't know how much it is real-world
<ScottK> If it's not == 0, then the chances of it going into the default install are nil.
<persia> Or rather, the chances of having it enabled by default are nil.  Having it available for those who choose to tweak their settings is a bit higher (but not extremely high).
<csurbhi> asac, ping
<ivoks> uuid-dev doesn't have /usr/lib/libuuid.la anymore?
<persia> ivoks: .la files have been generally deprecated
<persia> http://wiki.debian.org/ReleaseGoals/LAFileRemoval
<ivoks> ok
<ivoks> thanks, wasn't aware of that
<suji11> Hi , am having dictionary file for tamil, this going to be install to this directory /usr/share/myspell/dicts , for this how to create debian package?
<soren> \sh: Quite possible, yes.
<dantti> cjwatson: ping
<OdyX> Hi. I am the usb-modeswitch{-data} maintainer for Debian. It has some bugs on Ubuntu which are solved by new versions in Debian. Who is supposed to ask for a sync ?
<ogra> OdyX, anyone can ask for a sync https://wiki.ubuntu.com/SyncRequestProcess ... note that we default to sync from testing for 10.04 though
<OdyX> ogra: Okay. My fixes are in testing :-> How late are we wrt to Ubuntu's freeeze ?
<ogra> debian import freeze is on the 11th
<ogra> should be fine if you file the request now
<OdyX> oh. 3 days left then
<OdyX> great.
<Q-FUNK> hi! could anyone with core-dev upload priviledges please act on bug #493628 ?
<ubottu> Launchpad bug 493628 in mozvoikko "Please merge mozvoikko-1.0-4 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/493628
<pitti> mvo: do we still need this nasty $http_proxy hack in sudo?
<TeTeT> mvo: it's important because of bug 432631
<ubottu> Launchpad bug 432631 in sudo "sudo only preserves some, but not all proxy env vars" [Medium,Confirmed] https://launchpad.net/bugs/432631
<mvo> pitti: not strictly, but I would agree we should keep it. its just one entry in the environment whitelist, or do you talk about a different one?
<pitti> mvo: well, it's creating inconsistencies, as reported by TeTeT
<persia> TeTeT: Isn't that intended behaviour?
<pitti> and I'm not really keen on endlessly expanding the list
<TeTeT> persia: makes it tough to use in certain proxy architectures, where you serve some from within your network, others from the Internet
<pitti> mvo: but you can set the proxy on installation these days, can't you?
<TeTeT> serve some=packages
<mvo> my prevent approach would be to have them all in the whitelist then. we have all the bits&pieces in place to remove it, but it will be a inferiour user experience IMO
<mvo> yes, proxy can be set during install and via network capplet
<mvo> but the user needs to remember to click on "apply for all users" (or somesuch) when he sets the proxy
<pitti> mvo: aptdaemon gets it from where? it's not run through sudo
<mvo> without that, the proxy will only be in his session and if we remove the sudo support, then it will not be there in the terminal
<TeTeT> pitti: IMO the first admin user
<mvo> pitti: aptdaemon gets it from the client (software-center) so that is fine
<pitti> well, perfect
<mvo>  I'm more concerned it people opening a terminal
<pitti> (well, not perfect in fact, since it's the very same security problem)
<pitti> a proxy just conceptually isn't something that should be a per-user setting
<pitti> mvo: perhaps eventually the proxy capplet should _always_ apply system-wide?
<mvo> we can make that happen, I guess, just check for admin group and not ask for a password
<persia> Um, why shouldn't proxies be per-user?  I agree in the case of apt proxies, but I can imagine all kinds of other sorts of proxies being per-user.
<TeTeT> isn't /etc/cron.daily/apt also taking the proxy environment from a user?
<mvo> TeTeT: its doing that to work around the same problem
<mvo> and only if there is no proxy set via apt conf or the root environment
<TeTeT> ok, just saw the -z http_proxy
<TeTeT> mvo + pitti : so there is no easy solution?
<pitti> mvo: no, I meant "apply system-wide" should always be the default button
<pitti> or action
<pitti> ugh, how can the daily cron job take an user's env? which user's?
<TeTeT> pitti: first admin user
<persia> That requires all sorts of hackery.
<pitti> urgh
<pitti> we really need a system-wide setting for this
<TeTeT> pitti: admin_user=$(getent group admin|cut -d: -f4|cut -d, -f1)
<pitti> persia: while that might be true, I doubt that for the vast majority of use cases
<pitti> we don't have per-user network connections either
<pitti> and a proxy is very tightly tied to a network configuration
<persia> Well, OK.  I'm thinking of things like a shared machine where someone wants a UK proxy for BBC, but others don't need it, and the like.
<pitti> and if one special application wants to talk through a proxy, it should ceratinly handle that internally instead of clobbering $http_proxy?
<persia> I was thinking of the browser :)
<TeTeT> persia: the browser can use it's on proxy setting per user without problem, IMO
<mvo> we have a way to set this system wide, the apt cron script checks gconf for the case when a user installed without proxy and never pressed "use system wide". this is only a precaution to ensure that e.g. security updates can get through
<pitti> that already has its own (and also I still don't believe that per-user settings are much sensible there)
<mvo> I'm in favour of removing all this, don't get me wrong, I'm just concerned that we break a lot of systems that used to work and will no longer work after the change
<pitti> mvo: OTOH that means if an user breaks his proxy settings, we break security updates system-wide?
<mvo> its only the admin user and if he can no longer browse, he will notice
<pitti> right, it's a case of "should've fixed that 5 years ago" :(
<mvo> I mean, that is a bit of a theretical scenario, if he breaks his other network settings, the same hapepns
<mvo> I think its just a unfortunate thing we inherited from the gnome control center
<mvo> my take on it would be: make it consistent for lucid (by adding https_proxy, ftp_proxy) and remove for lucid+1 with appropriate way of telling the user
<TeTeT> works for me
<pitti> couldn't we alternatively use the first admin user's proxy setting and write that into a system-wide conffile in a postinst?
<pitti> it's no worse than we do now, but woudl at least be an one-time migration
<pitti> and if we do it in lucid, we aren't stuck with it for another 4 releases
<mvo> its worse in the sense that it will not update the config
<pitti> we have the "apply system wide" button
<mvo> I mean, then we need to tell the user what we did if he has a different proxy on home/work
<pitti> we could update the label in g-c-c?
<mvo> oh, that is a good idea - update to indicate inconistency?
<pitti> I mean, if persia's objection of "per-user settings make sense" is true, then we _don't_ always want to apply those to apt
<pitti> and if it's false, then we shouldn't have per-user settings in the first place
<pitti> mvo: indicate inconsistency also sounds good; I meant, change the wording around "system wide" to point out "to also apply to package updates"
<mvo> I guess that is a good way forward, apply once and when changed have a way to tell the users that its inconsistent
<mvo> (apply once via postinst)
<pitti> mvo: does apt just use $http_proxy as well? I. e. /etc/environment?
<pitti> mvo: IOW, what does "apply system-wide" do? adding it to /etc/environment would make sense certainly?
<mvo> pitti: apt has its own apt.conf setting, but the system-wide button also writes to /etc/environment
<pitti> ah, I see
<mvo> pitti: it does both, add to apt.conf and environment
<pitti> mvo: AFAICS, /etc/cron.daily/apt only sets $http_proxy, though
<mvo> right, it can go away entirely with the approach of apply+warn IMO
<pitti> mvo: right, I meant apparently apt does check $http_proxy?
<mvo> yes
<pitti> it would make the entire system very consistent
<pitti> i. e. system-wide $http_proxy, and users can change
<pitti> ok, I'll summarize in the bug
<pitti> mvo: thanks for discussion!
<kitallis> could these two bugs be caused by a similar flaw? https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/29894 & https://bugs.launchpad.net/notify-osd/+bug/500550
<ubottu> Ubuntu bug 29894 in gnome-utils "can't take screenshot when menu on panel is opened" [Unknown,In progress]
<mvo> pitti: sure, thanks as well, I think we have a good solution
<pitti> mvo, TeTeT: bug 432631 updated; cross-check?
<ubottu> Launchpad bug 432631 in sudo "clean up system/per-user proxy handling" [Medium,In progress] https://launchpad.net/bugs/432631
<\sh> soren: I changed that but no change :(
<mvo> pitti: thanks, done. I added the inconsitency check/warning. I think its important to ensure users keep updating the thing
<pitti> thanks
<smoser> anyone know why https://launchpad.net/ubuntu/+source/cloud-utils is still 'pending publication'
<smoser> build took place 2 days ago
<persia> smoser: Check the NEW queue.
<persia> https://launchpad.net/ubuntu/lucid/+queue
<smoser> persia, thanks
<geser> any main sponsor free to review and sponsor 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
<ogra> oh, when did we stop setting LANG in /etc/environment ?
<pitti> did we ever?
<pitti> /etc/default/locale
<ogra> yes, tollef added that ages ago
<ogra> pre dapper iirc
<ogra> and it was always carried along
<pitti> /etc/environment works
<ogra> mine only has PATH
<pitti> but we don't put it there by default
<ogra> right
<ogra> we used to though
<alkisg> I think it changed in Interpid
<ogra> that might be, my lappie was upgraded from intrepid originally until i did this renistall for the new HD
<ogra> sigh ...
<ogra> oem-config doesnt work at all here ... goes into an endless loop
<smoser> is it normal for publish-to-archive to lag build by more than a day ?
<smoser> https://edge.launchpad.net/ubuntu/+source/linux-ec2 build finished 44 hours ago, but its not in archive yet.
<sistpoty|work> smoser: looks like it's in binary new: https://launchpad.net/ubuntu/lucid/+queue?start=30
<superm1> smoser, if you look closer at the build ( https://launchpad.net/ubuntu/+source/linux-ec2/2.6.32-302.6 ), you can see that it's got "New" binaries.  that means an archive admin will have to accept them into the archive and adjust the component (main,restricted,universe,multiverse) accordingly
<superm1> ogra, what version of oem-config are you testing that's going into an endless loop?
<ogra> superm1, well, i'm not sure i run it correctly or even set it up correctly, its the recent lucid version
<smoser> hm..
<superm1> ogra, well all there is to setting it up is "sudo oem-config-prepare", but the particulars on the version are important because there was some bugs that would cause that behavior within the last 2 versions or so, but should be resolved on the latest
<ogra> superm1, essentially i only want user timezone kbd and language settings in a bare debootstrapped chroot system ... i installed oem-config and touched /var/lib/oem-config/run
<sebner> Are there still problems with autosyncing debsrc3.0 packages?
<smoser> i dont quite understand why linux-ec2 build would have produced "new" packages.
<ogra> superm1, the above makes it start but gets me also tasksel and a lot of extra stuff i'd like to avoid
<soren> smoser: New binary packages. ABI bump, right?
<superm1> ogra, oh you're running the debconf frontend.... i'm not sure how stable it is at this point
<ogra> superm1, ah, i'll try to do an X setup then
<ogra> though i need both frontends
<smoser> oh. ok. yeah. ther ewas an abi bump.  so each time kernel bumps abi they have a "new" package.
<soren> smoser: Yes.
<smoser> soren, you're right on abi bump.
<soren> smoser: This happens all the times for kernels. Most of the time, you just don't notice :)
<smoser> right.
<smoser> is it proper for me to nag slangasek or james_w (per https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days) to approve https://launchpad.net/ubuntu/lucid/+queue?queue_state=0&queue_text=linux ?
<james_w> smoser: it is
<ogra> superm1, oem-config-enable doesnt setup the /var/lib/oem-config/run it only puts the rc scripts in place it seems
<superm1> ogra, oem-config-prepare is what i had mentioned, but essentially it's just touching /var/lib/oem-config/run for the next boot
<ogra> superm1, didnt happen here
<ogra> hmm, and installing the xorg package in the chroot didnt get me the graphical version ... i wonder what i'm missing
<smoser> james_w, could you do that for me then please ? thank you.
<ogra> superm1, do you know if ubiquity or d-i put anything in place i have to add to my chroot/image to make it start ubiquitys oem-config instead of the text version ? as far as i understood its just supposed to come up as DM
<ogra> root@osiris:/# /usr/sbin/oem-config -q
<ogra> debconf_ui
<ogra> aha
<geser> sebner: only with second autosyncs of packages using .orig.tar.bz2 (see bug #225151)
<ubottu> Launchpad bug 225151 in soyuz "Please add support for .orig.tar.bz2" [High,Triaged] https://launchpad.net/bugs/225151
<james_w> smoser: done
<smoser> danke
<sebner> geser: ah ic. thanks :)
<dupondje> could somebody check https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 for me ? it needs sponsoring
<ubottu> Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Low,Triaged]
<dupondje> would be nice this fix gets into Lucid, as its broken since Karmic :(
<superm1> ogra, you've gotta install a gtk or kde frontend to use one of those (oem-config-gtk or oem-config-kde)
<ogra> oh, i thought that comes automatically with the new ubiquity dep
<ogra> silly me
<geser> dupondje: my C++ is a little bit rusty but don't you need to free(delete) the BlankLine allocation somewhere again?
<dupondje> geser: I didn't touch the free's etc, only the size of the thing :)
<tsimpson> it's allocated on the stack
<ogra> wow, the gtk frontend pulls in fvwm ???
<superm1> ogra, it pulls in a window manager.  i suppose fvwm is one of those possibilities
<superm1> most cases it's used people already have metacity or xfwm4 installed
<ogra> yeah, i guess i'm building a very special case atm ;)
 * ogra is working on an offline rootfs build tool for armel systems
<ogra> and i thought it would be the easies to just pull in oem-config to set up user and pw ... but that effort gets wose and worse
<tsimpson> dupondje: you really should use a patch, rather then directly modifying the source
<dupondje> tsimpson: why exactly ? whats the difference ?
<geser> dupondje: before it was on the stack and was cleared automatically, but now you use dynamic allocation (new) and should free it again (delete) else you get a memory leak
<tsimpson> dupondje: several reasons, a couple of which are: 1) it's debian policy, 2) it's easy to see ubuntu changes, and 3) if upstream incorporate the patch, it's easy to remove our patch
<tsimpson> and yes, you do need to "delete[] BlankLine;" somewhere (the destructor)
<dupondje> ok thanks for the input
<dupondje> will make a new debdiff
<smoser> pitti, ping, your you have feedback on https://bugs.launchpad.net/ubuntu/+source/apport/+bug/513061 (last comment there)
<ubottu> Ubuntu bug 513061 in apport "apport reports 'not a genuine Ubuntu package' on fresh installation without apt cache" [Low,Triaged]
<ogra> no ui at all :/
<ogra> argh and installing metacity would install 400MB !
 * ogra wants old oem-config back ! that ubiquity merge is a mess if you dont use it with a desktop image
<ogra> *whine*
<ogra> ah, i was trapped by recommends
<ogra> still over 30M
<ogra> superm1, ok, its trying to start but breaks then with subprocess.Popen(proc)
<ogra> using 2.1.16 btw
<superm1> ogasawara_, can you get a full BT?  It might have logged that BT to /var/log/oem-config.log already for you.
<superm1> ogra, ^
<ogra> i'll try to ... i sadly cant copy-paste from qemu
<superm1> you should be able to at least scp that log file out hopefully to a real machine
<superm1> or use something like pastebinit to get it out on the internets
<ogra> yeah, indeed
<ogra> woah
<ogra> seems to be a pygtk issue actually
<ogra> superm1, just fyi ... http://paste.ubuntu.com/371902/ i doubt its ubiquitys fault
<superm1> ogra, yeah i agree.  have fun debugging that :)
<ogra> heh
<ogra> i'll probably give up on the UI part ... it pull sway to much into the rootfs anyway since the merge
<ogra> the old oem-config was far better suited for that usecase
<ogra> (which is why it was initially added to the spec :) )
<jono> bdmurray, ping?
<jono> ignore my msg :)
<superm1> ogra, well the debconf frontend is probably still well suited for your case, just check with ev where it's at stability wise.
<ogra> yeah
<ogra> seems i need to have a lot of debconf stuff set in advance though
<ogra> currently thats a plain debootstrapped system
<ogra> superm1, do you know if we have any docs what oem-config expects or do i need to dig through the code ?
<superm1> ogra, for the debconf ui, i've no idea.  for the other UI's, nothing needs to be set in advance normally
<ogra> ok
<ogra> well, then i'D expect the same for debconf actually
<ogra> i'll wait until ev is back
<apw> pitti, whats happening with the states on bug# 446146
<apw> bug #446146, you and JFo seem to be arguing :)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/446146)
 * apw slaps ubottu 
<apw> be more patient ubottu
<JFo> heh
<JFo> I keep getting timeouts too
<czajkowski> be nice to the bot
<smoser> maybe someone can help. i'm missing something and can't figure out what.  I'm trying to backport schroot to karmic.  I grabbed ubuntu source (lp:ubuntu/schroot) and applied changes at http://paste.ubuntu.com/371949/
<smoser> whenh i build with sbuild, it builds fine, but a schroot-common package is not built.  I'm at a loss as to why, I see i nthe log that files are copied to debian/install/usr/share/locale
<smoser> (debian/schroot-common.install has 'debian/install/usr/share/locale usr/share')
<smoser> i notice now the libsbuild-doc package is also not built
<maxb> sbuild is commonly used for buildds. Therefore, I would be unsurprised if it defaulted to not building architecture=all packages.
<smoser> maxb, thank you
<geser> smoser: I don't use sbuild but I heard that you need to pass an option to sbuild to also build the arch-indep packages, check the manpage in that direction
<smoser> geser, yeah maxb suggested above, and was correct.  i had to run with --arch-all
<smoser> but thank you
<dupondje> tsimpson: geser: https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<ubottu> Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Low,Triaged]
<dupondje> added a new patch
<geser> kees: Hi, thanks for your last commit to ubuntu-dev-tools. would you consider it as a fix for bug #518574?
<ubottu> Launchpad bug 518574 in ubuntu-dev-tools "requestsync is dependent on a Debian batch process" [Undecided,New] https://launchpad.net/bugs/518574
<kees> geser: oh, hrm
 * kees reads
<kees> geser: yeah, I guess it does.  I will adjust my commeit
<kees> s/eit/it
<dupondje> geser: could you check if its fully correct now ? :)
<kirkland> slangasek: ping
<slangasek> kirkland: hi
<kirkland> slangasek: http://paste.ubuntu.com/371989/ <--- that's the pam patch I need for the improved ecryptfs functionality
<kirkland> slangasek: i'm looking for guidance from you on the order of operations here
<kirkland> slangasek: i'm prepping an email to upstream PAM
<kirkland> slangasek: in what order should the patch be accepted, before I can upload it to Lucid?
<kirkland> slangasek: ie, is upstream and debian acceptance pre-reqs for getting this patch into Lucid's pam soon?
<geser> dupondje: looks ok as far as I can tell, you just need to wait for a main sponsor now
<dupondje> geser: ok thx for looking :)
<slangasek> kirkland: why does pam_ecryptfs need pam_keyinit in the auth stage?  If you can tell me that, then I have no objection to it going into lucid first
<kirkland> slangasek: hrm
<kirkland> slangasek: this bit was written with dhowells
<kirkland> slangasek: basically, we need pam_keyutils to establish the session keyring
<kirkland> slangasek: whereas now, we're using the user keyring
<slangasek> why are we expecting the session keyring to be established before the PAM session is opened? :)
<dupondje> kees: I see you already uploaded patches for aptitude, is it maby possible to check https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 ? Would be nice if this gets into Lucid. Just did a build, and it works perfect :)
<ubottu> Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Low,Triaged]
 * kirkland thinks
<slangasek> actually, looks to me like we're missing a corresponding pam_sm_close_session() call - is that going to leave extra session keyrings hanging around in the kernel?
<kirkland> slangasek: dhowells says that those are auto-reaped
<slangasek> ok
<kirkland> slangasek: okay, so pam_ecryptfs inserts the key in its pam_sm_authenticate()
<kirkland> slangasek: which means the keyring must exist at that point
<slangasek> why does it do that, rather than waiting until pam_sm_open_session() itself?
<kirkland> slangasek: well, we need the passphrase the user actually entered
<kirkland> slangasek: to unwrap the mount passphrase
<slangasek> yes; which can be captured in the auth stage and stored as module data until the session stage
<kirkland> slangasek: interesting...
<slangasek> otherwise, what happens with a session-less service when you have pam_ecryptfs configured?
<kees> dupondje: was that meant for someone else?
<kirkland> slangasek: looking at the code ...
<dupondje> kees: no, saw you had some change in aptitude. Just need somebody that wants to approve the patch.
<kirkland> slangasek: pam_ecryptfs's session handler just does the mount, if necessary, and if possible
<kirkland> slangasek: it expects the necessary keys to already be loaded
<slangasek> well, I'm questioning that assumption :)
<kirkland> slangasek: which happens at the auth stage
<slangasek> i.e., why should the kernel setup be done at the auth stage, if it's really tied to a session
<slangasek> consider a sessionless service that runs multiple user authentications in a single process
<slangasek> (web services may fit this model)
<slangasek> (or POP?)
<kirkland> slangasek: hmm, so you're saying don't load the keys *unless* we're in a session
 * slangasek nods
<kirkland> slangasek: okay, well, i can't find a good argument why not
<kirkland> slangasek: i think this originally landed in pam_auth so that we would have access to the password
<slangasek> I think pam_krb5 is probably a good example to follow, here
<kees> dupondje: oh, yeah, that was just an ABI bump.  check with mvo
<kirkland> slangasek: okay, well, my only concern is that this is a lot of code for me to muck around with at this point in Lucid
<dupondje> kees: will do if he's around here somewhere :)
<slangasek> (though I think pam_krb5 uses kerberos APIs to carry the creds between auth and session, instead of the PAM APIs)
<kirkland> slangasek: i might need a good second set of eyes
<slangasek> kirkland: I have several in my drawer
<kirkland> cjwatson: any objections to this grub2 patch?  -> http://paste.ubuntu.com/372039/
<jcole> ï»¿ï»¿ï»¿where is the global firefox settings file? i want to set the global homepage
<cr3> when I run debuild: 1. I get .bzr in the resulting tarball; 2. the top directory is $(basename $(pwd)), whereas it should be name-version. how can I solve these problems?
<RAOF> cr3: It sounds like you probably want to run âbzr bdâ rather than debuild.  Are you building from a bzr packaging branch?
<cr3> RAOF: I'm not sure what is a bzr _packaging_ branch, it's just a bzr branch which happens to contain a debian directory for packaging purposes if that's what you mean
<RAOF> cr3: Yeah; it's source package you grab via bzr.  You want to use bzr builddeb (or its alias, bzr bd) in the same way that you'd use svn-buildpackage or git-buildpackage.
<cr3> RAOF: but this package doesn't necessary have an upstream version, so looking for upstream tarball won't work
<RAOF> bzr bd will either (a) find a nice revision property to tell it how to construct a tarball, or (b) you can use --split to create an .orig.tar.gz from the source tree.
<smoser> kees, ping.
<kirkland> slangasek: dhowells joined us here to help answer some of your hard pam questions for me
<kees> smoser: hi! what's up?
<smoser> before knowing any better, i modified mk-sbuild-lv to support setting up schroot mounts with union-type=aufs
<slangasek> dhowells: hello :)
<dhowells> hi
<smoser> (i say knowing any better because i think there might be already existing tools, but mk-sbuild-lv was all i was familiar with, and it had more smarts than i wanted to copy)
<smoser> would accepting a patch be possible ?
<smoser> or would you be uninterested in such a thing, kees
<smoser> http://paste.ubuntu.com/372069/
<slangasek> dhowells: I've posed the argument to kirkland that neither pam_keyinit nor pam_ecryptfs should be messing with the session keyring in the auth stage, because there are valid use cases for sessionless authentication where we don't want the PAM stack to be modifying the keyring of the calling process
<dhowells> slangasek: sounds reasonable
<slangasek> dhowells: and have proposed that he stow the creds in the auth stage with pam_set_data() and retrieve them in the session stage, at which point this patch to pam_keyinit is unnecessary
<dhowells> slangasek: the main thing about pam_keyinit is that it needs to be invoked before any PAM module that wants to create keys and hang them off the session keyring
<dhowells> slangasek: but it has to be called after "session pam_selinux open blah"
<slangasek> interesting
<slangasek> so doing this in the auth phase is definitely wrong...
<dhowells> otherwise the keys and keyrings created by pam_keyinit, pam_ecryptfs, etc., don't get correct security labels
 * slangasek nods
<kees> smoser: one sec, I'll read that
<dhowells> slangasek, kirkland: in fact, in can be argued that pam_ecryptfs shouldn't be reading the encrypted key files from the user's homedir until after pam_selinux has set the security label
<smoser> kees, my feelings wont be hurt if you're not interested, prior to doing it i wasn't aware of a sbuild-createchroot.
<kirkland> dhowells: that's possibly true; selinux never entered my consideration when doing the encrypted-home-directory work
<smoser> does it seem to anyone else that schroot does not read files in /etc/schroot.conf/chroots.d/ like it says it does?
<smoser> (err... chroot.d)
<kees> smoser: on a call, so a bit lagged
<smoser> no problem.
<kirkland> slangasek: dhowells: so let me see where this leaves us ...
<kirkland> slangasek strongly believes that we're doing stuff in auth that we should be doing in session
<kirkland> burden is on kirkland to convince slangasek otherwise ;-)
<kees> smoser: interesting.  I didn't know that schroot grew a "union-type".
<smoser> in 1.4 and it is "preferred"
<smoser> its faster and smaller than lvm
<kees> very interesting.
<persia> kees: If you're deeply interested, I ought have a refactoring that generates a mk-sbuild-tgz in a couple more hours.
<persia> (and I'd appreciate your review)
<kees> persia: does schroot handle tgz sanely (i.e. a target named -source that updates the tgz?)
<kirkland> dhowells: i can *try* to move my pam_ecryptfs stuff to the session bit
<persia> If you set union-type=aufs, to my understanding.  I'm still testing locally
<kirkland> dhowells: slangasek: but i have no idea yet how to move the cleartext login passphrase from the auth to the session (will need to look at krb5 per slangasek)
<smoser> kees, that was my understanding also.
<smoser> i believe that you can even hvae a loopback filesystem as the source for a union type
<kees> smoser: cool, yeah, I like this.  persia: I'm interested, for sure.
<smoser> if you didn't like the filesystems sitting in /srv/chroots unpacked
<slangasek> kirkland: pam_set_data() in auth, pam_get_data() in session will do the trick (taking care to set an appropriate cleanup function...)
<kees> smoser: okay, let me shake this patch out a bit (there is at least one little bug) and I'll commit it.
<persia> kees: OK.  I'll be breaking for food soon, but ought be able to push a branch for review by somewhere shortly after midnight UTC.
<smoser> kees, note the rename
<dhowells> slangasek: is there a chance that someone can steal the data?
<smoser> if you think thats right.
<kees> persia: let me get smoser's change in first, since that'll have the framework for "chroot type" in it.
<persia> smoser: I'm putting tarballs in /var/lib/schroot/tarballs/ by default.  Does that also make sense to you?
<kees> smoser: yeah, I think that's fine.
<smoser> persia, i picked /srv/chroots, just as that was what was in the examples in man schroot
<smoser> var/lib sounds reasonable.
<kees> persia: that sounds good to me.  I'd like the chroots to be under there too (instead of /srv/*)
<smoser> we can definitely have it support tgz, directory, and lvm by users preference.
<kirkland> slangasek: i'll give that a shot
<persia> smoser: Looking at your patch, I think we've been doing the same thing for the past while :)
<kirkland> slangasek: assuming that works, then keyring creation should happen in the session
<smoser> well, good, then i *completely* wasted my time :)
<slangasek> dhowells: the same chance that someone would intercept the password while it's being input
<smoser> persia, since you're kind of playing there, i would appreciate a sanity check...
<smoser> for me, contrary to doc, files in /etc/schroot/chroot.d/ are ignored
<persia> smoser: I'll let kees review the patch, since he's had lots more experience hacking that script than I :)  I split the scripts and refactored, rather than adding, but I like your approach better.  One note is that you might pull the lvm2 install out of the initialisation, and have a `dpkg -l lvm2 || sudo apt-get install lvm2` run only in cases where an lvm snapshot is requested.
<smoser> i figured out the chroots.d, seems like there is a filter applied to filenames there that i wasnt passing. sbuild::is_valid_filename was filitering it out.
<smoser> i have to run
<smoser> kees, if we're dusting off that script, we really should write entries into /etc/schroot/chroots.d
<persia> What does that directory do?  I'm not finding it in the docs.
<persia> smoser: You may also want to consider rebasing off the mk-sbuild-lv in lucid.  It's similar, but has a few other changes.
<Caesar> yofel: ping
<yofel> pong
<Caesar> yofel: bug #381753, I just want to make sure that marking it Fix Released isn't going to cause it to be overlooked for Hardy
<ubottu> Launchpad bug 381753 in dpkg "Handling of conflicting conffiles broken" [High,Fix released] https://launchpad.net/bugs/381753
<yofel> Caesar: not sure (that's why I nominated it), but the bug is fixed in Ubuntu since Jaunty so it *is* fixed
<Caesar> ok
<Caesar> I can provide a patch if it helps, it's laughably small
<persia> Caesar: Please do, if you have one.  It may not affect the fix time, but having it in a state where it only requires review rather than requiring development tends to smooth the path.
<Caesar> I don't have one, but at the time I looked at what the fix was, and it was a one-liner
<Caesar> So I can produce one relatively easily once I revisit the problem
<kapdia> hello
<kapdia> which option do i use on a live cd to only install a minimal system
 * kapdia can't access #ubuntu or #ubuntu-support
<RAOF> I don't think you do - for that I think you need the alternate CD.  Also, not really a question for #ubuntu-devel; #ubuntu or #ubuntu+1 would be the appropriate venue.
<kapdia> thx RAOF
<johnm> could anyone tell me if something has changed re: users being able to setuid root recently? in that, I can't :)
<slangasek> what do you mean, "setuid root"?
<johnm> slangasek: as in, setuid32(0).. but I've worked it out now I think.. been racking through it for a while now and its just been getting frustrating ;)
<slangasek> ehm, I don't know why you would expect a user to be able to call that
<johnm> on a setuid binary?
<slangasek> if it's on a setuid binary, then it's not the user calling setuid() :)
<tlyu> but if it's a setuid binary, not _all_ of UIDs get set on exec...
<johnm> indeed, but as an example I was setuit root on the binary and then called setuid() and it was failing, but it was an apparmor profile blocking it.
<johnm> something I thought I'd disabled :)
<slangasek> aha :)
#ubuntu-devel 2010-02-09
<directhex> tip for the day: writing a full dep5 debian/copyright for 39k source files is hard work
<slangasek> directhex: dep5 says nothing about the granularity you should provide, you know
<directhex> slangasek, all copyright holders need listing in the appropriately licensed chunks, though. i'm *heavily* abusing wildcards to make life more bearable than it could be
<mdeslaur> asac: do you mind if I merge liferea?
<smoser> persia, hm... i pulled from lp:ubuntu/ubuntu-dev-tools
<slangasek> directhex: well, you only have to list all copyright holders if the license or Policy requires it... dep5 only defines the format :)
<directhex> slangasek, the aim is to avoid REJECT. experience teaches over-thoroughness is a more successful path than under-thoroughness
<persia> smoser: Perhaps that's out of date.  Trunk is at lp:ubuntu-dev-tools.  This may change at some point.
<persia> smoser: Once you've rebased, please push somewhere, and I'll redo my tgz handling based on your branch.
<smoser> hlok
<smoser> ok
<directhex> now, bedtime. there's always more time for copyright tomorrow
<smoser> persia, lp:~smoser/ubuntu-dev-tools/ubuntu-dev-tools.dev
<smoser> i've got to run, so i didn't test the merge... i had tested what i had before at least for union
<kees> smoser, persia: ran out of time today, but if you work from smoser's branch, I'll be able to pull it in quickly (i'm working from his branch too)
<persia> smoser's branch is way cooler than mine was, and mine has since been discarded :)
<persia> Or it would be, based on the patch.
 * persia waits for LP more
<Caesar> slangasek: ping
<Caesar> slangasek: minor shambles detected wrt autofs
<Caesar> slangasek: autofs is a dummy package in main
<slangasek> Caesar: hi
<Caesar> slangasek: autofs-ldap is a real package in universe claiming to be from the autofs source package
<Caesar> it's possible to install autofs5 (via autofs) and still have autofs-ldap
<Caesar> What should I file the bug against?
<Caesar> and trying to install autofs after autofs5 has been installed produced ugly errors
<slangasek> what's your target outcome?  autofs-ldap auto-upgraded to autofs5-ldap, or autofs restored as a real package?
<Caesar> It sounds like autofs-ldap (and friends) needs to go/become a dummy package
<slangasek> ok, please file it on autofs then
<Caesar> Is it normal for dummy packages to be uninstallable after removal?
<slangasek> any package in the archive should be installable
<slangasek> if it's not installable, it shouldn't need to be there at all
<Caesar> autofs (dummy package) is not installable when autofs5 is installed
<slangasek> yah, autofs5 Conflicts: autofs; that's not right
<slangasek> so I guess autofs5 needs fixing as well
<Caesar> Two bugs?
<slangasek> one bug, it's all of a piece really
<Caesar> ok
<Caesar> I'll file it shortly
<slangasek> cheers
<fullTummy> j e b i t e s e
<fullTummy> ViÄi vraga su sedam binjiÅ¡ah,
<fullTummy> su dva maÄa a su dvije krune,
<fullTummy> praunuka Turkova s Koranom!
<fullTummy> Za njim jata prokletoga kota,
<fullTummy> da opuste zemlju svukoliku
<fullTummy> ka skakavac Å¡to polja opusti!
<fullTummy> Francuskoga da ne bi brijega,
<fullTummy> aravijsko more sve potopi!
<fullTummy> San pakleni okruni Osmana,
<kklimonda> !op
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<fullTummy> darova mu lunu ka jabuku.
<fullTummy> Zloga gosta Evropi Orkana!
<fullTummy> Vizantija sada nije drugo
<fullTummy> no prÄija mlade Teodore;
<fullTummy> zvijezda je crne sudbe nad njom.
<fullTummy> Paleolog poziva Murata
<fullTummy> da zakopa Grke sa Srbima.
<fullTummy> Svoju misli BrankoviÄ s Gertukom.
<elpargo> hi, if I want to write a program that will run "forever" listening to a streaming api (http1.1) will it be better to make a service out of it? or should I stick with a daemon?
<fullTummy> Muhamede, to je za Gertuku!
<fullTummy> Sjem Azije, Äe im je gnjijezdo,
<fullTummy> vraÅ¾je pleme pozoba narode -
<fullTummy> dan i narod, kako Äuku tica:
<fullTummy> Murat Srpsku, a Bajazit Bosnu,
<fullTummy> Murat Epir, a Muhamed GrÄku,
<fullTummy> dva Selima Cipar i Afriku.
<fullTummy> Svaki neÅ¡to, ne ostade niÅ¡ta;
<fullTummy> straÅ¡ilo je sluÅ¡at Å¡to se radi!
<fullTummy> Malen svijet za adova Å¾vala,
<fullTummy> ni najest ga, kamoli prejesti!
<fullTummy> Janko brani Vladislava mrtva;
<fullTummy> Å¡to ga brani, kad ga ne odbrani?
<fullTummy> Skenderbeg je srca ObiliÄa,
<fullTummy> al' umrije tuÅ¾nim izgnanikom. -
<fullTummy> A ja Å¡to Äu, ali sa kime Äu?
<fullTummy> Malo rukah, malena i snaga,
<fullTummy> jedna slamka meÄu vihorove,
<elpargo> :(
<fullTummy> sirak tuÅ¾ni bez nigÄe nikoga...
<fullTummy> Moje pleme snom mrtvijem spava,
<fullTummy> suza moja nema roditelja,
<fullTummy> nada mnom je nebo zatvoreno,
<kklimonda> we need more operators
<fullTummy> ne prima mi ni plaÄa ni molitve;
<elpargo> why people waste time and money doing that.
<kklimonda> I have no idea
<kklimonda> and I've thought really hard about it lately
<tsimpson> better late than never I guess
<elpargo> thanks tsimpson
<zul> caesar: ping
<Caesar> zul: pong
<zul> Caesar: got a sec to chat?
<Caesar> zul: if it's quick, otherwise I'll be home in a little bit
<ebroder> Does anybody have any ideas about bug #276777? I'm running into something similar using gdebi, but I think it's the same bug
<ubottu> Launchpad bug 276777 in debconf "libpam0g error while upgrading from 8.04 to 8.10 alpha6" [Undecided,New] https://launchpad.net/bugs/276777
<ebroder> The error popup is coming from the /usr/share/debconf/frontend process, which doesn't have DBUS_SESSION_BUS_ADDRESS set
<ebroder> Nothing is bound to the socket it's complaining about, and it's different from the DBUS_SESSION_BUS_ADDRESS that my unprivileged user has set
<micahg> kees: ping re NSS
<kees> micahg: go for it (I just touched it for build changes)
<micahg> kees: cool, thanks
<kees> np, thanks
<pitti> Good morning
<pitti> apw: we don't close bug tasks when it's still in -proposed, so "fix committed" is more appropriate
<pitti> james_w: I'm a bit confused about https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/ido/lucid-201002090705/+merge/18905
<pitti> james_w: does that mean that kenvandine committed something different to the branch than what actually got uploaded?
<pitti> kenvandine: ^
<dholbach> good morning
<kees> Ng: if the G45M has a TPM module, my rng-tools change should work with it.  what sort of stuff does it have?
<pitti> hey dholbach, guten Morgen
<dholbach> hi pitti
<alkisg> The new tftpd-hpa is serving files from /srv/tftp instead of /var/lib/tftpboot (LP #518815). Is this change permanent? Should we change LTSP to use that new path?
<ubottu> Launchpad bug 518815 in ltsp "The new tftpd-hpa.postinst uses /svr/tftp instead of /var/lib/tftpboot" [High,Confirmed] https://launchpad.net/bugs/518815
<kees> smoser: thanks, I've merged the mk-sbuild changes.
<Ng> kees: I'm not entirely sure, but the bios for my thinkpad is full of talk of security chips
<kees> Ng: hmmm, and none of the tpm_* modules are happy?
<Ng> kees: not immediately. http://www.thinkwiki.org/wiki/Intel_GM45_TPM_device_iTPM_INTC0102 seems relevant
<pitti> does anyone have an idea what I'm missing to get the AM_CHECK_PYTHON_HEADERS autoconf macro?
<kees> Ng: it looks like the fix is upstream http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/char/tpm/tpm_tis.c;h=2405f17b29ddd87994f354e5530f264c726d5761;hb=HEAD  but not in lucid.  perhaps request a cherry-pick from the kernel-team?
<Ng> kees: aha, ta
<james_w> pitti: no, that's a bug, I'll take care of it
<free> pitti: hey!
<free> pitti: I'm preparing an SRU for the landscape-client, just to be extra sure, for each bug the SRU addresses I have to create a task by selecting Ubuntu in the "Also affects project" link, right?
<pitti> free: right, it needs an Ubuntu package task, and then release tasks for lucid and the release(s) you want to SRU to
<pitti> free: (the latter is "target to release...")
<free> pitti: cool, thanks
<free> pitti: does this one look good? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/218388
<ubottu> Error: This bug is private
<pitti> free: please make it public first
<pitti> (I can't see it)
<free> oops :) public now
<pitti> free: yes, approved all tasks
<free> pitti: thank you
<pitti> james_w: thanks
<lool> cjwatson: I need to add support for setting the credentials "C" flag in binfmt-support; would having a "credentials" line in the format description file in /usr be a good way for that, or do you prefer a different way?
<lool> cjwatson: This is needed to allow sudo to work from armel chroots
<pitti> james_w: I'm about to create a brand new package; if I do "bzr init" and "bzr import path/python-gudev-147.1.tar.gz", will this automagically do the pristine-tar magic?
<james_w> pitti: unfortunately not
<pitti> bzr help commands doesn't have anything about pristine-tar
<pitti> james_w: is there some howto about using pristine tar with bzr?
<james_w> pitti: you want to base your work off an upstream branch?
<pitti> james_w: or should I just not use bzr, upload, wait for the auto-importer, and use it from then on?
<pitti> james_w: upstream is in git
<james_w> so? :-)
<pitti> james_w: so I thought I'd just start with the last upstream tarball
<james_w> in that case using import-dsc will work if you create something that builds a source package, do so, and then import it to a fresh branch
<pitti> ok, so it seems for the initial packaging I shouldn't start with bzr right away then?
<james_w> the functionality is not yet exposed at the UI level that makes it easy to do so
<mvo> heh :) cron segfaults during a karmic->lucid upgrade
<bryceh> mvo, erk!
<dholbach> pitti: do you have an idea why https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-harvest-next-steps and https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-loco-directory-development are not on http://people.canonical.com/~pitti/workitems/canonical-community-ubuntu-10.04.html ?
<pitti> dholbach: neither of those is milestoned for ubuntu-10.04
<pitti> so they'll just appear on the "entire release" chart
<pitti> http://people.canonical.com/~pitti/workitems/canonical-community.html
<dholbach> bah, I'm sure they were
<dholbach> thanks pitti
<pitti> dholbach: or, more precisely, they have not any work items milestoned to ubuntu-10.04
<pitti> (the milestone of the spec is merely the default milestone of WIs)
<dholbach> jono: ^
<jono> dholbach, I am positive they were
<dholbach> jono: ok, I'll change it
<jono> dholbach, this is going to screw our burndown :P
<dholbach> C'est la vie
<dholbach> both specs are looking quite OK
<dholbach> in terms of done items
<jono> dholbach, cool
<jono> dholbach, so long you plough the actions and get us in shape, I am happy :)
<dholbach> jono: no pressure, eh?
<jono> dholbach, none at all :)
<jono> you will tock 'em, I have no doubts, you always do :)
<jono> rock, rather
<dholbach> jono: now I wonder how many others are not on the list ;-)
<jono> dholbach, from what I can tell, pretty much all of them are
<jono> at least all the key ones I am tracking
<dholbach> alrightie
<jono> dholbach, ok, I am heading to bed
<dholbach> thanks pitti
<jono> night!
<jono> thanks pitti :)
<dholbach> jono: sleep tight
<beuno> (for Lucid, that is
<beuno> (window change fail)
<cjwatson> directhex: I would be overjoyed if you did a grub2/lucid theme
<asac> mdeslaur: no ... go ahead
<directhex> cjwatson, is there an art style finalized yet? i was thinking something which has the same l&f as the login screen would be good
<cjwatson> kirkland: no objection in general but (a) grub2 uses cdbs patches (b) please send the patch upstream (c) please commit to bzr (d) surely it should fail if there's no qemu available?
<cjwatson> lool: I'm not familiar with it - could you file a bug with a description of the flag you're trying to support, please?
<cjwatson> directhex: not sure, I don't think so
<directhex> cjwatson, i'll leave it for now then - at least the gfxmenu stuff should be mostly bug-free now, thanks to the testing i did on debian
<directhex> by "bug free" i don't mean "won't explode" i mean "will display what i actually put in the theme file in kvm", of course
<lool> cjwatson: lp #519228
<ubottu> Launchpad bug 519228 in binfmt-support "Support for C flag" [Undecided,New] https://launchpad.net/bugs/519228
<lool> cjwatson: Didn't test it, but am thinking of something like http://paste.ubuntu.com/372364/
<lool> cjwatson: Correct me if I'm wrong, but as long as I'm adding optional fields and I deal with them being empty, I don't need to deal with upgrade issues for /var/lib/binfmt/* contents?
<lool> (I don't quite get why that's a different format from /usr/share/binfmts/*)
<cjwatson> lool: I'd like to think about this a little bit asynchronously if that's OK - it's a little while since I worked on this
<dupondje> mvo: could you check this patch for me : https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 ? Want it into ubuntu since karmic alpha 2 ;)
<ubottu> Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Low,Triaged]
<lool> cjwatson: That's fine; I'll finish my patch because I have the contect in mind and we will rediscuss whenever you have slept over the request
<cjwatson> lool: (and I'd like to make this change in Debian of course)
<lool> Notably, it might well be that you want --flags instead of --credentials
<lool> cjwatson: Oh of course; did you want me to open a Debian bug?
<cjwatson> doesn't matter
<mvo> dupondje: thanks, I have a look (but busy ATM)
<dupondje> mvo: no problem, waiting for it so long now ;) but its a small patch. I also builded it, and it works perfect
<mvo> dupondje: yeah, it looks like its not a big issue :)
<mvo> dupondje: thanks for fixing it!
<dupondje> mvo: well got fustrated about it, so fixed it myself ;)
<cjwatson> james_w: I've upgraded lp:~ubuntu-core-dev/gfxboot-theme-ubuntu/mainline to 2a; does lp:ubuntu/gfxboot-theme-ubuntu point to that, and if not can it?
<lool> james_w: I have a small issue with pushing to ubuntu branches: I pushed to lp:ubuntu/binfmt-support/lp-519228 but that seems to have been mapped to lp:ubuntu/lucid/binfmt-support
<lool> (I initially branched lp:ubuntu/binfmt-support, debcommit, bzr push lp:ubuntu/binfmt-support/lp-519228, but the bug report shows and links to lp:ubuntu/lucid/binfmt-support)
<lool> I just tried pushing to lp:ubuntu/lucid/binfmt-support/lp-519228 as well, and bzr told me "No new revisions to push." so I guess that too is mapped to the lucid branch
<lool> I'll push to my namespace instead
<lool> Bah lp:~lool/ubuntu/binfmt-support/lp-519228 => No such distribution series binfmt-support.
<lool> lp:~lool/ubuntu/lucid/binfmt-support/lp-519228 worked
 * lool uncommits lp:ubuntu/binfmt-support
<james_w> lool: lp:~lool/ubuntu/lucid/binfmt-support/lp-519228
<james_w> lool: please file a bug on bzr that it allowed you to do that
<lool> james_w: Yup, that's what I used in the end
<cjwatson> lool: not that I'll be able to merge that anyway ...
<james_w> it may be an LP bug, but something is broken if it allowed you to push to that given that url
<cjwatson> lool: sadly, lp:ubuntu/binfmt-support does not share branch history with lp:binfmt-support.  the latter is a mirror of the branch I'm actually doing development in
<lool> cjwatson: There is no Vcs in the binfmt-support control, I thought I would be having multiple revisions for this work, but I ended up committing a single one, consider this a very expensive way to provide a patch  :)
<cjwatson> err, yes there is!
<lool> Uh
<lool> I wonder how I missed it
 * lool slaps forehead: I apt-cache show-ed instead of showsrc
<mvo> ev_: thanks for fixing #519206 you beat me by 1h :)
<ev_> mvo: sure thing :)
<lool> james_w: LP #519244
<ubottu> Launchpad bug 519244 in bzr "Allows pushing to lp:ubuntu/lucid/package/foo or lp:ubuntu/package/foo but silently remaps that" [Undecided,New] https://launchpad.net/bugs/519244
<james_w> thanks lool
<lool> thanks for your patience  :)
<MacSlow> any hints how to fix/avoid/work-around and "errorcode 2" from dpkg-deb --control for libglib2.0/-dev/-dbg libnih1 ?
<MacSlow> thanks in advance
<cjwatson> MacSlow: can you be more verbose about the exact problem, please?
<cjwatson> MacSlow: error 2 is "no such file or directory"
<cjwatson> but might not be in this case, if that's an error exit status from a script rather than from a C library function
<cjwatson> i.e. could be anything and you haven't given enough information to disambiguate
<MacSlow> cjwatson, I tried to update my desktop-machine with synaptic (lacking all lucid updates which happened during the week in Portland) and for the four mentioned packages I get this error reported for "dpkg-deb --control" presented in a dialog-box where synaptic probably just spits out stdout (or stderr)
<MacSlow> mvo, ^^^
<cjwatson> MacSlow: we need the exact message, not a paraphrase of it
<seb128> MacSlow, can you run sudo apt-get -f install
<cjwatson> I've never heard of dpkg saying literally "errorcode 2"
<seb128> and copy the log on paste.ubuntu.com
<MacSlow> crimsun, I'll try to get the english version of it... stand by
<cjwatson> it is better to post an exact translated version rather than a guessed English version
<cjwatson> the former is greppable; the latter is not
<seb128> MacSlow, LC_ALL=C sudo apt-get -f install
<MacSlow> cjwatson, seb128: http://pastebin.ubuntu.com/372425
<cjwatson> I think you just have a corrupted download then
<cjwatson> 'sudo apt-get clean' and try again
<MacSlow> cjwatson, hm... guess all those the nvidia/flash "sponsored" freezes today (while trying to download 1.4 GBytes worth of updates) hosed the .debs then?!
<cjwatson> it is possible for driver-induced crashes to cause filesystem breakage, yes, especially proprietary drivers
<seb128> MacSlow, what do you upgrade from and to what do have that much to download?
<MacSlow> ok... re-fetching 1.6 GBytes now :/
<cjwatson> superm1: bug 508173> is it possible to get an upgrade log with DEBCONF_DEBUG=developer set in the environment?
<ubottu> Launchpad bug 508173 in grub2 "postinst has errors with grub-probe that cause the system to stop booting" [Undecided,New] https://launchpad.net/bugs/508173
<seb128> MacSlow, note that apt-get clean will wipe all your cached debs, you need to download again
<seb128> too late for that ;-)
<MacSlow> seb128, it's my desktop (main working machine), which didn't see updates for a week (Portland)
<seb128> 1.6G in a week?!
<cjwatson> that's over twice as big as the .deb size for a complete default install ...
<MacSlow> seb128, how do I know
<MacSlow> seb128, cjwatson: you're the repo masters with all the oversight... I've no clue what goes on there
<MacSlow> seb128, cjwatson: part could be that I've gnome and kde on this box
<seb128> I've no oversight of the zillion things you installed
<MacSlow> :)
<seb128> but I usually get some 300 meg in a week
<seb128> not 1.6G
<mvo> MacSlow: could you run md5sum on the debs?
<MacSlow> mvo, no... I'll not consider doing stuff like that as it side-tracks me too much... btw... re-downloading the fresh packages anyway now
<kenvandine> pitti, that is a very strange merge request
<pitti> kenvandine: james_w said it's a bug, and he'd handle it
<mvo> MacSlow: hm, ok. it might be a real bug hidding somewhere
<kenvandine> ok
<dantti> cjwatson: ping
<cjwatson> dantti: I replied to your e-mail
<dantti> cjwatson: yep I saw it, sorry for not putting what I had in mind
<dantti> cjwatson: I have just replyied to it
<dantti> i just thought it woud be simpler to explain on IRC
<cyphermox> cjwatson, I'm not sure if you're the right person to ask, but I sent my MOTU application to devel-permissions and the dmb, I'm not sure if it went through to the DMB address, but I can't see my message in the devel-permissions archives (I sent it on Feb 2)
<geser> cyphermox: your mail reached at least the dmb ml
<cyphermox> geser, thanks, just making sure :)
<cjwatson> dantti: this is way too long for IRC.  Please can we continue by e-mail in future
<cjwatson> cyphermox: thanks, I'm in the process of doing the minutes from the last meeting and catching up on associated actions
<saispo> anyone use virt-manager ?
<cyphermox> cjwatson, ok. When I saw you cleaned up the agenda I added myself in
<dantti> cjwatson: ok, np
<mdeslaur> saispo: I do
<saispo> mdeslaur: i think i've found why i can't create arm vm ;)
<mdeslaur> saispo: oh?
<saispo> i miss installing qemu-* :)
 * hyperair wonders if anybody managed to make a ppc vm
<mdeslaur> saispo: ah, yes, I think there's a separate package for that now: qemu-kvm-extras
<cjwatson> cyphermox: that's fine (and indeed best), thanks
<saispo> mdeslaur: it's true
<saispo> mdeslaur: have you tried to create a qemu-arm machine and try to boot it under a Debian iso image ?
<mdeslaur> saispo: no, I haven't
<ogra> saispo, use qemu-arm-static and use a chroot ... way faster than a full VM ... has issues with mono though
<ogra> (and feel free to drop by in #ubuntu-arm for issues ;) )
<saispo> ogra: ok, thanks
<dholbach> cjwatson: regarding the DMB minutes: the DMB can't be made owner of ~universe-contributors by the CC, only the TB can (MC is owner right now which is owned by the TB)
<persia> saispo: If you install the newest ubuntu-dev-tools, you can use pbuilder-dist or mk-sbuild-lv to create an emulated chroot.
<persia> hyperair: There is work going on to make emulated powerpc chroots work, but it's not complete.  Needs lots of merging from Debian.
<hyperair> persia: ooh cool.
<saispo> ok persia, will see that
<hyperair> persia: i tried running qemu with the openbios-ppc bios, but it kept hanging.
<saispo> and where i can find openbios for sparc and ppc ?
<persia> You need to get a new openbios-ppc: there's an issue with Soyuz that means we can't build it in Ubuntu right now :(
<persia> saispo: You need to find someone to build you one, or try using Debian's.
<saispo> ok
<saispo> thanks
<cjwatson> dholbach: if the CC tells us we may, then a TB member can change the ownership.  However what I heard seemed to indicate that this was something for the CC to authorise, which is why I didn't Just Do It
<persia> hyperair: If you're up for it, try looking at the Debian "qemu" package, and see what bits from the "qemu-user-static" binary you can merge with the Ubuntu "qemu-kvm" package.
<persia> cjwatson: The CC has authorised the action in a vote in a meeting, but didn't specifically authorise the TB to take that action.  I'm not sure how picky we ought be :)
<hyperair> hmm okay, if i've got time
<dholbach> cjwatson: gotcha, I will send a mail
<ogra> persia, i talked to vagrantc in portland, he said ppc is far from stable
<ogra> persia, dont pull it into pbuilder yet, i'll give you a heads up if i get one from him (he is doing the work on the static parts)
<persia> ogra: Yep.  Sparc is apparently even less well, and we can't currently build openbios for either, which makes using them tricky, *but* it's especially hard to fix when we don't have it available at all :)
<ogra> i dont think there is any work going on for a sparc static port yet
<persia> My big fancy plan for emulated build systems for developers was to generalise the wrapped debootstrap calls, and then generalise the links in the tools.  Some stuff won't work, but getting it to work or not work shouldn't affect the tools.
<persia> The SPARC static port is committed, but apparently doesn't work well enough to talk about much yet.
<persia> I don't know of any ia64 static work being done though.
<ogra> ah
<cjwatson> dholbach: I've followed up to the existing thread
<dholbach> me too :)
<cjwatson> dholbach: ah, so you did, mail delays :)
<smoser> persia, just wondering, why would you prefer tarball to directory in schroot ?
<vish> dholbach: hi... i noticed the branding for the 5-a-day team is missing.. since you are the team owner and the only one who can upload it.. could you have a look at > http://dl.dropbox.com/u/1325768/5-bold.png   or  http://dl.dropbox.com/u/1325768/5-thin.png 14px icons
<persia> smoser: 1) Takes up less space, 2) is one of the steps towards getting a working pbuilder->sbuild conversion script, which is itself a step towards helping pbuilder users use the ubuntu-security-tools stuff.
<persia> smoser: But I left the default to directory, just added support for --type file
<smoser> i'm not complaining, hadn't seen your changes, just wondering
<dholbach> vish: aren't they both the same? :)
<smoser> the big benefit of the directory (for me at lesat) is speed
<vish> dholbach: hmm , one is a bold 5 other one is thin ..
<persia> smoser: lp:~persia/ubuntu-dev-tools/more-schroot-types : it's complex enough I didn't want to commit without review.
<dholbach> vish: oh sorry yes
<vish> dholbach: just giving you options ;) you can choose which ever you like ;)
<dholbach> cool
<dholbach> vish: changed
<vish> dholbach: neat thanks :)
<dholbach> thank you
<smoser> persia, just quickly looking at diff, i like the general cleanups
<persia> Some of them are from kees, but I wanted to generalise.  I don't see any reason why we couldn't support all SCHROOT_TYPE variants, although only tgz advances my personal agenda, and I'm far too susceptible to episodes of yak-shaving to look at the rest right now.
<persia> smoser: If you'd like, adding in candidate templates and support for all of them would make this a significantly more generalised tool, and might even be suitable for inclusion in schroot rather than being separate.
<persia> (although that does remove the chance of abstracting the mirror detection code, etc. and sharing between pbuilder-dist and mk-sbuild (but I was kinda stuck on that anyway as writing code that works for both shell and python can be tricky))
<dholbach> zul: can you maybe change the maintainer field to use ubuntu-devel-discuss@ instead? (update-maintainer of the ubuntu-dev-tools package does it automatically for you)
<zul> dholbach: yep ill do that
<kees> persia: I've merged the "file" type now.  thanks!
<kees> heya BenC
<BenC> kees: hey dude
<persia> kees: Thanks.  I think it's now general enough to support the rest of the SCHROOT_TYPE values, if you find a volunteer ;)
<kees> persia: yeah, probably.  I'm curious to do timing tests now between lvm-snapshot, directory, and file.
<persia> directory will be fastest.  RAOF did some testing, and at least for some hardware, file is faster than lvm-snapshot.
<kees> lvm-snapshot ends really quickly because it just releases the snapshot, but directory doesn't have to go through dm redirection.
<kees> well, the main speed issue with lvm-snapshot is doing the build itself in the lv, which I side-step locally by mounting a common build directory.
<persia> But I think it depends on available RAM, etc.  Plus I suspect we ought have this discussion when we're both not pretending to pay attention to another channel :)
<kees> heh
<jcastro> kees: where do your ubuntu+1 slides live online?
<kees> jcastro: outflux.net/ul07/
<kirkland> pitti: where did the work item tracker go?
<pitti> http://people.canonical.com/~pitti/workitems/ (weeks ago)
<kirkland> pitti: oh, i was looking at macaroni
<pitti> kirkland: I just kept the macaroni one around for people not reading their mail fast enough :)
<kirkland> pitti: or updating their bookmarks :-)
<kirkland> pitti: thanks!
<pitti> kirkland: you're welcome
<paulliu> hi. "hornsey" is currently in Debian testing but still not in Ubuntu Lucid. Where can I query the auto-sync status?
<kitallis> the empathy contact window seems to retain it's last position for a while after snapping back into the panel, comes back to the same left corner position after a longer period of time ; in accordance with this bug : https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/144348
<ubottu> Ubuntu bug 144348 in empathy "Does not remember window position" [Wishlist,Triaged]
<kitallis> is this a WM problem, or is this application specific? I think pidgin does this alright.
<directhex> seb128, 38,780 source files processed by hand - copyright file for moonlight 2.0 written
<seb128> impressive!
<Laney> have fun reviewing that one
<persia> kees: re: common build directory: how does that work?
<kees> persia: http://people.canonical.com/~kees/schroot/
<persia> kees: Ah.  Do I end up with roughly the same thing by doing it in $HOME/src/${foo}
<kees> yeah, though without the extra script, it lacks clean up
<micahg> mvo: I have to talk to asac about the Firefox upgrade issue...I thought we needed transitional pacakges
<directhex> seb128, so now i'm blocking on an update from upstream which fixes a few licensing bugs plus firefox 3.6 support. should be out within a week or two - they're currently rushing a 3.0 preview release for the winter olympics but will do the 2.0 point release after that
<seb128> directhex, ok, no hurry, if we get it in lucid that's good
<directhex> seb128, once it's in, i'll ubuntu1 monodevelop and re-enable the moonlight authoring which we disabled in debian
<mvo> micahg: do you have a bug reference? I see a missing panel icon after the uprade
<micahg> mvo: bug 513074
<ubottu> Launchpad bug 513074 in firefox "profile is corrupted on FF 3.0.17 to 3.6 upgrade (Hardy 8.04 LTS only)" [High,Triaged] https://launchpad.net/bugs/513074
<mvo> micahg: thanks, I check it out, I have a upgrade test profile for this that I can run and see if its a universal problem
<micahg> mvo: I hope to have another release pushed out this week with the transitional packages in there to prevent the upgrade problem, if you can test after the next release, that would be great
<mvo> micahg: cool, please also check https://code.edge.launchpad.net/~mvo/firefox/fix-518747/+merge/18928 if you do a firefox upload
<micahg> mvo: I just rejected it due to merge conflicts, I'll add the replaces and conflicts when I add the transitional packages though
<sebner> directhex: will you update to 2.2.1 before?
<directhex> sebner, yes, it's on my TODO
<sebner> k
<kees> today's music care of dholbach!  thanks!  :)
<mvo> micahg: ok, that is fine with me, the important bit is to have a replaces: firefox-3.0 there to avoid the file-overwrite bug
<directhex> sebner, problem is not all the addins are 2.2.1 (some are still 2.2) so i need to double-check deps & re-upload everything
<nxvl> slangasek: just noticed that we don't have alpha 5 anymore, and i used to move to the devel release once alpha 5 was out, which one is the equivalent now, alpha 3?
<sebner> directhex: pretty much trouble so near to the FF, hmm? :\
<micahg> mvo: I realize that I should have fixed the title in the first bug
<dholbach> kees: eh?
<directhex> sebner, i'm sure seb128 will let it by if i flutter my eyelashes
<kees> dholbach: I just downloaded and am enjoying your first mix of 2010.  :)
<dholbach> kees: ah, thanks :-)
<seb128> directhex, sebner: doing some update should be ok yes
 * apw has just updated and am getting apopup on the gdm screen 'Install problem!  The configuration default for GNOME PowerManager have not been installed correctly"  anyone else seeing that?
<apw> (to lucid)
<mvo> asac: sorry, just noticed the conflict and micahg rejected already. I fix it
<asac> thx
<apw> bah _and_ i cannot login now
<mvo> micahg: I did a new proposal now that should fix the problems
<Laney> mvo: Is the conffile prompt on brltty ubuntu4 -> ubuntu5 expected?
<mvo> Laney: sort of, karmic (and before) -> ubuntu5 should work fine, but the versions in between are still prompting
<Laney> alright, no worries then
<mvo> Laney: TBH I'm not sure if its worth fixing, its lucid->lucid upgrades only that prompt
<Laney> I wouldn't be too concerned about that, only for stable->current upgrades
<dupondje> mvo: had any time yet ? :)
<micahg> mvo: sorry, for the trouble, it's merged in and we'll do another release later this evening
<slangasek> nxvl: alpha3 is the equivalent in some respects
<nxvl> slangasek: ok, thanks
<primes2h> pitti: Hello. Could you have a quick look at this please? A patch is attached. bug #394071 It needs a sponsor.
<ubottu> Launchpad bug 394071 in system-config-printer "new printer button looks like "create a new document"" [Low,Confirmed] https://launchpad.net/bugs/394071
<tjaalton> slangasek: hey, are you running lucid on a client with the nfs4/krb5 setup?
<slangasek> tjaalton: yes
<slangasek> tjaalton: why, are you fixing 480444? :)
<tjaalton> slangasek: hmm ok, I'm having issues with expired tickets hanging the client..
<slangasek> tjaalton: I haven't noticed this, since I get a ticket refresh every time I unlock my screensaver
<tjaalton> slangasek: yep, a while after I do that the session is frozen, and for instance running just 'ps' hangs. root can still access the shares
<tjaalton> now testing .33 and nfs-utils 1.2.2rc9
<superm1> cjwatson, i'll see what i can do to fetch that log.  should be doable
<slangasek> tjaalton: well, if I have no creds at all, trying to ls a v4+krb5 mount fails immediately for me
<tjaalton> slangasek: oh, and the whole $HOME is behind nfs of course. there are plenty of apps that go berserk when the tickets expire. gconf/gnome-settings-daemon being one
<tjaalton> slangasek: anyway, happy to hear it works for you, maybe our setup is broken somehow.. though hardy didn't have big issues with expired tickets
<tjaalton> maybe I should try to get a network trace as well.. someone adviced that using iptables to drop the outbound nfs traffic would recover rpciod after a while, but that didn't work
<cjwatson> superm1: ta
<rickspencer3> any trial guru around who has a moment to help me run it over one of my libraries?
<directhex> asac, did you get to the bottom of mono on lucid/arm issues? it was you who was looking, right?
<primes2h> pitti: wait, changed description.. bug #394071
<ubottu> Launchpad bug 394071 in system-config-printer ""New" printer button is not appropriate and it doesn't respect genre in Italian language." [Low,Triaged] https://launchpad.net/bugs/394071
<qense> I've got a problem with Indicator Application (C implementation) not using the actions as defined somewhere in the code. Instead it shows GTK+ stock menu items.
<qense> What is needed to properly associate the actions with the menu passed to AppIndicator?
<asac> directhex: i am debugging still
<Caesar> slangasek: do you know if it's possible to write an upstart job such that it'll kick the service upon a file changing?
<Caesar> More concretely, I'd like to restart gssd when /etc/krb5.keytab appears, disappears or otherwise changes
<slangasek> Caesar: AFAIK no
<Caesar> Drat
<cjwatson> sorry to DMB members about the list spam; my mail server seems to have gone a bit odd and delivered the same message multiple times
<mneptok> slangasek: fail. VORLON TAVUTNA CHOG!
<Caesar> cjwatson: you got a few minutes to talk about OpenSSH?
<cjwatson> Caesar: sure ...
<lifeless> is there a dedicated UEC channel ?
<persia> lifeless: I've seen occasional discussion on -virt and -server, but there may also be one.
<kamalmostafa> I'm having trouble doing a requestsync for 'clxclient'.   Any advice?...
<kamalmostafa>   $  requestsync --lp -d unstable -s clxclient lucid
<kamalmostafa>   E: Did not retrieve any changelog entries. Was the package recently uploaded? (check http://packages.debian.org/changelogs/)
<kamalmostafa> Yes, it was recently uploaded, but I see that the latest changelog (3.6.1-1.1) is present as of today at http://packages.debian.org/changelogs/pool/main/c/clxclient/current/changelog.
<slangasek> kamalmostafa: I can't reproduce this problem
<kamalmostafa> slangasek: Interesting.  I do still get the same problem, using the exact command line I pasted.  This is Karmic with ubuntu-dev-tools (0.81.1).  Your version?
<slangasek> using lucid, of course
<kamalmostafa> slangasek: Okay, and I see that lucid sports newer ubuntu-dev-tools than I've got.   I'll chase down -- seems likely to be the cause of my problem.  Thanks.
<slangasek> well, nothing in the changelog jumps out at me, but it might help
<kamalmostafa> slangasek: well, certainly the first thing to try anyway...  Let me fire up a kvm and see what happens.
<fagan> why is the git package called git-core ?
<StevenK> Since a package called 'git' already existed
<fagan> ah
<fagan> In lucid there is no git package in the repo
<StevenK> Ehhh
<Laney> yes, it exist*ed* at the time
<Laney> I believe there is a plan to transition git-core to git
<fagan> I just thought I should ask in the interest of simplicity
<seb128> directhex, Laney: any reason we don't use mono 2.6?
<Laney> 2.4 is the LTS branch
<Laney> from upstream
<seb128> 2.6 is no stable?
<Laney> stable yes, lts no
<seb128> ok
<seb128> so we will stay on 2.4 for lucid?
<Laney> yep
<Laney> and squeeze
<seb128> thanks
<seb128> I will do some tweaking to the versions page
<directhex> seb128, we've found the 2.4 branch very dependable, and guessed that the security guys would prefer the branch with a 5-year support cycle rather than the one with the "until we get bored" cycle
<directhex> seb128, if anyone asks, i try to run a supported repo with recent releases for LTS. it'll go live around the time lucid releases
<seb128> directhex, thanks, nobody is asking so far, I was just reviewing our versions table for lucid and wondering if there was a reason to keep an outdated version there
<seb128> directhex, seems to make sense if 2.4 is lts and not 2.6
<directhex> seb128, 2.4 as lts is what novell have been telling me. i guess because it's what ships in sles11, and in a paid supported addon for sles10
<seb128> ok
<jcastro> directhex: does that mean we lose file dir watching in banshee?
<crimsun> jcastro: no, watcher depends on mono >= 2.4.3
<directhex> the only major item we miss out on is the new debugger
<cjohnston> mbudde: ping
#ubuntu-devel 2010-02-10
<suji11> hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me?
<arand> suji11: #uubntu-motu would be more appropriate for packaging help.
<suji11>  arand: ok
<pabs3> does anyone know when the Debian import freeze for Lucid is?
<micahg> pabs3: Thursday
<pabs3> thanks
<tjaalton> slangasek: bah, still hangs with .33rc7. the session works for a while (terminal, access to home), but launching nautilus breaks it for good
<Speedy1> www.search2.net
<pitti> Good morning
<Keybuk> ev: confirmed; automation doesn't work with 20100210 either
<Keybuk> (or 20090209.1)
<ev> Keybuk: indeed, already looking into it.  Appears to be a casper bug, but I'm still digging.
<dholbach> bah, my desktop machine hung itself for the second time today and there's nothing in syslog
<dholbach> and gdm doesn't show up properly either
<seb128> dholbach, do you have plytmouth installed there?
<Keybuk> "hung itself" ?
<dholbach> Keybuk: like the mouse pointer does not move any more, I can't ssh in, music stutters like a broken record, etc :)
<dholbach> seb128: yes
<seb128> dholbach, try uninstalling it
<seb128> my box stop freezing since I removed it
<dholbach> seb128: will let you know in a bit
<sebner> seb128: the plymouth/gdm freeze seems fixed /here though. Just did a normal boot. (I used a workaround the past week)
<seb128> sebner, not there, I just did some testing for slangasek
<seb128> I got it 3 times in a row today
<seb128> until I uninstalled plymouth again
<dholbach> sebner: it works on my laptop (i386, intel graphics) too, just not on my desktop (amd64, nv)
<seb128> it's racy
<dholbach> Keybuk: but at least magic sysrq still worked
<seb128> so it will not happen every time
<dholbach> seb128: yay - problem "fixed"! ;)
<sebner> seb128: dholbach : Well, as I said, I was seeing it too the whole past week (with nvidia) but tried a normal boot today and it worked. Maybe it was just luck
<dholbach> I hope that'll fix the kernel/whatever hang too :-)
<seb128> dholbach, ;-)
<seb128> I blame it on Keybuk for forcing plymouth on everybody and running away ;-)
<sebner> dholbach: the funny thing is that on my box I'm seeing "self-healing" pretty often xD
<Keybuk> not heard of that one being plymouth related
<Keybuk> if X is up, plymouth shouldn't be running
<sladen> another excellent one is if you shut the laptop lid during boot, and then reopen it to try and log in...
<dholbach> Keybuk: I'm sure the hang is unrelated to plymouth :)
<seb128> Keybuk, launchpad bug #516412
<ubottu> Launchpad bug 516412 in plymouth "Pressing <Enter> causes X to freeze" [High,Confirmed] https://launchpad.net/bugs/516412
<Keybuk> only if your boot is very very fast and you never see plymouth
<seb128> Keybuk, it's still the same vt1 conflict issue I think
<Keybuk> like I said, only if your boot is very fast ;)
<Keybuk> otherwise X will be on vt7
<seb128> my boot is not very fast
<seb128> it's my d630
<seb128> it takes some 45 seconds to boot
<Keybuk> do you see the ubuntu logo?
<chrisccoulson> i get X running on vt7 too, and i still see it crash when hitting enter
<Keybuk> chrisccoulson: then that's unrelated to plymouth afaik
<chrisccoulson> Keybuk - when i have plymouth installed, I noticed that all my keyboard input gets routed to the VT that X is running on
<seb128> Keybuk, I see "Starting up..." for 15 seconds, "_" in text for 3 seconds, plymouth for 3 seconds, empty screen with xorg cursor for 3 seconds
<seb128> then session
<chrisccoulson> if i stop X, everything I've ever typed is on the underlying VT
<seb128> then box crash when I hit enter
<Keybuk> seb128: I can't see how that's caused by plymouth
<Keybuk> sounds more like an X bug
<seb128> I doesn't happen without plymouth
<seb128> so it's an interaction between both
<seb128> slangasek says that plymouth is not supposed to exit that early
<Keybuk> but plymouth has already exited by the time X starts, right?
<seb128> ie I should still have plymouth on the spinning cursor time
<dholbach> boohoooo, the machine hung again :-(((((
 * dholbach is very unhappy
<Keybuk> oh, does plymouth segfault for you?
<seb128> not that I know, at least it doesn't trigger apport
<seb128> but it's only displayed for some 3 seconds
<Keybuk> do you have a segfault message in kernel dmesg?
<seb128> ie it goes away before having xorg displayed
<Keybuk> yeah, sounds like plymouth crashed
<seb128> no crash mention in the logs
<seb128> it's a shame that the only 2 people not getting that issue are slangasek and you ;-)
<seb128> in any case I can get debug informations if you need some
<seb128> it happens pretty consistently there
<Keybuk> I'll take a look after FF
<seb128> ok thanks
<dupondje> mvo: had some time yet ? ;)
<mvo> dupondje: still on my list, but todo should be fine
<mdz> is anyone else getting emailed about build failures in the kubuntu-ppa-staging PPA?
<sbeattie> mdz: oh yes. It's going to the ubuntu-reviews list, for some strange reason.
<mdz> Riddell: ^^
<persia> I think it's also going to all members of some group, to which kubuntu-devel belongs, and hitting ubuntu-core-dev as a result.
 * Keybuk wonders why he's now getting kubuntu build failure logs in his inbox
<Tm_T> we thought you haven't had enough mails yet
 * Tm_T hides
<Keybuk> tm_T: I'll forward you the 2,000 odd mails in my LP folder shall I? :p
<Tm_T> Keybuk: sure, I already have several thousand unread mails here
<maxb> Which package determines that Ctrl+Alt+F1 means VT switch when in X? I'm trying to determine what changed on my lucid system such that it now VT-switches with plain Alt+Fx even when in X
<Keybuk> maxb: linux-image-generic...
<Keybuk> actually I think the Ctrl-Alt thing may be xorg-server ;)
<maxb> Was about to say... didn't think I'd updated the kernel in the last few days
<Keybuk> it's not an update or change
<Keybuk> it's a bug
<Keybuk> I suspect this to be the same bug that causes people's X servers to crash when they press Enter
<maxb> crash as in display freezes on the last displayed image? I've seen that too
<maxb> *blink* and the password I typed into gdm was displayed after the Login: prompt from a text getty after I quit X
<Keybuk> yeah
<Keybuk> you have the same bug then
<seb128> maxb, uninstall plymouth...
 * maxb does that
<tkamppeter> I need help: When there are updates available, update-manager gets somehow started automatically, probably via D-Bus. I want to do so with the firmware installation tool of HPLIP. Someone knows how this works?
<tkamppeter> Can I use libnotify for that?
<cjwatson> it's done explicitly in update-notifier; grep that package and you should find it
<tkamppeter> cjwatson: Thanks
<pitti> tkamppeter: jockey recently grew the ability to listen for "needs firmware" uevents, and launch if it found something (currently used for  DVB-T sticks, which need firmware)
<pitti> (the listening to those firmware events is also implemented in update-notifier)
<tkamppeter> pitti, I have the following situation:
<tkamppeter> HPLIP recognizes with the UDEV rule /lib/udev/rules.d/56-hpmud_support.rules whether a printer needs a proprietary plug-in in order to work with HPLIP.
<tkamppeter> pitti, the udev rule simply runs "hp-mkuri -c" with the model name of the discovered printer in an env variable.
<tkamppeter> pitti, hp-mkuri checks whether the printer needs the plugin, and if yes, it simply generates a notification uing libnotify, telling the user to run the appropriate utility (which is part of HPLIP, "hp-plugin").
<tkamppeter> pitti, I want that hp-mkuri starts the utility directly in that case.
<tkamppeter> pitti, and that with a not too big patch on hp-mkuri, so that I can contribute the patch upstream to HPLIP.
<pitti> tkamppeter: how does it currently connect to libnotify? udev rules run as root, and are not attached to a particular user (session)?
<pitti> tkamppeter: ah, so it's not "firmware" in the linux sense? (/lib/firmware/)
<pitti> tkamppeter: can you please put /lib/udev/rules.d/56-hpmud_support.rules in a pastebin? (sorry, I don't have it installed)
<tkamppeter> pitti, no, the firmware is not installed into /lib/firmware and the plugin can contain other things than firmware, like color profiles or binary-only driver add-ons.
<pitti> tkamppeter: ok, so it's more like a general package
<pitti> tkamppeter: that sounds like a case for jockey, except that it doesn't do hotplugging without further support (from update-notifier)
<tkamppeter> pitti, http://pastebin.ubuntu.com/373145/
<pitti> RUN+="bin/sh -c '/usr/bin/hp-mkuri -c &'"
<pitti> ??
<pitti> why doesn't it just run hp-mkuri straight away?
<tkamppeter> pitti, here is the source of hp-mkuri: http://pastebin.ubuntu.com/373147/
<tkamppeter> See especially the notify() function which generates desktop notification bubbles via libnotify.
<pitti> tkamppeter: so, adding this match to update-notifier looks straightforward (the firmware bit already listens to gudev and has an event handler)
<pitti> (and drop that rule)
<tkamppeter> pitti, I do not know why the UDEV rule launches the program through a subshell, when I run hp-mkuri manually it exits already while the notification bubble is still there.
<pitti> tkamppeter: I meant, why does it need that sh -c & hackery?
<pitti> tkamppeter: but anyway, if the rule goes away in favor of changing update-notifier, it won't matter anyway
<tkamppeter> pitti, perhaps due to its non-zero exit codes, but for that one could also do "hp-mkuri || :"
<pitti> it shouldn't care
<soren> Do we do anything to reduce swappiness when swap is on an SSD?
<ogra> soren, i doubt that, usually the controller should care with recent SSDs
<soren> ogra: What do you mean?
<ogra> soren, on recent SSDs the controller does the wear out levelling
<soren> Ah.
<ogra> so it shouldnt matter what your swappiness is set to with newer HW
<cjwatson> mvo: do you know what's going on with the return of bug 507842?  I'm seeing it here too
<ubottu> Launchpad bug 507842 in python-central "Does not honor XS-Python-Version if debian/control contains a empty line before the Source: line" [Medium,In progress] https://launchpad.net/bugs/507842
<tkamppeter> pitti, I would like more to modify the notify() function in hp-mkuri as this is more streamlined with upstream. I do not need to add a dependency on update-notifier, so it is easier forgetting it accepted upstream.
<ogra> soren, indeed there is that grey area of SSDs that dont do that ... i know cking did a lot of SSD work, he might be able to tell you what is on/off wrt SSD handling today
<persia> ogra: That heavily depends on the filesystem used and the filesystems supported by the FTL (although many common FTLs do support ext2/3 now)
<ogra> persia, swap is swap :)
<ogra> unless you use a swapfile on top of a filesystem indeed :)
<soren> persia: FTL?
<persia> ogra: Ah, right.  I have no idea if any available FTLs treat swap well.  I seem to remember a discussion regarding using swapfiles to work around that.
<persia> soren: Flash-Translation-Layer : is the embedded computer that sits between the disk interface and the flash.
<pitti> tkamppeter: this uses some weird trick to talk to an user session; I don't even see how it is supposed to work in the first place; it doesn't even do setuid(), let alone dbus connections to any user's session
<mvo> cjwatson: re 507842> I have a look
<pitti> tkamppeter: the update-notifier support would be ubuntu only indeed; nothing for upstream
<ogra> one solution with older SSDs was to have a swapfile and copy that around all the time ... i played with that, but thats horribly slow and wasteful
<persia> Another solution is to use raw flash and UBI, but that requires motherboard support (and separate flash)
<ogra> well, or use a modern SSD :)
<ogra> with a proper controller
<ogra> its a matter of price
<tkamppeter> pitti, you mean libnotify uses this weird trick? notify() in hp-mkuri only calls functions/methods of libnotify.
 * soren thinks his Intel X-25M is modern enough
<ogra> yeah, definately
<soren> Wow. This thing boots fast!
<ogra> soren, bootchart ?
<persia> soren: Check with Intel regarding swap support in the FTL.  You may find you want a swapfile.
<pitti> tkamppeter: yeah, and that's what I don't understand; I can't believe that this works at all
<ogra> soren, i have a samsung, with the upgrade to lucid my system went from 45 to under 10sec
<persia> (But you don't have to copy the swapfile around with an FTL that supports the underlying filesystem)
<soren> ogra: Yeah, I'm way under 10 sec.
<tkamppeter> pitti, is libnotify shouting into the D-Bus and some user session daemon (notify-osd?) is listening and showing the bubbles?
<ogra> soren, i'm talking desktop though :)
<soren> ogra: Me too.
<ogra> wow
<pitti> tkamppeter: it's not "the" d-bus; notifications are happening on the session bus, which is per-user
<pitti> and an udev rule doesn't have their addresses
<soren> ogra: It feels way less than 10 sec, at least. /me is doing a bootchart now.
<pitti> tkamppeter: did you test that this current rule actually works?
<ogra> soren, temporary use autologin to get reliable measures
<soren> ogra: I'm using ecryptfs, so no can do.
<soren> ogra: Oh, i guess I could create a dummy user to test it.
<cjwatson> mvo: ta
<ogra> my fastest was 8sec so far ... but it went up a little with the latest plymouth changes
<tkamppeter> pitti, yes. I have the HP LaserJet 1020 which needs firmware. I have removed the plug-in and then power-cycled the printer and I got a notification bubble.
<ogra> its constantly around 9.5 now
<tkamppeter> pitti, the bubble showed 30 sec.
<pitti> magic
<tkamppeter> pitti, and the bubble is in notify-osd style (black transparent with white text).
<tkamppeter> pitti, the magic must be inside libnotify.
<pitti> apparently so
<tkamppeter> pitti, it works both by power-cycling the printer (then hp-mkuri runs as root) and by calling hp-mkuri on the command line (then it runs as me).
<mvo> lool: hi, do you have a moment to talk about the latest python-central changes?
<pitti> tkamppeter: so, you can't use libnotify to launch a program in the user session, so if you want to do that, you need to patch update-notifier
<tkamppeter> pitti, I do not know enough about the capabilities of libnotify, perhaps it can.
<pitti> tkamppeter: with notification-daemon you could attach an action, which could then launch a program
<pitti> but notify-osd doesn't have actions
<tkamppeter> pitti, notification-daemon is not used in Ubuntu any more?
<pitti> tkamppeter: not by default
<tkamppeter> pitti, and hplip has a working dbus server only if hplip-gui is installed which is also not done by default in Ubuntu.
<pitti> tkamppeter: the session d-bus is launched by gnome, independent of hplip-gui
<tkamppeter> pitti, how can I make use of the session d-bus the simplest way to let the udev rule launch an interactive program?
<pitti> oh, you mean it exports a service over dbus, nevermind
<pitti> tkamppeter: you can't
<pitti> tkamppeter: you need a program in the user session to listen to udev events (such as update-notifier)
<pitti> which then can launch a program
<tkamppeter> pitti, how will it work by using update-notifier?
<tkamppeter> pitti, does it require a change in update-notifier?
<pitti> tkamppeter: update-notifier already sets up a handler for udev events (currently for firmware); this needs to be extended to match on that printer
<pitti> tkamppeter: yes, it does
<tkamppeter> pitti, is there some general d-bus listener in the user's desktop session which I can use without modifying it?
<pitti> tkamppeter: no, mvo and I have always talked about this, but we never got to that
<pitti> tkamppeter: update-notifier should be fine, the code is our's, and easy
 * pitti needs to run out for some 30 mins
<Keybuk> long-term, the idea would be that Upstart could be that general listener, even in the desktop session case
<Keybuk> but that's YEARS off
<tkamppeter> pitti, OK, can you do the changes on update-notifier?
<mvo> tkamppeter: what is required? I can probably do it too
<tkamppeter> mvo, the program hp-mkuri (written in C, http://pastebin.ubuntu.com/373147/) should send a message to somewhere telling that a certain command line should be executed in the user's session, to run a GUI application.
<tkamppeter> mvo, the command line to be called is not a straight command line but a shell script one-line, like "if python -c 'import PyQt4.QtGui' 2>/dev/null; then gksu -- hp-plugin -u; else gksu -- xterm -T 'HPLIP Plugin Installation' -sb -rightbar -e hp-plugin -i; fi" so that it works on all Ubuntu systems.
<mvo> tkamppeter: but the command line is not send as wel, right? that will be encoded in the session and the singal just is there to know which one to pick ?
<mvo> tkamppeter: so when a signal like "plugin_installation_required" then u-n should call the above command?
<tkamppeter> mvo, one could send the command line, but one could also send only a signal. The command line does not depend onm the printer model or on its connection type.
<tkamppeter> mvo, but I would like that the HPLIP Ubuntu package provides this command line, because the command line can change with changes in future HPLIP versions.
<mvo> tkamppeter: sending a commandline like this is scary, I would prefer to have it encoded inside u-n
<mvo> tkamppeter: so just the signal, if future version require a different one, then I'm happy to update update-notifier
<tkamppeter> mvo, we could put it into a file which is part of the hplip package, and the part of u-n which executes it, reads this file,
<mvo> tkamppeter: thats ok
<chrisccoulson> mvo - on the topic of u-n - do you think u-n should check it is on the active console before doing things like launching update-manager and showing the reboot dialog?
<mvo> chrisccoulson: yes, good idea!
<chrisccoulson> mvo - want me to provide a patch to do that?
<chrisccoulson> (if i get the chance)
<mvo> tkamppeter: I can make the required changes if you give me the signal name
<mvo> chrisccoulson: YES :-)
<chrisccoulson> cool, i'll try and look at that :)
<chrisccoulson> right, lunch time. bbiab
<tkamppeter> mvo, can you tell me where I should put the file and how to name it? Do not make it a conffile (not in /etc/) as it is only package- and not user-/system-dependent and so conffile update complications should get avoided.
<tkamppeter> mvo, I do not have a signal name yet and also do no know how to send such type of signal. Can you tell me what I have to do?
<mvo> tkamppeter: ok, lets take that off the channel into private conversation then. I can help with that
<tkamppeter> mvo, OK.
<lool> mvo: Sure, but I'm about to go for lunch
<lool> mvo: Do you have issues with them?
<mvo> lool: I have a debdiff for review that fixes the most recent change http://paste.ubuntu.com/373188/ - I think its still not ideal, but works in my tests
<lool> mvo: That's odd, I tested the code and it worked for me; do you have a sample control where it fails?
<mvo> lool: sure, try the atspi one
<lool> mvo: Oh it's comments
<mvo> lool: the problem is that paraborder is set to "0" on the first line that is not a \n - but that means that control files with # this is autogenerated\ndo not\nedit\n\n will not work
<mvo> lool: so if you are fine with the above debdiff I will upload now and rebuild pyatspi
<pitti> re
<lool> mvo: how about http://paste.ubuntu.com/373190/ instead?
<pitti> mvo, tkamppeter: we shouldn't use hp-mkuri in the middle, I think; update-notifier can just listen to the device event directly and fire up the gui
<lool> mvo: Sorry about that BTW, I forgot to handle comments, but I wanted to stop parsing of XS-PV in binary packages
<mvo> lool: yeah, that is fine as well
<lool> mvo: Ok; I think my change is closer to what dpkg-dev does
<lool> see /usr/share/perl5/Dpkg/Cdata.pm
<mvo> lool: fine with me
<lool> mvo: uploading
<lool> done
<lool> mvo: Sorry again for the trouble
<lool> mvo: Next thing on my list would be to turn on include-links by default in a PPA
 * lool lunch &
<mvo> lool: nice, thanks
<tkamppeter> pittim I do not know whether it is a good idea, as the UDEV rule is also subject to change with the HPLIP package, and so hplip should provide it.
<tkamppeter> pitti: ^^
<pitti> tkamppeter: make the udev rule ENV{ID_HPLIP_CHECK}="1" and only test the property in update-notifier, not the vendor/product ID directly?
<mvo> tkamppeter, pitti: we can make u-n run a script provided by hplip when we get such a event
<pitti> mvo: I thought that was by and large already there?
<mvo> pitti: yes
<mvo> pitti: I just wanted to decouple what is run from the u-n code, so that hplip can provide the command in a script
<pitti> that makes sense
<tkamppeter> pitti, mvo, hp-mkuri is needed to check whether a download of the plugin is really necessary. It sends notifications only if the HP device really needs the plugin and if the plugin is not yet installed.
<mvo> and hp-mkuri needs to run as root? or could it run as the user?
<tkamppeter> pitti, mvo, therefore I want to send the signal out of hp-mkuri, to not need to re-implement how to determine which device needs the plugin.
<pitti> mvo: does u-n listen to the system bus?
<pitti> if it does, hp-mkuri could send a signal to the system bus which u-n could pick up
<tkamppeter> pitti, mvo, hp-mkuri works also running as me. It gets the model by env variable, so it does not need to access the printer.
<tkamppeter> pitti, mvo, so you can see how the notification looks like by running: hp_model='HP LaserJet 1020' hp-mkuri -c; echo $?
<tkamppeter> pitti, mvo, no printer needs to be connected for that.
<mvo> tkamppeter: if its enough if it runs as the user we could just make it part of the script in hplip that u-n triggers ?
<tkamppeter> Yes, then u-n can trigger the script on any HP printer, simply when /lib/udev/rules.d/40-hplip.rules has set ENV{ID_HPLIP}="1"
<tkamppeter> Only problem is that we also need to know the printer model somehow without the script needing to re-detect.
<tkamppeter> hp-mkuri needs the model in an env variable. /lib/udev/rules.d/56-hpmud_support.rules has it simply at hand.
<tkamppeter> pitti, mvo, ^^^^
<pitti> asac: so it's still necessary to apply dozens and dozens of thumb2 patches to all kinds of packages? I thought that got fixed in gcc proper?
<ogra> pitti, that doesnt fix the broken code that uses hardcoded asm
<pitti> ah, so that's not just the workaround any more that we applied to gtk and such
<ogra> there are lots of packages that use asm to add arm support, asm thats not supported in thumb2 mode
<asac> pitti: not sure what you mean
<ogra> pitti, https://wiki.ubuntu.com/ARM/Thumb2
<asac> pitti: there was a implicit-it fix that helped for a good bunch
<asac> the rest is assembler that isnt valid and needs to get ported
<ogra> pitti, look at "assembler errors" at that wikipage
<asac> pitti: could you upload postgresql at some point before alpha3?
<asac> iirc my patch is fix committed there
<pitti> asac: I meant thsi: http://launchpadlibrarian.net/36400628/glib2.0_2.23.0-1ubuntu1_2.23.0-1ubuntu2.diff.gz
<asac> pitti: https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList ... thats the fulll list of packages with assembler issues
 * asac  checks
<pitti> asac: yep, can do, it went to testing right before the sprint
<asac> pitti: yes
<asac> thats the kind of patches we do
<asac> atomics
<asac> and other stuff
<asac> for atomics we can replace assembler with gcc atomic built-ins
<asac> for other stuff we need to add different assembler
<asac> https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<asac> thats the howto
<lool> pitti: the glib fix is upstream now
<lool> It's not a patch anymore
<asac> right
<pitti> ah, I remembered that it was a workaround for a gcc fix
<pitti> thanks
<asac> pitti: there was something else ... called "implicit-it"
<lool> It's a workaround to use gcc's functions instead of the builtin assembler implementation
<asac> we added that to a few packages in the beginning, but then doko made that default for gcc
<lool> Oh right, that's probably what pitti recalls
<asac> yes
<tkamppeter> pitti, mvo: Any comments on my last messages?
<james_w> was there anything that stops us from uploading v3 formats to lucid directly?
<james_w> does that LP bug mean that you will only be able to upload -0ubuntu1 packages?
<cjwatson> v3 (.orig).tar.gz ought
<cjwatson> to work
<james_w> but not .bz2?
<cjwatson> .bz2 and others were believed to be buggy, yes
<james_w> ok, I'll stop implementing it then :-)
<cjwatson> ?
<cjwatson> it should be fine for native packages
<cjwatson> which was the one I particularly cared about :-)
<cjwatson> (dpkg)
<james_w> sorry, I mean I'll stop implementing the bit that makes v3 source packages with .bz2 tarballs
<james_w> I have the import part
<cjwatson> james_w: ah, right
<james_w> I've added a --v3 flag to merge-upstream that will make it not repack .bz2 tarballs, should be good for this release
<james_w> we can make it more automatic when the toolchain is up to it
<cjwatson> james_w: pristine-tar can repack bz2 - it's xz it has trouble with, if that's the problem you mean
<cjwatson> james_w: is there a current bzr-builddeb release branch that doesn't require bzr 2.1?
<james_w> cjwatson: that too, but I don't want to automatically create packages that will lead to problems later with Launchpad
<cjwatson> mm, fair enough
<james_w> cjwatson: no, unfortunately not. You can just edit __init__.py to comment out that block if you want.
<james_w> it's for the changelog merge support
<cjwatson> I just reverted to r398 :-)
<mvo> pitti: does "dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedFirmware" in the backend as a singal name make sense to you? for signaling u-n?
<sabdfl> Processing triggers for initramfs-tools ...
<sabdfl> update-initramfs: Generating /boot/initrd.img-2.6.32-12-generic
<sabdfl> cpio: ./lib/udev/firmware.sh: Function stat failed: No such file or directory
<sabdfl> update-initramfs: failed for /boot/initrd.img-2.6.32-12-generic
<sabdfl> should I be worried about that?
<sabdfl> just happened on an update, i'm reluctant to reboot till i can get it sorted
<sebner> sabdfl: did the update fail or did you just read the message? Because I did a update some minutes ago (with gui) without problems
<sabdfl> hmm.. was doing it under aptitude. i have some ppa's but don't think there's a kernel package in 'em
<sabdfl> it did say i needed to do dpkg --configure -a
<sabdfl> so i think it failed
<sebner> sabdfl: oh, seeing it too now. I don't use PPAs so ..
 * sebner waves at Keybuk 
<cjwatson> sabdfl: bug 519855
<ubottu> Launchpad bug 519855 in udev "update-initramfs fails: ./lib/udev/firmware.sh does not exist" [Undecided,New] https://launchpad.net/bugs/519855
<sabdfl> cjwatson: should i not reboot, or just go ahead?
<cjwatson> I'm not sure yet
<cjwatson> firmware.sh was converted to C
<ion> The old initramfs should still be there unchanged.
<sebner> cjwatson: It set it to confirmed and there is already a patch
<cjwatson> I was just writing the obvious patch :)
<sebner> ah heh
<cjwatson> sabdfl: you should be able to apply http://launchpadlibrarian.net/39011493/udev-firmware.patch and then 'update-initramfs -u' again
<sabdfl> cjwatson: i don't mind waiting for it to come via update if it won't hose my system on reboot
<sabdfl> or should i just be the guinea pig
<sebner> sabdfl: in the worst case you might be able to do the "workaround" in the recovery shell :P
<sabdfl> ok. if you don't see me again soon....
<kklimonda> I've just applied the patch, updated initramfs and rebooted - all works fine
<sabdfl> anybody reboot without the patch?
<kklimonda> sabdfl, someone on ubuntuforums did and it worked
<sabdfl> ok, see you all soon then, and thanks for the help
<sebner> kklimonda: bah, you are spoiling all the fun :P
<sebner> sabdfl: hf!
<cjwatson> reboot without the patch> that will depend on details of your hardware
<cjwatson> i.e. whether you need firmware to be loaded in order to mount the root filesystem
<cjwatson> most systems don't, but a few SCSI systems need the firmware loader
<cjwatson> as do things like NFS-root over network devices that need firmware
<kklimonda> cjwatson, hmm.. but if update-initramfs fails older version of initramfs is going to be used which still has /lib/udev/firmware.sh - at which point is it going to fail to boot?
<cjwatson> kklimonda: dunno
<cjwatson> mvo: do you want to mark foundations-lucid-dynamic-cdrom-handling as implemented (I figure you should get the karma!), or do you want to do something about the postponed WI there?
<mbudde> kenvandine: Is there python-appindicator 0.0.12 build for karmic?
<micahg> kees: ping re PIE for xulrunner
<cjwatson> Keybuk: BTW, you asked about my initramfs-tools branch at the end of last week; as far as I can tell I pushed the changes to bzr before I uploaded them, and everything looked up to date when I checked independently
<kenvandine> mbudde, oh... no... i need to do that in the ppa
<kenvandine> mbudde, i'll ping you when it is
<mvo> cjwatson: karma!
<mvo> cjwatson: I mark it implemented :) thanks. the remaining item is really small, I will see what I can do about it, but its not a big issue in the UI
<JFo> Keybuk, I wonder if you would be interested in looking over some "Deleting plymouth seems to have fixed/created issues" bugs I have on the kernel?
<JFo> for instance bug 518452
<cjwatson> mvo: righto
<ubottu> Launchpad bug 518452 in linux "[Lucid] No longer boots with new 2.6.32-12 generic kernel" [Medium,Triaged] https://launchpad.net/bugs/518452
<mbudde> kenvandine: great!
<dholbach> Riddell: could it be that kdebase in the kubuntu-ppa has ubuntu-devel@lists.u.c set as Maintainer address?
<t3rm1n4l> hi
<t3rm1n4l> i tried to load "record" module X11 on 9.10
<t3rm1n4l> but i couldnt
<t3rm1n4l> i heard it is broken
<BlackZ> t3rm1n4l, I think it's better to ask in #ubuntu - if you think it's a bug you can report it (see https://launchpad.net/ubuntu/+filebug/) thanks
<pitti> mvo: signal> looks fine to me
<dholbach> Riddell: kdepim4 and kdeutils4 too - we get mails on ubuntu-reviews because of that
<cjwatson> dholbach: isn't it just kubuntu-ninjas -> kubuntu-dev -> ubuntu-core-dev or some such
<cjwatson> some team along the kubuntu bit of the chain probably needs to get a contact address set
<dholbach> ah ok
<cjwatson> it's not particularly new, just that some stuff failed recently
<tkamppeter> keybuk, hi
<cjwatson> for those who were asking: I've done a new-source run, mostly.  I left out a few packages which collided with other source packages or whatever and needed some manual inspection; if you're still missing anything that's in testing and you can't figure out why it isn't in lucid, shout
<Keybuk> cjwatson: did you do contrib and non-free too?
<persia> cjwatson: swt-gtk came up earlier : does that apply only for NEW sources, or also outstanding syncs?
 * ogra just wants that one package that magically fixes all our bugs ... but i guess that wasnt even uploaded to debian yet :)
<sebner> cjohnston: alien-arena
<sebner> *cjwatson
<sebner> I guess that counts for contrib
<sebner> Keybuk: ^
<Keybuk> ogra: did you boot with "nobugs" on the kernel command-line?
<Laney> that's not new-source :)
<ogra> Keybuk, awww, that might be it :)
<tjaalton> slangasek: http://linux-nfs.org/pipermail/nfsv4/2010-February/012075.html
<tjaalton> slangasek: so we might want to pull those for the lucid kernel. I'll try the patches tomorrow
<cjwatson> Keybuk: yes
<cjwatson> persia: I didn't do outstanding syncs, is there a bug open about this one or is it just a sync from testing?
<cjwatson> ... the latter apparently.  I'll do it now
<persia> cjwatson: Just a sync from testing : I don't mean to escalate it if it's in the category of "not done yet" rather than "something is wonky".
<sebner> cjwatson: alien-arena is in testing
<sebner> not new-source though
<sebner> cjwatson: will you also do a normal autosync run?
<cjwatson> sebner: it's running right now
<cjwatson> sebner: yes, I already did alien-arena, thanks
<sebner> cjwatson: cool, thanks :)
<cjwatson> oh, maybe not, that's autosync not new
<cjwatson> I'll do it, it's running
<sebner> heh
<cjwatson> E: swt-gtk is trying to override libswt-gtk-3.5-java_3.5.1+repack~3-0ubuntu1 without -f/--force.
<cjwatson> persia: which of swt-gtk and eclipse should win?
 * persia runs off to get an expert opinion
<cjwatson> if the answer is swt-gtk, then eclipse still needs to be modified to stop building that package, or the next upload will fail
<persia> Right.  I've asked nthykier, but there may be some time before I get the answer.  Given the work being done to get a working eclipse into Debian before sqeeze freeze, I suspect there's a good chance that this is sortable with the next eclipse upload.
<persia> But at least now I know why it wasn't working.  Is the sync blocked in a useful way, or will this problem come inevitably?
<cjwatson> EPARSE?
<persia> cjwatson: Will the "E: swt-gtk is trying to override libswt-gtk-3.5-java_3.5.1+repack~3-0ubuntu1 ..." error continue to block the sync until I get an answer, or is it certain that eclipse needs to be modified and reuploaded?
<cjwatson> persia: we can override the error if instructed appropriately, although eclipse *should* still see an upload around the same time if at all possible; in the meantime, the sync will continue to fail
<persia> cjwatson: The sync failing for now is the best behaviour.  I'll sort it between those working on eclipse and those depending on swt-gtk and try to get the sync and upload organised this week.
<cjwatson> ok, blacklisted for the moment with a comment referring to you
<cjwatson> wow, somebody using .orig-COMPONENT.tar.gz (wmaker-data)
<persia> Thanks.  I'll file a bug to unblacklist once it's sorted.
<Keybuk> cjwatson: you can always count on those Window Maker guys to be ahead of the curve
<Keybuk> it's the way they cling onto a window manager that was popular in the 90s
<ion> keybuk: Our present desktop still clings onto the style of window management that was popular in the 90s. :-P
<Keybuk> ion: I've bitched about this a lot too
<geser> cjwatson: is there a list somewhere with failed autosyncs so they can get investigated?
<cjwatson> geser: sadly not, the toolset makes it hard to generate too
<cjwatson> what happens is you run sync-source.py -a and it falls over somewhere
<cjwatson> then you have to blacklist it and run sync-source.py -a, which starts over again from the beginning
<cjwatson> repeat until very bored
<geser> oh
<cjwatson> sebner: alien-arena runs into some crazy unpack failure too.  do you care about it?  http://paste.ubuntu.com/373384/
<cjwatson> this is dpkg-dev 1.15.4ubuntu2~0.CAT.8.04; not *that* old but I suppose it might have been fixed in dpkg since then
<sebner> cjwatson: I'll take a look
<cjwatson> blacklisted for now, anyway; FWIW the sync blacklist is here: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<sebner> cjwatson: local lucid pbuilder fails, dpkg-source -x works locally though
<cjwatson> who knows ...
<sebner> heh
<pecisk> it is known when Evo 2.29.x versions will roll in Lucid?
<persia> pecisk: Never precisely, because of the wide number of factors involved.
<seb128> pecisk, never
<seb128> 2.29 is a rewrite of many component
<seb128> switching bonobo to dbus
<seb128> and bonoboui to gtk
<seb128> we don't think it's stable enough for a lts
<seb128> and other distro will ship 2.28 for their lts as well
<seb128> ie rhel6
<pecisk> :(
<pecisk> well, it's understandable reasoing
<seb128> you will probably have a ppa for 2.30 somewhere
<pecisk> seb128, yep, I thought about it
<pecisk> so it's probably worth to roll out my own PPA for it then
<pecisk> thanks for info :)
<nxvl> kirkland: hey, are you around?
<nxvl> kirkland: i just reported this bug: Bug #520004, and tracker it down until a fix you made
<ubottu> Launchpad bug 520004 in initramfs-tools "Fail to Upgrade to Lucid due initramfs-tools broken package" [Undecided,New] https://launchpad.net/bugs/520004
<kirkland> nxvl: yo
<nxvl> it seems that /script/functions is missing
<kirkland> nxvl: i think that's a dupe
<kirkland> bug 519855
<ubottu> Launchpad bug 519855 in udev "update-initramfs fails: ./lib/udev/firmware.sh does not exist" [High,Fix released] https://launchpad.net/bugs/519855
<kirkland> nxvl: you can hack it by symlinking firmware to firmware.sh
<nxvl> kirkland: and the scripts/function thing is just a warning that can be ignored?
<kirkland> nxvl: i'm not sure; i know that the firmware thing will break you though
<nxvl> kirkland: just testing the firmware thing
<nxvl> kirkland: huh, it looks like it worked, thanks, i got the other message aswell tought, but it worked
<nxvl> kirkland: thank you
<kirkland> nxvl: no problemo
<smoser> slangasek, is there anything i can do for you for bug 504883
<ubottu> Launchpad bug 504883 in udev "job with "mounted MOUNTPOINT=/ and net-device-up IFACE=eth0" blocks boot" [Medium,Triaged] https://launchpad.net/bugs/504883
<smoser> i would really like to see it fixed sooner rather than later, as running cloud-init much earlier could cause some issues for me.
<Chipzz> directhex: you were at fosdem?
<directhex> aye
<Chipzz> cool :)
<slangasek> smoser: it's turned over to Keybuk now for follow-up with udev upstream
<smoser> is it something that will likely be fixed in alpha3 or beta1 ? or should i just plan on it not being fixed.  any thoughts?
<slangasek> smoser: ask Keybuk :)
<slangasek> if you're saying it *should* be fixed sooner in order to not push your changes back too far, we can milestone it, but you should still talk to Keybuk to see what he thinks our options are
<smoser> ok. thanks. I'll try Keybuk tomorrow at a more reasonable hour.
<pitti> urgh, our ancient lvm2 breaks more and more stuff :(
<pitti> kees: ^ is it still a possibility to merge it with Debian?
<persia> Do we at least have a good excuse to have an ancient lvm2?
<ogra> persia, *because*
<pitti> I guess just nobody had the guts/time to merge it
 * persia did specify "good"
<pitti> it's ancient, thus it's hard, thus it becomes even older, and harder
 * pitti waves good night
<kees> pitti: I was planning to merge today, unless you want to take it?
<kees> oh, no, you're sleeping. :)
 * slangasek chuckles
<micahg> kees: did you need us to backport the PIE build hardening to karmic and jaunty for xulrunner 1.9.1?
<kees> micahg: no thanks, I don't want to introduce changes like that for pre-lucid.
<apw> anyone else seeing their password in plain text in seahorse in an up-to-date lucid?
<apw> (for gpg)
<micahg> kees: great, it should go into lucid with the 1.9.1.8 release next week
<kees> micahg: cool
<ogra> apw, not here
<apw> ogra, what is with this machine
<ogra> adunno
<TheMuso> apw: Yeah I saw that yesterday.
<apw> TheMuso, not good ... gone again today?
 * apw updates to find out
 * TheMuso does also.
<shtylman_> \sh: I responded to the google perftools issue... its kinda unclear to me cause launchpad shows the package (libunwind)
<shtylman_> maybe its not built yet?
<EagleScreen> hi
<Guest94638> I see that usplash is in universe in lucid, is it going to be replaced by another tool?
<TheMuso> Guest94638: Plymouth has replaced usplash.
<Guest94638> I see
<directhex> asac, well, mono on arm built okay - any idea if it *works*?
<directhex> 325 test(s) passed. 39 test(s) did not pass.
<asac> directhex: not tried yet, isnt there a test suite run during build we could look at?
<asac> right
<directhex> hrm. wonder how that compares to karmic
<asac> directhex: what is the fail ratio on i386?
<directhex> 0 on i386/amd64
<directhex> 0 on ppc. 4 on sparc, 1 on itanium
<directhex> let's check arm on karmic
<directhex> 321 test(s) passed. 40 test(s) did not pass.
<directhex> aha, not so bad after all
<asac> ;)
<directhex> assuming it worked on karmic, anyway
<asac> directhex: is there a test summary in log so we can check what actually failed?
<asac> directhex: afaik, mono had issues on arm in karmic
<directhex> asac, yes, there is. http://launchpadlibrarian.net/39020256/buildlog_ubuntu-lucid-armel.mono_2.4.3%2Bdfsg-1ubuntu2_FULLYBUILT.txt.gz - search for "did not pass" and scroll up or down
<asac> hmm. often not really obvious  what it does
<directhex> oh... actually, search for "show time", that's where the suite starts
 * asac looks at exception6.cs
<asac> directhex: does that failed 512(2) mean that it returned exit code 2?
<directhex> honestly, i'm not sure. i've never really dug too deep into the test suite
<asac> kk
<ogra> hmm
<ogra> apart from lp-integration and nautilus everything built
<asac> assuming it means 2 ... it would mean that mono doesnt throw exception for overflow of Int.MaxValue
<asac> on arm :/
<asac> maybe i should really try --with-jit=no
<ogra> ** (/usr/lib/mono/2.0/gacutil.exe:9843): CRITICAL **: _wapi_shm_file_open: shared file [/root/.wapi/shared_data-huito-Linux-armv7l-312-12-0] open error: Permission denied
<ogra> fun
<asac> what is .wapi?
<ogra> no idea, directhex ?
<asac> hmm. weatherapi
<asac> python-pywapi
<directhex> i think it's a thing it uses for storing semaphores. i think you can disable it
<ogra> http://launchpadlibrarian.net/39023420/buildlog_ubuntu-lucid-armel.launchpad-integration_0.1.33_FAILEDTOBUILD.txt.gz
<directhex> hang on
<asac> but not sure, because that is python ;)
<crypt-0> does this have anything to do with monodevelop?
<ogra> why does it try to open /root/.wapi ?
<ogra> it shoudnt try to access /root on the buildd
<ogra> ** (/usr/lib/mono/2.0/gacutil.exe:2810): CRITICAL **: _wapi_shm_file_open: shared file [/root/.wapi/shared_data-palmer-Linux-i686-312-12-0] open error: Permission denied
<directhex> ogra, it's trying to do that on the buildd? i think we're supposed to be disabling that via debian/rules environment
<asac> yes. its proably something trying to load profile data ;)
<ogra> aha, same thing on x86
<ogra> directhex, yeah, the package is screwed on all arches
<ogra> seems it was completely repackaged in cdbs
<ogra> i wonder why
<ogra> - Revert from DH7 to CDBS and correctly do CLI build
<ogra> heh
<asac> who maintains that?
<asac> yeah .... great move ;)
<ogra> not as correctly as expected :)
<ogra> uploaded by robert_ancell
<directhex> aha
<directhex> ogra, to stop .wapi being an issue, it's neccessary to export an environment variable. i guess it's missing from launchpad-integration?
<ogra> likely
<ogra> well, i wont fix it tonight ;)
<asac> ogra: nautilus seems to be waiting for a builder (e.g. didnt fail)?
<directhex> yeah, seems the export is missing
<ogra> i just gave it back, it was failing before due to indicator-app not being done
<ogra> but i-a is published now
<directhex> export MONO_SHARED_DIR=$(CURDIR)
<ogra> next run should succeed
<directhex> ^^ add that to debian/rules for launchpad-integration
<directhex> should fix it
<Caesar> zul: ping
<TheMuso> 1/c
<seb128> ogra, asac: lpi uses cdbs for years
<ogra> seb128, then i wonder about that changelog entry
<seb128> ogra, asac: robert_ancell changed it to dh7 to fix a mono binding packaging issue but broke all cdbs magic rules on the way
<seb128> so we did revert to cdbs
<ogra> ah
<seb128> and fixed the mono build differently
 * ogra didnt know
<ogra> no, you didnt :)
<bdrung> can a core-dev unsubscribe u-m-s from bug #407649 please?
<ubottu> Launchpad bug 407649 in scim-anthy "Sync scim-anthy 1.2.7-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/407649
<seb128> ogra, they copied the debian wiki snippet
<ogra> export MONO_SHARED_DIR=$(CURDIR) seems to be missing according to directhex
<seb128> why do we need that?
<seb128> and is dh7 doing that for you?
<ogra> * (/usr/lib/mono/2.0/gacutil.exe:9843): CRITICAL **: _wapi_shm_file_open: shared file [/root/.wapi/shared_data-huito-Linux-armv7l-312-12-0] open error: Permission denied
<ogra> it tries to import stuff from /root
<ogra> same on all arches
<Laney> it is used for IPC afaik
<directhex> yeah, ipc semaphore nonsense
<directhex> it stores them in $MONO_SHARED_DIR/.wapi
<Laney> you want to export MONO_DISABLE_SHM = 1
<Laney> or use cli.make
<directhex> oh, that works too
<robert_ancell> cli.make required dh7 :)
<Laney> nah
<Laney> well, it exports DH_OPTIONS too, but I would hope that that's harmless
<Laney> if you do directhex's solution, you should make sure to clean up after it in clean:
<robert_ancell> Laney, DH_OPTIONS makes everything complain in <dh7
<Laney> what has that?
<Laney> and isn't it just a warning?
<Laney> a pointless discussion anyway since we are talking about one export :)
<seb128> RAOF has it all fixed apparently
<Caesar> I was wondering if someone would be able to sponsor an upload for me? It's a patch in #519119
 * robert_ancell wishes we could migrate everything to dh7 overnight
<RAOF> dh7 is much clearer when you're doing strange things :)
<persia> robert_ancell: Too much breaks right now, but the time is coming.
<ogra> robert_ancell, upload dh7-automigration
<ogra> (and hope it does what the name says :) =
<persia> robert_ancell: Make python-central dh7 compatible :)
<cjwatson> ... it isn't?
<Laney> someone should port the magic that is done by cdbs for gnomish things to DH7
<cjwatson> Laney: yes, definitely
<asac> bdrung: done
<bdrung> asac: thanks
<bdrung> asac: now you are my victim. ;) can you ack bug #517854 and sponsor bug #515230?
<ubottu> Launchpad bug 517854 in mozilla-devscripts "Sync mozilla-devscripts 0.20 (main) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/517854
<ubottu> Launchpad bug 515230 in lintian "Please merge lintian 2.3.3 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/515230
<seb128> robert_ancell, you don't want to migrate anything gnomish to dh7
<ogra> Caesar, why did you assign it to zul ?
<seb128> robert_ancell, we would loose language pack magic and all the gnome magic for gconf, schemas, etc
<robert_ancell> seb128, we need a dh7 sprint
<Caesar> ogra: because we'd talked about it
<ogra> ah
<Caesar> he'd also created the problem I was trying to fix
<Caesar> But he also said he'd upload it yesterday, and he hasn't
<seb128> robert_ancell, I've better to do that rewritting working packages with an another packaging system I think ;-)
<ogra> right, doing that now
<Caesar> awesome, thanks
<persia> robert_ancell: If you *do* want to migrate the gnomish stuff, you might find the recent changes in pkg-kde-tools a reasonable guide to how to do it.
<robert_ancell> persia, not planning on doing it any time soon but thanks for the tip
<ogra> Caesar, hmm, seems he already uploaded it
<Caesar> ORLY?
 * Caesar consults rmadison
<Caesar> Huh
<ogra> https://launchpad.net/ubuntu/lucid/+source/autofs5/5.0.4-3.1ubuntu3
<ogra> :)
<Caesar> Sorry to waste your time
<ogra> no waste happened :)
<ogra> i'm just idling in front of my lappie waiting for image builds to finish :)
<Caesar> Ah :-)
<cjwatson> the reason to migrate that stuff to dh7 is that then it would be possible to use that stuff in packages that are already using dh7 for other reasons
<cjwatson> (the vast bulk of which don't care, but a few do)
<cjwatson> or it seems likely that a few do anyway
<cjwatson> by "migrate to" I mean "add support for it in"
<highvoltage> hmm, I never realised that windows server also had its own release cadence: http://www.engadget.com/2010/02/10/microsoft-employee-raves-about-windows-next-in-a-blog-post-bl/
<slangasek> aaaah, why is seahorse prompting for my passphrase in cleartext?
<jdong> haha
<ogra> slangasek, apw complained about that before, he might have filed a bug (or TheMuso wh saw it too) i couldnt reproduce it here
<seb128> slangasek, I've a suspicious it's due to the upstream change to change the secure text entry widget
<seb128> slangasek, bug #520099
<ubottu> Launchpad bug 520099 in seahorse "gpg password prompt showing password in clear text" [High,New] https://launchpad.net/bugs/520099
<seb128> it's probably wrongly assigned to seahorse rather seahorse-plugins though
<slangasek> ok
<seb128> slangasek, http://git.gnome.org/browse/seahorse-plugins/commit/?id=ed6f046ff86e34925acb8ec045b150d26137d472
<seb128> would be my guess as faulty commit
 * slangasek fiddles the bug state
<slangasek> seb128: thanks
<seb128> np
<seb128> I will debug that tomorrow if nobody does before
<seb128> slangasek, I'm wondering if that's again a bug due to the input method you use
<seb128> or rather happening only when using one
<seb128> we had one of those previous cycle
<seb128> can you try without XIM_... or whatever the variable is called?
<seb128> GTK_IM_MODULE=xim
<seb128> slangasek, try unsetting GTK_IM_MODULE?
#ubuntu-devel 2010-02-11
<slangasek> seb128: I don't have GTK_IM_MODULE set anymore; the default GTK IM became less inadequate
<slangasek> (and if that caused the display of text to be completely changed, someone should be thwapped :)
<seb128> slangasek, ok, so I don't know why some people get it and some don't
<slangasek> yeah, dunno
 * ogra hugs popey for his eternal patience with karl f. larsen
<popey> haha
<Caesar> Where can I spectate?
<ogra> Caesar, ubuntu-users ML
 * bigon is wondering is upload that fix #516359 could not also contains fixes for #497497 and #472444
<ogra> https://lists.ubuntu.com/archives/ubuntu-users/2010-February/209987.html is worth a read
<ogra> and after that thread (but only after) https://lists.ubuntu.com/archives/ubuntu-users/2010-February/210545.html
<popey> hehe
<ogra> *g*
<popey> i had missed that first one
<popey> he's calmed down a lot
<ogra> karl is my best entertainment on that list, without him i would probably have unsubbed a year ago ...
<ogra> sadly he caused so much damage
<popey> indeed
<ogra> but yes, its a lot better recently
<popey> he's on moderation
<popey> the only person who is
<Caesar> Was he that guy at UDS?
<ogra> the fun thing is that re is really rarely offending to anyone
<popey> yeah, he's calmed down enough to come off mod i reckon
<ogra> but he manages to get perople so far over the edge that *they* get offending
<popey> yeah, vicious circle
<ogra> watching him is like a psychological study of masses
<slangasek> Lucid: now with stubble
<popey> that could be said of vast swathes of the ubuntu community
<ogra> yeah, indeed, but karl is really special
<popey> he's what 75 years old or something?
<ogra> resistent to any learning ...
<ogra> yeah
<ogra> behaving like 12 or so :)
<popey> we have a cantankerous old git in our local Linux User Group, he's much the same, but much less gun-ho
<popey> he hates ubuntu too :)
<ogra> heh
<ogra> karl loves it i think
<popey> i stuck an ubuntu sticker on the underside of his debian laptop once.. he went mental
<ogra> lol
<popey> lovely guy, we do love to wind eachother up now and then
 * ogra will print "Karl F. Larsen Groupie" t-shirts and hand them out at uds !
<ogra> to all ML mods :)
<popey> heh
 * kees heads head on desk.
<kees> every time I get dmsetup export support into Debian, they rip it back out since it is "unused".
<slangasek> hmm?
<kees> pitti: this is not a 1 day task, I'm about 1/4 of the way done with the devmapper+lvm2 merge, just so you don't duplicate work and start it too.
<micahg> Amaranth: that user in the flash bug has been problematic
<Amaranth> Yeah, I can see that :)
<micahg> Amaranth: I'm talking to LP admins about it now
<spm> Amaranth: fyi. I've sent a polite please don't "send as" email; a call from a vaguely irrelevant authority has worked in the past; so hopefully will this time. we shall see.
<spenser> Hi, I'm working on fixing bug #520240.  This is my first ever attempt at a patch for Ubuntu/Debian.  I updated the rules and added the file that I needed to add,  however when I run debuild -us -uc to build the package I get the following lintian error. Now running lintian...
<spenser> E: libapache2-mod-authz-unixgroup: duplicate-conffile /etc/apache2/mods-available/authz_unixgroup.load
<spenser> Finished running lintian. How can I fix this?
<ubottu> Launchpad bug 520240 in libapache2-mod-authz-unixgroup "Does not install create /etc/apache2/mods-avaiable/authz_unixgroup.load file" [Undecided,New] https://launchpad.net/bugs/520240
<arand> spenser: #ubuntu-motu might be more appropriate
<spenser> ohh ok thank you
<F40PH> !ops
<pitti> Good morning
<pitti> kees: right, understood; thanks so much for taking care of it!
<dholbach> good morning
<tkamppeter> mvo, hi
<mvo> hey tkamppeter
<tkamppeter> mvo, I have changed and uploaded HPLIP
<mvo> tkamppeter: ok, I will upload update-notifier, lets see if it works then
<tkamppeter> Here is the debdiff of HPLIP, so that you do not need to wait for the upload to finish processing: http://pastebin.ubuntu.com/373777/
<siretart> E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle.
<siretart> known?
<siretart> oh, bug #516727, sorry for the noise
<ubottu> Launchpad bug 516727 in openoffice.org "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Confirmed] https://launchpad.net/bugs/516727
<tkamppeter> mvo, you can try with the debdiff (http://pastebin.ubuntu.com/373777/) for the case the HPLIP package is not yet ready for yyou to download.
<tkamppeter> mvo, please tell me when you have uploaded update-notifier, then I can try with a real printer.
<mvo> siretart: *grumpf* again? we had that in every release I think :(
<mvo> siretart: thanks, do you have this bug? if so, can you attach /var/lib/apt/dpkg/status and your /etc/apt/sources.list (or mail it to me)?
<siretart> mvo: I've just removed openoffice.org-filter-binfilter and am just doing a dist-upgrade
<siretart> as for sources.list, plain lucid + some ppas (motumedia + chromium)
<mvo> siretart: aha, so its lucid->lucid?
<siretart> yes
<mvo> ok
<siretart> I'm not dist-upgrading that often, every few weeks or so
<pitti> cjwatson: are you still working on the gnu-efi merge (bug 488797), or is it okay to sponsor?
<ubottu> Launchpad bug 488797 in gnu-efi "Please merge gnu-efi 3.0i-2(main) from debian squeeze(main)" [Undecided,Confirmed] https://launchpad.net/bugs/488797
<frafu> Hi, pitti. As far as I know, you are one of the developers of the dist-utils-extra package; correct? If so, could you please have a look at this: https://answers.edge.launchpad.net/python-distutils-extra/+question/100558  Thanks in advance.
<pitti> frafu: will have a look
<frafu> thanks
<Keybuk> ev: just for clarification, 20100211 doesn't work either
<pitti> frafu: answered
<frafu> pitti: thanks
<ev> Keybuk: indeed, I've fixed the problem in casper and have just been waiting for ftpmaster to catch up so I can build new CDs
<Keybuk> sweet
<kees> pitti: I'm almost ready with lvm2.
<kees> Keybuk: upstream debian chopped up their udev rules for devmapper and lvm2.  I'll need to revisit doing Hardy->Lucid upgrades, but for the moment, things look to be correct, even if it results in 3 udev rules files in lvm2 and 2 in dmsetup.
<Keybuk> kees: I didn't think we used upstream or Debian rules?
 * Keybuk is pretty sure he wrote the rules in our package
<kees> Keybuk: we used upstreams, but heavily heavily modified them.  while walking them trying to find differences, I've mostly convinced myself they're sane now.
<kees> Keybuk: the only "new" one is the "trigger vgchange" file.
<kees> Keybuk: I'm going to upload this to a PPA first; I don't want to break the world, and there is a ton of changes in it.
<kees> Keybuk: changelog looks like this so far: http://paste.ubuntu.com/373861/
<Keybuk> have you checked the rules against those shipped in the udev packages?
<Keybuk> kees: looks sane
<kees> Keybuk: afaict, udev doesn't ship anything for dm devices (including lvm).
<Keybuk> rules/packages/64-device-mapper.rules
<kees> while Debian's rules are somewhat differently arranged, it seems that the bugs we've been fixing with our rules were being fixed by them as well.
<Keybuk> rules/suse/64-device-mapper.rules
<Keybuk> cause it'd be worth updating udev with new rules if they're much different
<geser> kees: is every case of "undefined reference to `__stack_chk_fail'" valid to add "-fno-stack-protector" or do I need to do more checks?
<kees> -rw-r--r-- root/root      2643 2010-02-10 15:36 ./lib/udev/rules.d/55-dm.rules
<kees> -rw-r--r-- root/root       767 2010-02-10 17:14 ./lib/udev/rules.d/60-persistent-storage-dm.rules
<Keybuk> kees: in the source package, not installed
<kees> geser: the reverse.  any time you find "undefined reference to `__stack_chk_fail'", you should find out why the linker is bad.  :)
<kees> Keybuk: ah, well, one thing at a time.  :)
<Keybuk> kees: "while you're in there" :p
<kees> -rw-r--r-- root/root       509 2010-02-10 15:36 ./lib/udev/rules.d/60-persistent-storage-lvm.rules
<kees> -rw-r--r-- root/root       272 2010-02-10 17:40 ./lib/udev/rules.d/85-lvm2.rules
<kees> -rw-r--r-- root/root       550 2010-02-10 17:41 ./lib/udev/rules.d/56-lvm.rules
<kees> these are the ones I'm curious about
<kees> our 85-lvm2.rules is the new one
<Keybuk> that's the one that runs vgscan/vgchange no?
<kees> well, "new" in that it's the watershed/vgchange hammer
<kees> but they renamed their rules from lvm2 to lvm
<kees> I figured I'd just keep ours as 85-lvm2.rules for sanity
<kees> it should probably be called 85-lvm-auto.rules or something
<Keybuk> possibly
<kees> geser: sometimes it's a sign that you're linking with "ld" instead of "gcc"
<geser> kees: I was looking at http://launchpadlibrarian.net/38115510/buildlog_ubuntu-lucid-i386.mknbi_1.4.4-2_FAILEDTOBUILD.txt.gz
<kees> geser: ld -N -Ttext 0x92800 -e _start --oformat binary -o first32@0x92800.linux start32@0x92800.o first32.o memsizes.o printf.o string.o
<kees> swap ld with gcc for now
<kees> if you can
<geser> kees: does it make a difference that gcc is called with -ffreestanding?
<kees> geser: otherwise, build the .o files with -nostdlib
<kees> geser: it should yes, as freestanding uses nostdlib, iirc
<geser> kees: in this case building the .o files with -nostdlib would be the right fix, correct?
<kees> geser: yeah, I think that would work.
<geser> thanks, will try out if this fixes the FTBFS
<kees> geser: it's likely a bug that it stackprotector should be disabled when -ffreestanding exists
<ogra> Keybuk, bug 520028 ... shouldnt there be a stronger dependency on dbus from upstart (if thats really at fault here)
<ubottu> Launchpad bug 520028 in project-rootstock "ubuntu-minimal doesn't build correctly for karmic" [Undecided,New] https://launchpad.net/bugs/520028
<Keybuk> "stronger dependency" ?
<Keybuk> you mean like PRE-DEPENDS
<Keybuk> wing-commander scott% dpkg -s upstart | grep dbus
<Keybuk> Pre-Depends: libc6 (>= 2.4), libdbus-1-3 (>= 1.2.16), libnih-dbus1 (>= 1.0.0), libnih1 (>= 1.0.0), libudev0 (>= 147), sysvinit-utils, sysv-rc, initscripts, mountall
<ogra> Keybuk, libdbus-1-3 only recommends dbus
<ogra> and apparently that guy has a prob if dbus isnt installed (which doesnt happen with plain debootstrap)
<StevenK> cjwatson: My shell foo is failing me, can "run this, and then this, and if either one of them is successful, run this other thing" be expressed?
<Keybuk> ogra: upstart doesn't depend on dbus (the daemon) though
<ogra> Keybuk, if the daemon is essential for booting i think it should be either pulled in by debootstrap or by upstart
<Keybuk> it's not essential for booting
<Keybuk> the fact you can install ubuntu-minimal with debootstrap and go is a good sign here
<Keybuk> it means that whatever he's using (which is not debootstrap, the bug is on something called "project-rootstock") is failing to build a correct image
<ogra> rootstock is a wrapper to debootsrap
<ogra> (and a bit more)
<Keybuk> the deps are correct, anyway
<Keybuk> upstart pre-depends libdbus
<Keybuk> libdbus recommends dbus
<Keybuk> the dbus daemon is not a requirement, but is present in all but unusual situations
<Keybuk> which is the correct meaning
<ogra> define an unusal situation :)
<Keybuk> stripped down installs
<Keybuk> embedded platforms
<Keybuk> highly focused specialised things
<ogra> if he just runs debootstrap (which he essentially did) then dbus is apparently missing
<Keybuk> sure
<Keybuk> nothing wrong with that
<ogra> i would expect debootstrap to create a basic functional system
<Keybuk> it does
<ogra> ogra@osiris:~/Devel/branches/project-rootstock$ sudo chroot /var/build/lucid-arm-chroot/ dpkg -l dbus|grep ^ii
<ogra> ogra@osiris:~/Devel/branches/project-rootstock$
<Keybuk> you know what
<Keybuk> why do you bother asking me things?
<Keybuk> you never listen to my answers
<Keybuk> I've said four times that you don't need the dbus daemon
<Keybuk> and yet you continue to ignore me
<ogra> ok, sorry
<Keybuk> I'll explain it one more time
<Keybuk> Upstart uses peer-to-peer D-Bus
<ogra> no, its ok
<Keybuk> when you want to talk to Upstart, you open an AF_UNIX socket and connect to @/com/ubuntu/upstart
<Keybuk> the protocol you talk is the D-Bus protocol
<Keybuk> as implemented by libdbus
<Keybuk> but there is no bus daemon involved
<Keybuk> the thing listening on that socket is init itself
<Keybuk> this means that the D-Bus daemon (in the dbus package) is not required
<Keybuk> you *can* also use the D-Bus daemon if you prefer
<Keybuk> if it's running, Upstart will connect to it
<Keybuk> and then you can use libdbus to open a bus connection (to the system bus)
<Keybuk> and address messages to com.ubuntu.Upstart on that
<Keybuk> and reach the init daemon
<Keybuk> the advantage of doing this is that since the bus daemon is an intermediary, you can do this as non-root
<Keybuk> the bus daemon security policy permits read-only queries
<Keybuk> this is why "status", "initctl list", etc. all work as normal users
<Keybuk> but "stop", "start", etc. don't
<Keybuk> so
<Keybuk> while you need libdbus
<Keybuk> you do not *need* dbus
<Keybuk> and since the entire boot is done as root, nothing will try and use it anyway
<ogra> right, understood
<Keybuk> mountall uses this peer-to-peer connection too
<Keybuk> fwif
<Keybuk> so it only needs libdbus, not dbus-daemon
<Keybuk> you only need dbus if you want system bus services, like Network Manager, or Avahi, etc.
<Keybuk> but since those aren't part of minimal, you don't get the bus daemon
<ogra> right, and they usually depend on the daemon if there is no packaging error
<ogra> Keybuk, thanks a lot for that intro, i really didnt mean to annoy you
<Keybuk> exactly
<Keybuk> since I know for a fact that ubuntu-minimal works
<Keybuk> and he doesn't say anywhere how "boot doesn't work"
<Keybuk> and is using a non-standard way of building it
<Keybuk> I'm inclined to believe he's screwed up
<ogra> right
<Keybuk> I'm also quite happy to be proved wrong here ;)
<ogra> well, he is using a bare debootstrap
<ogra> thats what rootstock does if you dont specify anything extra
<cjwatson> pitti: I don't think I was ever working on it - my comment just meant what it said on the tin
<cjwatson> pitti: feel free to sponsor
<ogra> i used to install ubuntu-minimal by default on top of that if you dont use any options ... but that was removed at some point by lool (i think to gain debian compatibility), i'll re-add it
<Keybuk> I'm not 100% sure a bare debootstrap boots
<Keybuk> you'd have to check with cjwatson on that one
<Keybuk> I can't remember what debootstrap actually installs
<kees> cjwatson: hi! in doing the devmapper/lvm2 merge I ran into a change you made that I think is no longer needed, but I wasn't sure how to validate it for sure.
<kees> cjwatson: you set DH_OPTIONS="" before doing the shlibs build to get sane symbols for udebs.  I think this is fixed upstream, but I don't know quite what to look for.
<cjwatson> StevenK: there might be a more concise way, but I would write it as something like:  CODE1=0; command1 || CODE1=$?; CODE2=0; command2 || CODE2=$?; if [ "$CODE1" -eq 0 ] || [ "$CODE2" -eq 0 ]; then command3; fi
<cjwatson> Keybuk,ogra: debootstrap installs priority: required and important; dbus is priority: optional
<ogra> right
<cjwatson> Keybuk,ogra: debootstrap certainly installs ubuntu-minimal, unless something went wrong
<ogra> well, not the metapackage, does it ?
<cjwatson> yes, the metapackage
<ogra> ok
<cjwatson> apt-cache show ubuntu-minimal | grep ^Priority:
<ogra> :)
<ogra> important ... ok
<Keybuk> cjwatson: ok, so debootstrap output should boot
<ogra> Keybuk, it usually does for me
<Keybuk> ogra: I'm going to ask a very pertinent question
<cjwatson> we stopped hardcoding the list of packages to use for debootstrap in 2005; it's all priority-driven nowadays
<ogra> but that user seems to be on karmic
<Keybuk> which may reveal how silly the reporter is being
<Keybuk> he installed debootstrap
<Keybuk> ...
<cjwatson> kees: let me check ...
<Keybuk> did he install a kernel as well?
<Keybuk> and a boot-loader?
<kees> cjwatson: specifically this: http://launchpadlibrarian.net/16954645/devmapper_2%3A1.02.25-1ubuntu4_2%3A1.02.25-1ubuntu5.diff.gz
<ogra> Keybuk, well, thats up to the user with rootstock ... but apparently after installing dbus his system booted ... who knows what he did inbetween first boot and dbus
<cjwatson> yeah, I was just tracking down the changelog to refresh my memory
<cjwatson> I certainly remember why that was needed, so I'll double-check Debian
<kees> cjwatson: what should I look for in the udebs?
<Keybuk> ogra: which makes no sense
<slangasek> cjwatson: CODE1=... eew, let's not have that in antimony's crontab please :)
<kees> cjwatson: the debian build of libdevmapper* in lvm2 is now very different
<Keybuk> an ubuntu-minimal install basically consists of upstart, udev, mountall and getty
<ogra> Keybuk, ??
<ogra> right
<Keybuk> that boots perfectly, *really fast* :p
<cjwatson> kees: you actually want to look at the shlibs file in the run-time library's control area
<cjwatson> and make sure it has some plausible-looking udeb: entries
<kees> debdiff between old and new libdevmapper1.02.1-udeb don't show regressions there, but let me unpack it and actually look at it
<cjwatson> you won't see it when debdiffing the udeb
<cjwatson> the breakage was exposed by building other udebs against devmapper
<kees> hrm, perhaps I don't know what "run-time library's control area" is
<cjwatson> libdevmapper1.02.1 rather than libdevmapper1.02.1-udeb
<slangasek> the DEBIAN/shlibs file, which won't register on debdiff
<kees> oh! er, okay
<kees> ah-ha, yes.  my current merge breaks it.
<cjwatson> so, err ... the Debian mirror I'm looking at doesn't actually appear to have a current libdevmapper1.02.1-udeb
<StevenK> Hah, damn. slangasek guessed what I wanted it for ;-)
<slangasek> StevenK: the mail from lool was a clue
<cjwatson> it builds clvm, lvm2-udeb, and lvm2
<kees> ah-ha, I just missed it, it does show in the debdiff of the regular debs, oops.
<cjwatson> am I missing something obvious?
<kees> libdevmapper 1.02.1 [-libdevmapper1.02.1-] {+libdevmapper-event1.02.1+} (>= [-2:1.02.27)-]
<kees> [-udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.27)-] {+2:1.02.39)+}
<kees> how to fix this in the current merge is not immediately obvious, though.
<cjwatson> slangasek: if you have a cleaner answer to the question asked ...
<slangasek> cjwatson: I want to revisit the premise :)
<cjwatson> well, I sort of agree there, if this is imx51/dove stuff
<kees> fwiw, current package looks like this: https://edge.launchpad.net/~kees/+archive/ppa/+sourcepub/962485/+listing-archive-extra
<cjwatson> the fact that doing those builds involves two separate invocations is a bug in and of itself
<cjwatson> and I said so from the beginning, I think
<slangasek> StevenK, lool: the whole reason we're running this as two commands instead of one was to work around some armel buildd bug... do we know that this is still an issue?
<dholbach> does anybody know what I should be doing if "bzr merge-package <...>" says "ERROR: No such tag: upstream-2.0.3"?
<dholbach> james_w maybe^ :)
<StevenK> slangasek: I'm doing it as two seperate builds since I didn't want imx51 to impact on dove and vis-vrsa
<cjwatson> eww, libdevmapper* has a different set of version numbers, no wonder I missed it
<StevenK> *vise versa
<kees> cjwatson: mind bending :)
<cjwatson> kees: Debian's package seems to have correct shlibs
<cjwatson> libdevmapper 1.02.1 libdevmapper1.02.1 (>= 2:1.02.39)
<cjwatson> udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.39)
<slangasek> dholbach: you're supposed to be able to fall back on bzr merge
<kees> cjwatson: perhaps it's the addition of libdevmapper-event that is breaking it
<dholbach> slangasek: "ok"
<slangasek> StevenK: er, and what makes you think that running them as a single command will cause them to "impact" each other?
<cjwatson> kees: ah yes, that's quite possible
<StevenK> slangasek: So, "ARCHES='armel+imx51 armel+dove' buildlive" ?
 * kees tries the DH_OPTION=  fix...
<cjwatson> wisdom teeth are impacted, people are affected by the effects of events
<cjwatson> as a .sig I saw once said
<kees> cjwatson: hmpf, no love.
<slangasek> StevenK: ARCHES='armel+imx51 armel+dove' buildlive ubuntu-netbook && ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live - but again, I was told the original reason for the split was to work around some strange autobuilder bug
<slangasek> s/autobuilder/livefs buildd/
<StevenK> I'm happy enough to try that and see what happens
<ogra> yes, while clementine is supposed to serialize builds that apparently doesnt work right
<StevenK> Er, it has, and does
<StevenK> Because I've seen it, multiple times
<ogra> well, if you are confident. go ahead and try it
<StevenK> Hopefully that will make lool happy too
<ogra> i know we had issues in the past which initially resulted in that weird crontab entry
<cjwatson> kees: do you have a bzr branch or something I can check out?
<cjwatson> or should I just use source from your ppa?
<kees> cjwatson: I can create one, if you want, but go ahead and snag the source from my ppa.
<cjwatson> kees: and did you literally try DH_OPTION=, or the correctly spelled DH_OPTIONS=?
<kees> I'm about 5 hours overdue for bedtime.  ;)
<kees> cjwatson: it was the correctly spelled DH_OPTIONS=
<kees> cjwatson: what's melting my mind now is how what's in the built deb got there.
<kees> libdevmapper 1.02.1 libdevmapper-event1.02.1 (>= 2:1.02.39)
<kees> that's in libdevmapper
<kees> yet...
<kees> it's in no shlibs file in the build tree
<cjwatson> dpkg-checkbuilddeps: Unmet build dependencies: libreadline5-dev
<cjwatson> don't suppose that's easily upgradeable to readline6?
 * cjwatson hates having to switch back and forth
<kees> $ cat ./debian/libdevmapper1.02.1/DEBIAN/shlibs
<kees> libdevmapper 1.02.1 libdevmapper1.02.1 (>= 2:1.02.39)
<kees> udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.39)
<kees> *hold face*
<kees> cjwatson: I can try it with 6
<cjwatson> kees: build in progress here
<kees> cjwatson: it built fine with readline6, so I'll flip that.
<kees> this is _really_ odd.  what is changing the shlibs file between debian/libdevmapper1.02.1/DEBIAN/shlibs and the deb
<kees> cjwatson: aargh, I'm an idiot. DH_OPTIONS=  worked fine, I just changed my version for the PPA upload. so I had ubuntu1 and ubuntu1~kees1 .debs.  I was checking the wrong one.
<Keybuk> ev: Executing grub-install hd(0) failed.  This is a fatal error.
<kees> s/an idiot/way past bedtime/
<ev> bah
<kees> okay, uploading the fix to my PPA, heading to bed
<cjwatson> kees: ah, ok :)
<ev> Keybuk: did you change your preseed?  Surely that should be grub-install (hd0)
<Keybuk> ev: err, (hd0) is what it said
<Keybuk> was retyping without paying complete attention
<Keybuk> syslog says "no mapping exists for 'hd0'"
<cjwatson> kees: I tend to use DH_VERBOSE=1 pretty liberally for debugging this kind of thing
<cjwatson> Keybuk: clearly a bug, but can you use /dev/sda rather than (hd0)?
<cjwatson> we're finally managing to get on the road to deprecating (hdX,Y) names for most purposes
<cjwatson> and it might work around whatever the problem is
<Keybuk> cjwatson: how do I do that?
<Keybuk> ubiquity        partman-auto/disk       string  /dev/sda
<ev> grub-installer/bootdev /dev/sda
<Keybuk> is what I have in my seed
<Keybuk> ev: I don't have anything about grub in there right now?
<ev> Keybuk: indeed, this is a workaround for the aforementioned bug
<cjwatson> huh
<cjwatson> why is (hd0) turning up at all then
<cjwatson> # Try to avoid using (hd0) as a boot device name.  Something which can be
<cjwatson> # turned into a stable by-id name is better.
<cjwatson> default_bootdev_os="$($chroot $ROOT grub-mkdevicemap --no-floppy -m - | head -n1 | cut -f2)"
<cjwatson> it only uses (hd0) if that fails
<Keybuk> you want the full logs?
<cjwatson> Keybuk: yes please, and could you also run 'chroot /target grub-mkdevicemap --no-floppy -m -' from a shell prompt after the failure and see what it says?
<cjwatson> maybe I forgot to mount /proc and friends before calling grub-mkdevicemap
 * ogra wonders how to tell jockey to not sacn on every start 
<ogra> *scan
<lool> StevenK, ogra, slangasek: Only the buildlive calls need to be split though, not the cron-ports.daily-live one
<ogra> yes
<slangasek> lool: but it's precisely that splitting that makes it a PITA to check the return code
<cjwatson> right; if it absolutely has to be serialised for some reason, that serialisation needs to be done inside the buildlive script itself
<cjwatson> but I would hope that isn't really necessary
<lool> slangasek: I don't think it's particularly bad if we run the image building code if the livefs failed
<cjwatson> we need to be consistent about this across architectures.  it's a pain for armel to be substantially different
<Keybuk> cjwatson: http://people.canonical.com/~scott/daily-installer/20100211.1-max/
<lool> IMO the easiest way is to add a livefs builder..
<Keybuk> that has the syslog and stuff
<slangasek> lool: even if it causes previous successful builds to be rotated off?
<ogra> lool, ++ send hardware :P
<lool> That would make things more symetric and would alleviate the image building time for armel....
<cjwatson> lool: why can't we just run the two live filesystem builds in parallel?
<lool> slangasek: It shouldn't be a failed build
<slangasek> lool: want to give up a buildd to do it? :)
<cjwatson> sure, it takes longer, but it takes longer *anyway* right now
<lool> cjwatson: we only have one livefs builder, and it happened that the serialization code didn't work
<Keybuk> cjwatson: running the chroot grub-mkdevicemap outputs
<ogra> cjohnston, because the build machine is already underpowered
<Keybuk> (hd0) /dev/sda
<lool> But it was years ago, perhaps that would work now
<lool> I never got the chance to debug it
<cjwatson> ogra: we're already running two builds
<slangasek> no, it wouldn't be a failed build, it would just be an ISO that's identical to the previous build and therefore redundant
<ogra> years ?
<lool> the symptom was that the livefs buildd was stuck
<ogra> right
<cjwatson> ogra: it makes no logical difference to underpoweredness whether we fire off two builds at once and have one stick on a lock until the other's done, or explicitly serialise them
<cjwatson> so this is a red herring
<ogra> cjwatson, yes, i know, but we cant run them at the same time
<lool> slangasek: Yeah, and I don't have a big problem with that!
<slangasek> cjwatson: the failure mode was that the livefs buildd required a hard reset
<cjwatson> ogra: livecd.sh doesn't try though, it uses locks
<lool> (hard reset == someone goes to data center to reboot)
<cjwatson> slangasek: right, but I'd much rather we debugged that ...
<slangasek> certainly
<cjwatson> Keybuk: permission errors on syslog
<ogra> cjwatson, we have no control about the kernel on these machines and its not a good kernel ...
<Keybuk> cjwatson: bah
<Keybuk> I keep fixing that
<ogra> i.e. it produces unexpected lockups in several cases
<lool> I don't mind trying the lock thing again; I still believe the best thing which can happen is a second livefs builder
<ogra> yes
<ogra> its the only proper solution
<cjwatson> I have no objection to a second livefs builder.  I do object to the way the scripts are laid out right now
<ogra> but we lack HW for that
<Keybuk> cjwatson: try now?
<cjwatson> it's confusing and error-prone
<lool> I had objections too  :)
<cjwatson> Keybuk: better, thanks
<lool> We could do locking on the cdimage side
<slangasek> lool: well, I have a problem with us stomping on history that would've been useful to retain when it's avoidable
<cjwatson> lool: I don't really care how it's done as long as it is done by a single invocation of buildlive
<lool> slangasek: What we care about in this situation is fixing the image build anyway, don't we?
<lool> (s/image/livefs)
<cjwatson> not necessarily if we're in the last day or two of the release process
<slangasek> that's not the *only* thing to care about, no
<Keybuk> ah, I fixed it in success.sh not in failure.sh
<cjwatson> in that circumstance, sometimes the right thing to do is simply to back off
<slangasek> cjwatson: OTOH, in the last day or two all builds are manual :)
<cjwatson> yes, but the less weird shell you have to deal with, the better ...
 * slangasek nods
<cjwatson> complex => error-prone
<lool> Anyway, we all agree on what the ideal situation would be, we just have various levels of tolerance with intermediate fixes
<ogra> and we dont have any hard data atm ...
<lool> So, let's try to get another builder, let's try to have a single buildlive call perhaps doing local locking, and let avoid building images when the livefs failed to build
<ogra> lets try with a single buildlive run and see what happens first
<slangasek> is there sufficient buildd capacity to consider repurposing a buildd as a second livefs builder?
<ogra> hostorically it didnt, but we lose only one daily build if it doesnt now
<ogra> slangasek, no
<ogra> thats the point
<ogra> we lack HW
<lool> Anyway, my involvment was just in raising a flag that cron.ports-daily-live should only run once for the same project, that has been well covered; I think I'm just adding confusion in the discussion now, I'll mobile / IS to resolve
<lool> +let
 * lool lunch &
<slangasek> local locking> I don't see the point it doing that (also error-prone) rewriting when the builder-fall-down-go-boom problem should be fixed anyway
<slangasek> ogra: "we lack HW" doesn't say anything about the buildd capacity to me
<slangasek> since the running buildds are obviously hardware that exists, and therefore is not lacked :)
<ogra> we have 8 buildds for everything and one livefs builder
<ogra> of these buildds usually one or two are hung
<ogra> and we are usually constantly behind
<slangasek> ok.
<ogra> oh, and buildds need to be in manual for several reasons as well, i.e. team PPA builds etc
<ogra> so in average we operate with 4-5 maichine plus livefs machine
<ogra> *machines
<slangasek> so the fact that armel's build queue is currently empty is atypical?
<ogra> yes
 * slangasek nods
<ogra> but more than the queue the factz that packages take about twice as long to build on our buildds is more significant
<slangasek> not really
<ogra> like a mass give back of KDE can take us out of business for two days
<slangasek> adding or removing a builder wouldn't change that
<ogra> having uploads qeueing up
<ogra> i foten have uploads sitting there for half a day because of toochain testbuilds while OO.o builds, while some kde package builds ... so the queue is processed a lot slower
<ogra> *often
<mdeslaur> slangasek: curiously, after updating packages at the sprint, I did get a plymouth splash screen with nvidia binary drivers for a couple of days, and then it went away again...
<slangasek> mdeslaur: that might have corresponded to a window when grub2 was doing Mad Things by default
<slangasek> (gfxpayload=keep)
<mdeslaur> slangasek: ah, maybe. mad, but nice looking. :)
<slangasek> if only that were the effect that option had for /everyone/, that would be great. :)
<mdeslaur> hehe
<dholbach> ara: do you want 516248 reviewed too?
<ara> dholbach, that one is fix released
<dholbach> ara: the merge proposal is still around - I'll mark it merged
<dholbach> hum, or maybe I don't
<dholbach> not sure who has the power to do it
<dholbach> ara: maybe you can mark it merged or something
<ara> dholbach, I'll try
<dholbach> fantÃ¡stico
<ara> dholbach, I can't, either
<dholbach> bah
<dholbach> maybe mark the branch as merged?
<dholbach> if not maybe james_w can help
<james_w> what's the url?
<james_w> there's an open bug about this
<dholbach> https://code.edge.launchpad.net/~apulido/ubuntu/lucid/ldtp/ldtp-fix-516248/+merge/18476
<dholbach> james_w: having any luck?
<slangasek> Riddell: why is virtuoso-opensource-6.0 using Pre-Depends when it doesn't have a preinst?
<dholbach> can somebody have a look at bug 506908 and see if the upstart script is good and upload it?
<ubottu> Launchpad bug 506908 in pcsc-lite "Upstart job for pcscd" [Undecided,In progress] https://launchpad.net/bugs/506908
<dholbach> ara: seems like james_w managed to fix it somehow :)
<ara> dholbach, james_w: thanks!
<james_w> ara: you can me-too bug 504025 about this if you like
<ubottu> Launchpad bug 504025 in launchpad-code "LP doesn't show correct permissions for packaging branches for me" [High,Triaged] https://launchpad.net/bugs/504025
<dholbach>  /me me-toos too
<ara> james_w, done :)
<apw> pitti, isn't the work-items-tracker meant to support dropped now?
<apw> ERROR: kernel-lucid-kernel-config-review: invalid state "dropped" for work item "[apw] Master config support from master branch in other branches"
<pitti> apw: hm, it's supposed to, I'm using it myself
<apw> i am somewhat confused cause i see it in the code
<apw>     if state in ('postpone', 'dropped', 'drop'):
<apw>         state = 'postponed'
<apw> i'd have expected that to zap it
<pitti> right, it should
<pitti> apw: you get that as email?
<apw> pgraner did ... i'll check if i did too
<apw> yeah last night
<sebner> cjwatson: alien-arena is blocked on buggy dpkg. I heard you plan to merge dpkg?
<persia> Um, I only said that a merge of dpkg was mentioned  I didn't mean to imply that any specific person was planning to do it.
<cjwatson> sebner: I plan to do that after bzr-builddeb can cope with importing .tar.bz2
<sebner> *hohohoho*
<cjwatson> which james_w is in the process of doing, I understand
<sebner> cjwatson: take my thanks then :)
<cjwatson> I'm not expecting the merge to be hugely difficult, but I don't want to do it outside bzr unless I have no other choice
<sebner> persia: Don't you feel like a cattleman? :P
<persia> sebner: No.
<sebner> cjwatson: no problem. As long it happends before FF ..
<sebner> persia: pushing me around that much *hehehe*
<pitti> apw: btw, any luck with the usb_id delay thing? was it that one commit you suspected?
<uniscript> anyone planning to package openoffice 3.2 for backporting (karmic)?
<uniscript> or should I use release debs from openoffice?
<smoser> hi, i'm looking for some feedback.
<smoser> Background info: Our UEC/EC2 Images are filesystem images (ext3) as such, we create the filesystem in our build process.
<smoser> the filesystem images currently have:
<smoser> (per dumpe2fs):
<smoser> Maximum mount count:      39
<smoser> Last checked:             Thu Feb 11 02:19:12 2010
<smoser> Check interval:           15552000 (6 months)
<smoser> I suspect that that means an instance of this image booted 6 months from now will run fsck on first boot
<bdrung> dholbach: why does sponsors-page.py needs so long (8 mins)? can it somehow accelerated by caching or something else?
<persia> smoser: That seems likely, yes.
<smoser> fsck'ing on first boot just because time has passed seems like a bad thing, as the bits haven't rotted sitting unused.
<smoser> so i'm thinking to 'tune2fs' that off
<smoser> anyone have thoughts as to how bad an idea that would be?
<dholbach> bdrung: it caches already
<persia> smoser: So just fsck based on maximum mount count?  In a UEC enviornment, how often do mounts happen?
<dholbach> bdrung: launchpadlib caches automatically
<dholbach> bdrung: but if you find a way to speed it up, that'd be cool
<ion> smoser: Might or might not be usable for you, but iâm using http://github.com/ion1/e2croncheck to avoid the fsck-on-startup on my server.
<dholbach> bdrung: one solution would be: make the list shorter!
<bdrung> dholbach: the second run took the same amount of time.
<ion> smoser: And also to get quicker notification of potential filesystem problems.
<smoser> persia, i think mounts probably occur similarly to "normal" systems. if different, i'd expect that UEC instances would have a shorter lifespan, though. so less mounts.
<persia> smoser: My worry was that with fewer mounts, it may be a very extended period of time until fsck.
<persia> Maybe the mount count could be reduced if the check interval is removed.
<smoser> hm... well, when i said "less mounts", i really meant less mounts ever
<smoser> as in the system likely is booted and does some stuff, then the filesystem thrown away
<smoser> one thing i *could* do is disable interval checking in the filesystem on creation
<smoser> and on first boot turn it on
<smoser> if that would cause the first interval based check to occur 'interval' from "now"
<persia> smoser: That seems like a reasonable compromise, as long as you have some way to indicate that a check happened on creation.
<smoser> persia, a check happend on creation?
<persia> smoser: For interval checking to work, you need some "last check" timestamp.  You want to spoof this with the timestamp for system initialisation.
<smoser> ah.
<bdrung> dholbach: making the list shorter is the best solution. :)
<smoser> tune2fs -T will let me set that
<dholbach> bdrung: WORD
<persia> smoser: There you go then :)
 * dholbach advertises: http://qa.ubuntu.com/reports/sponsoring/
<smoser> assuming it works on a mounted filesystem
<apw> pitti, when i tried to reproduce the usb_id delay, it was not visible in my output
<apw> pitti, meant to ask if you were still seeing it
<pitti> apw: I'm currently upgrading, I'll try again with -13
<pitti> apw: was still there with -12
<bdrung> dholbach: WORD?
<pitti> apw: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100209-1-une.png
<apw> i thought it had moved down the bottom and was 5s long and jut could not see it
<pitti> apw: (note that it doesn't actually hold up the entire session any more since plymouth is now run in parallel; but the 5 second I/O block is still there)
<apw> right but its clearly 5s long in your stuff there
<pitti> so it "just" slows down boot a little bit, but doesn't stall it by 5s any more
<apw> and wasn't there n mine, well it was more like .2s
<pitti> apw: either it's causing or waiting on this khubd block
<dholbach> bdrung: I very much agree with you :)
<smoser> please, if anyone has been following and thinks turning off inteval checking of a filesystem is a 'really bad idea', please speak up.  the *intent* will be to turn it back on on first boot, but that could fail.  The mount-count based checking will still be there.
<pitti> davmor, cjwatson: FYI, jockey fix uploaded (for the "always pops up" bug)
<bdrung> dholbach: you make the list longer by adding branches to them.
<dholbach> bdrung: james_w asked me to
<apw> pitti, thats mine: http://people.canonical.com/~apw/misc/penfold-lucid-20100210-2.png
 * pitti just finished sponsoring 11 packages and cleanign some 10 bugs, but doesn't see a noticeable dent in the page; *sigh*
<apw> but that is with a -13.18 prerelease kernel
 * apw sends pitti some red-bull
<bdrung> dholbach: can we generate the page dynamically?
<pitti> apw: that's a strange one
<dholbach> bdrung: like how?
<pitti> apw: no gnome-panel, etc? Apparently you don't have an ureadahead pack, so it's smeared out
<apw> pitti, note that with a manual login
<pitti> but indeed it's not there
<bdrung> pitti: thanks for sponsoring lintian.
<pitti> apw: ah, it finished dist-upgrading now; rebooting and crossing fingers :)
<apw> and yes it may have been making one
<mvo> DktrKranz: hi, could you please merge the gdebi debian bzr tree from lp:gdebi? hm, is that tree not a branch from the ubuntu tree? I thin kwe need fiddle wit hthat a bit to make merging work
<apw> i'll reboot and get a fresh one
<dholbach> bdrung: I think it'd be better to use harvest for things like that (so we just re-use the sponsoring.csv file)
<dholbach> bdrung: and when I say harvest, I mean lp:harvest and not the crappy thing that is online right now :)
<bdrung> dholbach: i thought at something like we did the dynamic part in harvest. having data prepared in some one and generating the html file dynamically.
<cjwatson> pitti: ah, thank you
<bdrung> dholbach: http://qa.ubuntu.com/reports/sponsoring/?user=bdrung should show the item that i can sponsor
<dholbach> bdrung: the new harvest uses django which will make it a lot easier to create whatever custom views we think of
<persia> I think we ought separate specific sponsorship requests from arbitrary things that need review.
<bdrung> if harvest can show only sponsoring task, then we should work on harvest and keep the current version of http://qa.ubuntu.com/reports/sponsoring/ as it is now
<pitti> apw: nope, still there on -13 :(
<apw> pitti, wtf, our machines should be identicle ...
<dholbach> bdrung: just check harvest out, set it up like in the INSTALL file and you'll see: it can show different "opportunity types"
<DktrKranz> mvo: do you mean to have a common ancestor?
<pitti> apw: do you have an even newer kernel than -13?
<mvo> DktrKranz: yes, it woudl make merging from and too simpler
<pitti>  apw: I don't have anything attached to this thing except the power cable
<mvo> DktrKranz: unless of course trunk/ has everything from the debian tree, then I can upload trunk/ to debian
<dholbach> bdrung: there's a few things that'd be good to have before we put it online somewhere (I started milestoning bugs against it)
<apw> pitti, its in theory the same bits ... i have just realised i do have an MMC card in the thing
<apw> and that is on USB ... perhaps thats skewing things
 * apw boots again
<pitti> apw: there's one thing I changed in the BIOS: It prefers to boot from USB (so that I don't always have to catch the F12 boot screen)
<DktrKranz> mvo: I thought it already had, I was probably wrong. I'll convert it later this evening, thanks
<pitti> apw: but when I boot -10, it doesn't happen, and with -11 it does happen, so I don't think it's related
<apw> pitti, got it ... putting the MMC card in the slot makes it go away
<apw> pitti, no wonder i couldn't see it
<pitti> magic
<apw> ok ... i can go test that patch now ... will let you know
<pitti> apw: do you have more of those cards which make boot faster?
<apw> heheeh
<apw> pitti, is there a bug for this 5s delay?
<pitti> apw: yes, hang on
<DktrKranz> mvo: so, do you plan to upload 0.6.0 soon?
<pitti> apw: bug 510937
<ubottu> Launchpad bug 510937 in linux "[2.6.32-11 regression] 5 second delay on early boot during usb_id" [Medium,Confirmed] https://launchpad.net/bugs/510937
<apw> pitti, excellent thanks, i'll get it on list
<pitti> apw: (with some things which I tried, etc.)
<mvo> DktrKranz: I think that would be a good thing, it would be nice to make sure the changelogs are all merged and no fixes get lost. I will not really have much time until feature freeze unfortunately :/
<DktrKranz> oh :(
<DktrKranz> I'll give it high prio
<mvo> many thanks DktrKranz!
<smoser> hm... persia just tested 'fsck device' of 400G disk with 1G usage (about what we have in our root images). it took .5 seconds.
<persia> smoser: So maybe just leave it alone?
<smoser> so it would seem that a forced interval check will cause first-boot delay of similar time
<smoser> yeah
<smoser> i think so
<smoser> i was just thinking it would take as long as when my system reboots and decides to fsck the large /home
<pitti> computer freezing during dist-upgrade, breaking futher boot -> priceless
<sebner> heh
<sebner> pitti: even in recovery mode?
<pitti> no, just booted -12, dpkg --configure -a, done
<Mirv> would anyone have something insightful to say to the usb-modeswitch thread I started on devel-discuss (https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-February/010647.html)? I'm wondering if it's something we'd really want but which just hasn't been on the radar.
<pitti> I don't know what caused it to crash
<cjwatson> Mirv: surely we just want the kernel to DTRT by default rather than going down the usb-modeswitch rat-hole; this is the upstream trend
<cjwatson> Mirv: it already DTRT for quite a few devices, rendering usb-modeswitch unnecessary as well as its existing unreliable state :-)
<cjwatson> Mirv: see e.g. linux/drivers/usb/storage/option_ms.c, the zerocd stuff
<Mirv> cjwatson: ok, that's what I was thinking about but then again usb-modeswitch seems to continue to develop. maybe then the reason for its existence goes away soon(ish)
<cjwatson> Mirv: personally, when I needed such a device to work, I found it *easier* to beat the kernel into shape than to wrestle with the various possible userspace nightmares
<cjwatson> and I'm not a kernel hacker
<cjwatson> the userspace stuff just plain didn't work for me
<cjwatson> I'd be very concerned about advertising that it's the Way to get things to work, and thus undermining getting things fixed in the kernel
<Mirv> I'm just thinking about the user space impact for lucid and if it's possible to evaluate it. But maybe it's indeed too hackish solution to be called a solution, no matter how it would help some.
<cjwatson> I found that in some situations the presence of udev rules for this actually made things worse, because I ended up with races
<Mirv> I was asking it mostly because I haven't bumped into the numerous problems described by some others, while in my case it was simply doesn't work at all / works fluently with usb-modeswitch.
<cjwatson> in your position, I would try to get the kernel to switch the device to networking mode by default
<cjwatson> which is probably just a matter of a quirk in the appropriate mass storage driver
<Mirv> Well, anyway, may that thread rest in peace then.
<Mirv> cjwatson: Ok, will put that to my todo list.
<mvo> tkamppeter: I looked at the hplip thing again and I noticed that there is a com.hp.hplip dbus object already. I think its best to use that, maybe in cooperation with upstream and add a method to trigger the NeedPlugin signal. if the signal then is available from the app it should work. the reason it is currently not working is that there is no signal on the com.hp.hplip that is available on the bus registered
<cjwatson> I agree that usb-modeswitch is often a way to get otherwise non-working hardware to work
<cjwatson> I'm just not very convinced it's a real properly supportable option
<cjwatson> but I'm just another user from this point of view, albeit one who ended up in quite a few discussions with various appropriate upstreams last time round :)
<Mirv> ok :) well, there is still a little bit of time if someone has an undisputable perfect solution that makes all 3G modems work out-of-the-box.
<Mirv> but otherwise let's just encourage people to fix the quirks in the kernel
<cjwatson> Mirv: what's your pci id?
<Mirv> cjwatson: usb id? it looks like 12d1:1446 before usb-modeswitch does the switch, after that 12d1:1001
<cjwatson> err, right
<cjwatson> Mirv: you might find it's as simple as http://paste.ubuntu.com/374035/ then
<Mirv> cjwatson: heh, that was fast. I'll try that out and report later.
<cjwatson> can't be sure, but the other huawei devices all seem to be handled basically the exact same way
<mathiaz> jdstrand: mdeslaur: hi - where can I find the genshi templates used by the security team?
<jdstrand> mathiaz: https://code.launchpad.net/~usn-tool/usn-tool/trunk
<mathiaz> jdstrand: thanks - IIUC genshi doesn't support template inheritance?
<jdstrand> mathiaz: hmm, not sure-- I didn't develop that code (I've only ever modified it slightly)
<tkamppeter> mvo, can you tell me what I exactly need to change on HPLIP and where?
<geser> mathiaz: no, genshi doesn't support inheritence but you can use includes (XInclude) to reuse templates
<tkamppeter> mvo, I have your new update-notifier and my new hplip installed and it does not work.
<mathiaz> geser: well - I'll write some text based templates (to generate preseed files)
<mathiaz> geser: IIUC XInclude is only available for XML templates
<geser> right
<mvo> tkamppeter: yeah, the reason is that dbus-send is not the best way for doing this, it better to change the existiing com.hp.hplip provider. I have not digged into that code yet, but it should be striaghtforward. maybe upstream is interessted in helping? otherwise I can work on it after feature-freeze on fixing it up
<geser> mathiaz: use "{% include ... %}" instead
<geser> http://genshi.edgewall.org/wiki/Documentation/text-templates.html#snippet-reuse
<tkamppeter> movo, we consider this feature as included now and work with time on it after feature freeze. Now I will make sure that all the other printing packages are up-to-date.
<tkamppeter> mvo: ^^
<mvo> tkamppeter: yeah, at this point it becomes a bugfix, if the hplip dbus stuff is done in python it should be pretty trivial
<tkamppeter> mvo: After that I can talk with upstream to find a concept for the hp-plugin call via D-Bus.
<mvo> tkamppeter: thanks, please talk to upstream first and if I have a spare minute I check the code
<tkamppeter> mvo, this stuff is in fact done in Python.
<tkamppeter> mvo, one thing is important: Before release we MUST have a way for hp-plugin to pop up when connecting such a printer, even if it is an interim solution and upstream provides something more streamlined after our release.
<mvo> tkamppeter: if we run dbus-send without --dest and with --print-reply then we can patch update-notifier to get those events. its a bit ugly, I would prefer to have it part of the real interface at com.hp.hplip. but its a backup plan if everything else fails
<tkamppeter> mvo, OK, so let us change the packages to this mode and change them again until we get a better solution.
<tkamppeter> mvo, so I do only s/--dest/--print-reply/ on the dbus-send command line?
<mvo> tkamppeter: I would prefer to investigate the better solution first, I can work on it later today
<micahg> Ubuntu Mozillateam meeting in #ubuntu-meeting in 5 minutes
<mvo> tkamppeter: the diff in update-notifier is really a bit ugly
<tkamppeter> mvo, then please tell me as soon as you have found some way and tell me then what to change in HPLIP.
<mvo> tkamppeter: I will
<tkamppeter> mvo, note that it is possible (I did not verify) that the part of HPLIP which is listening for the com.hp.hplip is some Qt-based part which is not used by standard installations (the applet of HPLIP will only get started if hplip-gui is installed). Our concept must also work in GNOME-only environments as an Ubuntu or Edubuntu off-the-CD standard install.
<sladen> Mirv: usb-modeswitch is a very long-winded way of sending a single usb-mass-storage command to the device's first profile
<sladen> Mirv: grep -hr MessageContent usb_modeswitch.d/ | sort -n | uniq -c | sort -rn   shows the level of duplication in the configuration files
<sladen> Mirv: I'm not even aware that the people that wrote it have *any idea* what binary crap they are poking to the device
<sladen> Mirv: eg. the first four bytes of all of those are  "USBC"  which is that usb mass storage protocol header
<sladen> Mirv: ...I do like that it is done in userspace though, as so easy to disable if you wanted something else
<lucas> running with kernel 2.6.32 from debian sid on a debian lenny. chrooting to a lucid amd64 chroot works fine. chrooting to a lucid i386 segfaults. does it ring a bell?
<slangasek> lucas: yes, because the Debian kernel team has said that kernel is broken
<lucas> slangasek: ah, wasn't aware of that. breakage related to that specific problem?
<slangasek> related to running 32-bit userspace on a 64-bit kernel, yes
<lucas> ok
<lucas> thanks
<slangasek> it appears the fix is in NEW
<lucas> ah yes it's known as #568416
<Laibsch> Keybuk: I'm currently working with Ahmed to get sl-modem out of its broken state and back into usable shape for lucid.  First step is to push back all the changes that Ubuntu did so we can sync from Debian again.
<Laibsch> Most of them are done.  sl-modem (2.9.11~20080817-3ubuntu2) changes are partially done.
<Laibsch> Neither Ahmed nor I are kernel or udev hackers.  Would you be willing to inspect the package before we upload to Debian to make sure that indeed the package to be uploaded to Debian has made the current Ubuntu delta obsolete?
<Keybuk> sure, I'll read through the diff
<Laibsch> We may have a question or two along the way as well and it would be great if you could mentor us here or there.
<Laibsch> Keybuk: debdiff?
<Keybuk> well, either really
<Laibsch> upstream version has changed and Ahmed made a lot of other changes as well.  I'm not sure reading the debdiff will be doable.
<Keybuk> ok, well, send me whatever you want me to look at
<Laibsch> cool
<Laibsch> thanks
<alkisg> From /etc/init/gdm.conf: [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ] || { stop; exit 0; }
<alkisg> Shouldn't that be '!=' instead of '='    ? Or am I reading this wrong?
<alkisg> (my problem is that failsafeXinit runs even though I have ldm as the default-display-manager)
<ev> mvo: are you okay with ubiquity-slideshow-ubuntu-upgrade, built out of ubiquity-slideshow-ubuntu, as the source for the upgrade slideshow, per Dylan's email?
<Keybuk> alkisg: no, it should be =
<Keybuk> alkisg: read it as "there's no default-display-manager file, or the file says gdm, OR don't use gdm"
<Keybuk> ie. gdm won't start if there's a default-display-manager file that doesn't say gdm
<alkisg> Keybuk: thanks, that final || got me confused :)  Any ideas on why failsafe runs even though  I don't use gdm (but have it installed) ?
<Keybuk> alkisg: no idea on that
<alkisg> Thank you though :)
<\sh> Keybuk: what about SRU the ifupdown fix for upstart for "virtual" network devices like bonds/bridges/etc?
<\sh> Keybuk: for karmic that is:)
<dpm> hey kirkland, you've already got the first 4 new testdrive translations after the announcement :) -> https://translations.edge.launchpad.net/testdrive
<Keybuk> \sh: I know nothing about it?
<rickspencer3> ug
<rickspencer3> I just realized that our trendline for A3 points to the 24th instead of the 18th :(
<rickspencer3> we are way over
 * rickspencer3 cries
<Keybuk> rickspencer3: problem with the burnout charts?
<rickspencer3> oops
<rickspencer3> wrong burndown chart
<rickspencer3> I was looking at Dx
<rickspencer3> Keybuk, well, I think we should consider the 18th the cut off point for working on A3
<rickspencer3> that's the Thur before we release A3
<rickspencer3> right?
<Keybuk> alphas are a lot loser than beta
<Keybuk> really the tuesday before
<rickspencer3> yeah
<rickspencer3> ok
<Keybuk> but things sneak in overnight
<Keybuk> so the 23rd
 * sebner waves at rickspencer3 :)
<rickspencer3> Keybuk, how's it going? good trip back?
 * rickspencer3 waves to sebner
<Keybuk> rickspencer3: not too bad, slept for most of the flight
<Keybuk> and don't seem to be suffering too much for jet lag
<rickspencer3> nice
<Keybuk> and I now only have 1,700 mails left to read
<Keybuk> *cry*
<rickspencer3> Keybuk:
<rickspencer3> cntrl-A, Delete
<rickspencer3> spam a mail ...
<rickspencer3> oops, I lost my inbox
<rickspencer3> if you sent me something important in the last two weeks, please resend
<Keybuk> rickspencer3: sadly these are the important ones I have to actually deal with
<rickspencer3> you will get like 2 emails back
<\sh> Keybuk: the workaround^Wfix for bug #446031
<ubottu> Launchpad bug 446031 in ifupdown "statically configured network interface does not come up at boot" [High,Fix released] https://launchpad.net/bugs/446031
<Laibsch> Keybuk: the current Ubuntu delta is http://git.debian.org/?p=collab-maint/sl-modem.git;a=commitdiff;h=1a5b58d3f49902e7c9e6f85c4acee22d07550c1a
<Laibsch> we looked carefully through it and have pushed back where appropriate
<Laibsch> there is one remaining difference
<Keybuk> \sh: nothing to do with me
<Keybuk> \sh: I'm not planning an SRU
<Keybuk> in general, I don't do them
<Laibsch> debian/sl-modem-daemon.modutils which is installed as /etc/modprobe.d/sl-modem.conf: http://git.debian.org/?p=collab-maint/sl-modem.git;a=blob;f=debian/sl-modem-daemon.sl-modem.modprobe;h=01db2ad8f27d427fdf8f7d4a45970a3568082c62;hb=HEAD
<Laibsch> My feeling is that, actually it was these udev changes that broke sl-modem for me (and everybody else I know)
<Keybuk> Laibsch: looks right
<Keybuk> which udev changes?
<Laibsch> the stuff you changed in 2.9.11~20080817-3ubuntu2 because udev should "just do it"
<Keybuk> right
<Laibsch> http://git.debian.org/?p=collab-maint/sl-modem.git;a=commitdiff;h=1a5b58d3f49902e7c9e6f85c4acee22d07550c1a
<Keybuk> that fixed the module loading
<Keybuk> before that it wouldn't be loaded by anything
<Laibsch> apparently not
<Laibsch> but it may be something else
<Laibsch> Keybuk: do you have an sl-modem in some of your devices?
<Keybuk> and calling mknod from a modprobe script is just *wrong*
<Keybuk> Laibsch: nope
<Laibsch> :-(
<Laibsch> OK
<Laibsch> sl-modem doesn't really do anything at least since Jaunty for me
<Laibsch> the necessary devices are not created
<Keybuk> probably a bug in the kernel code
<Laibsch> But Jaunty was ubuntu2
<Keybuk> it's an out-of-tree driver
<Keybuk> so it's no surprise it's broken
<Keybuk> jaunty's kernel dropped support for a bunch of old-style ways of doing device nodes
<Laibsch> bug 375148
<Keybuk> the driver probably needs updating
<ubottu> Launchpad bug 375148 in sl-modem "no more /dev/ttySL0 device node" [Medium,Confirmed] https://launchpad.net/bugs/375148
<Keybuk> sure, so patch the driver to register it properly
<Laibsch> OK
<cjwatson> bryceh: I have a horrible feeling that I'm going to have to reimplement bullet-proof-X for my current project
<Laibsch> that's where we'd hope for some help from you
<Laibsch> Keybuk: Ahmed nor I are kernel-savvy
<Keybuk> Laibsch: I really don't have the time to do that
<cjwatson> bryceh: the reason is that the process structure of failsafeXServer is such that ubiquity-dm isn't going to get the required SIGUSR1 if it just calls failsafeXServer
<Laibsch> Keybuk: where is the place to look?
<Keybuk> Laibsch: the module init is a good place to start
<Keybuk> compare with an in-kernel driver
<Keybuk> though I have a sudden feeling that you may be hitting a gregkhism
<Keybuk> and that out-of-kernel drivers aren't allowed to have device nodes anymore
<Laibsch> which is?
<cjwatson> bryceh: besides, the calling convention isn't really ideal for me anyway.  Do you think it might be possible to split out the driver selection and xorg.conf.failsafe writing so that I don't have to duplicate it?
<Keybuk> well, non-GPL drivers
<\sh> Keybuk: your expertise regarding upstart, do you think it's sane to do an SRU with the fix in ifupdown?
<Keybuk> \sh: no
<cjwatson> bryceh: (or has kdm already done some of this?  I haven't looked at its bullet-proof-X implementation, if any)
<Laibsch> Keybuk: thanks.  I'll talk to the kernel guys to see if they confirm this (and possibly have a fix)
<Keybuk> Laibsch: no problem
<Keybuk> Laibsch: basically the way it's supposed to work is the module registers a chardev major or minor
<Keybuk> Laibsch: and that results in the uevent going out and udev making the device node
<Keybuk> a simple ttyUSB module should show the right code sequence
<Laibsch> sounds challenging
<Keybuk> it's really easy
<Laibsch> OK
 * Laibsch hopes for more of this mentoring
<Laibsch> I'm off to see what I can get from the information provided
<nailora> zim is a great desktop wiki, that recently switched to python (formerly perl). updated packages are in debian testing ( http://packages.debian.org/squeeze/zim ) but not yet in ubuntu. is there a chance it can be included in lucid?
<Keybuk> Laibsch: I think it's as simple as calling register_chrdev_*()
<bryceh> cjwatson, kdm hasn't done it afaik, but yes, splitting this out is definitely doable - in fact I just wrote up a blueprint yesterday for moving failsafex out of xorg
<bryceh> cjwatson, however there really isn't "driver selection logic" - it just picks vesa and pastes an xorg.conf into place.
<cjwatson> bryceh: there's a little bit for powerpc and the like :)
<bryceh> cjwatson, it used to be more sophisticated, but these days thats all we've needed
<cjwatson> bryceh: do you think it's a "by feature freeze" kind of thing, or should I just go ahead and hack something into ubiquity now which we can refactor later?
<cjwatson> if you don't think it'll change all that much, that might not be a big problem
<bryceh> cjwatson, what I'm working on is a lucid+1 type thing
<cjwatson> right, I'll hack something up for now and send you a reference then?
<bryceh> so I'd suggest the ubiquity hacking approach
<bryceh> sounds good
<Laibsch> nailora: open a ticket in Launchpad.  Google for DebianImportFreeze which is looming, you have little time.
<cjwatson> the next question is how the hell to test this, of course
<cjwatson> nailora: when did they hit squeeze?
<cjwatson> must have been recently, I synced in most of the new packages yesterday
<cjwatson>        zim |     0.43-1 | lucid/universe | source
<cjwatson> it failed to build: http://launchpadlibrarian.net/38664080/buildlog_ubuntu-lucid-i386.zim_0.43-1_FAILEDTOBUILD.txt.gz
<cjwatson> looks like a debian vs. ubuntu python thing
<cjwatson> I can probably fix that up
<nailora> cjwatson: i would appreciate that a lot!
<nailora> Laibsch: thanks for your hint
<cjwatson> running build
<cjwatson> Enter passphrase for key '/home/cjwatson/.ssh/id_rsa':
<cjwatson> What. The. Heck.
<cjwatson> nailora: you can skip Laibsch's comment though, doesn't need a bug
<cjwatson> it would have needed a bug if it hadn't actually been synced already
<Keybuk> cjwatson: damn, I've already harvested over a dozen passphrases that way
<nailora> cjwatson: i did not / do not file a bug while you are looking at it / working on it. just wanted to thank him that he bothered to reply.
 * cjwatson nods
<nailora> and i have absolutely no idea about why it asks for an ssh key
<cjwatson> it's under 'bzr version-info --format python', but that shouldn't normally need to connect to anything
<cjwatson> I could just use the source package, I suppose, but ...
<cjwatson> must be because it's a checkout.  urgh.
<cjwatson> yeah, all better if I unbind.
<bdrung> cjwatson: you did some uploads of ntfs-3g. can you merge the newest version from Debian (bug #513197)?
<ubottu> Launchpad bug 513197 in ntfs-3g "Please merge ntfs-3g 1:2010.1.16-0.1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/513197
<cjwatson> bdrung: ok
<bdrung> cjohnston: thanks
<\sh> c/quit
<\sh> argl
<persia> \sh: you're stuck here, and can never leave :)
 * ogra humms hotel california
<cjwatson> xnox: err, why are you sending linkedin invitations to Launchpad merge proposals?
<xnox> cjwatson: LinkedId did it for me
<xnox> I'm very sorry
<ogra> cjwatson, business reasons :)
<cjwatson> !
<xnox> I use gmail and it imported
<cjwatson> surely it's within your control which addresses you use
<xnox> all the emails
<cjwatson> ok, please please be more careful in future
<xnox> I will I'm sorry
<cjwatson> maybe there should be a more free-software-friendly equivalent of linkedin ;-)
<xnox> yeah. And maybe spam filters should catch invintations to facebook / linkedin and all those things
<xnox> I've dented & tweeted & blogged about the incident now
<ogra> sadly they dont ... i seem the invites regulary
<xnox> Again sorry =(
<ogra> on MLs i'm on
<nailora> cjwatson: i am not exactly sure if you succeeded, but thank you for having a look at it on all accounts
<ogra> which usually creates a flamewar
<cjwatson> xnox: ah, didn't see the blog entry, sorry for the duplication then
<cjwatson> nailora: nearly done
<xnox> cjwatson: well I've hit the publish button a few seconds after your ping on irc ;-)
<cjwatson> nailora: actually, you know what, it's fixed in unstable, I'll just sync it
<cjwatson> needs a new debhelper so I'll have to merge that
<sebner> rickspencer3: any idea whom I wan to contact about questions regarding the canonical store?
<sebner> *want
<rickspencer3> sebner, is there not contact information on the web page?
<rickspencer3> tbh, I have no idea
<sebner> rickspencer3: there is (I'm trying to help one in the german ubuntu support forum) but no reply in months.
<sebner> nvm then
<rickspencer3> sebner, that sux
<rickspencer3> this channel is prolly not a great place to get support for that though
<rickspencer3> perhaps #ubuntu?
<sebner> rickspencer3: sure, therefore I was highlighting you ^^
<bluefoxicy> we should make more things jiggly
<bluefoxicy> menus should jiggle when they drop
<bluefoxicy> resizing a window should stretch it, like it's rubber, following and then snapping to its new size
<persia> Please no.
 * bluefoxicy takes that sentence structure away
<bluefoxicy> "we should have more jiggly things" <--> "you should make things more jiggly"
<persia> That's even less exciting :)
<Keybuk> things should not jiggle
<Keybuk> that's why the jockstrap and the bra were invented
<bluefoxicy> persia:  the "enhanced" graphics thing that adds "more pleasing visual effects" seems to only make the windows jiggly when you move them
<bluefoxicy> that's all it does
<bluefoxicy> windows now jiggle when they're dragged
<persia> Not mine, but I take care to keep my environment pleasing by uninstalling stuff that claims to make it "better" :)
<bluefoxicy> i just think the modes shouldn't be "non-accelerated" vs "Composited" vs "Composited, and windows jiggle when dragged"
<bluefoxicy> if I want jiggly windows, it's probably even better to have a fully action-oriented desktop
<bluefoxicy> windows appear by being explosively thrown on the screen (see original Gnome Wobbly Windows demo); minimized windows squish and flow into the taskbar buttons; menus slide and stretch and wobble into place as they drop
<bluefoxicy> if I don't want all that stuff, it's likely I don't want my windows to jiggle like jello jigglers either
<Keybuk> bluefoxicy: and if you move a window too fast, it could burst into flames
<bluefoxicy> xD
<persia> bluefoxicy: I'm in complete agreement with that: if you want wiggly bits, you should have *lots* of them.
<bluefoxicy> yeah it just makes sense
<jono> seb128, do you know offhand if the IMAP speed-up features in Evolution are in Lucid?
<jono> I am considering moving back from TB
<micahg> jono: hopefully TB3 will hit Lucid this weekend if it helps any
<jono> micahg, cool! I am running it our of their upstream release right now
<jono> the search is just so slow though
<jono> the whole new tab and search view feature
<snap-l> Does Evolution have any plans of using a better HTML rendering engine?
<micahg> jono: you can change the search with teh drop down back to the old style
<snap-l> Tht's been the real deal-breaker for me with Evo. That and threading
<kees> mdeslaur: btw, new virt-manager rocks.  :)
<mvo> ev: ubiquity-slideshow-ubuntu-upgrade> yes
<ev> mvo: awesome, I'll upload that tonight then
<mvo> ev: very nice
<bdrung> Keybuk: you are the maintainer of mountall. i wanted to run mountall with --debug (for providing more information to bug #507613) and write it into a file, but when mountall is launched, there is no writeable file system. do you have an idea how to get the debug information?
<ubottu> Launchpad bug 507613 in mountall "boot stops due to failed mounting of a sshfs partition" [Undecided,New] https://launchpad.net/bugs/507613
<Keybuk> bdrung: write it to a tmpfs ?
<Keybuk> like /dev
<bdrung> Keybuk: and how can i save the file to survive the reboot?
<Keybuk> bdrung: remount the filesystem r/w and copy it over?
<bdrung> Keybuk: the system will hang. so i cannot type commands into the terminal
<tlyu> does the launchpad bug watch updater only run periodically? i updated a debian bug that is linked in launchpad; should i expect the change to propagate?
<arand> tlyu: yea, I think daily at least, definitely not instant.
<bdrung> tlyu: yes, it's run periodically (or there is a other reason for the delay).
<tlyu> ok, thanks
<bdrung> tlyu: we had a bug that prevents the update, but this bug is already fixed.
<ari-tczew> any sponsor for main got a minute?
<frafu> Hi, could anybody please tell me whether it is normal that python-distutils-extra and DistUtilsExtra.auto have two different version numbers?
<frafu> Hi pitti; could you have a look at LP: #520548 ? Thanks.
<frafu> https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/520548
<ubottu> Ubuntu bug 520548 in python-distutils-extra "DistUtilsExtra.auto.__version__ gives wrong version" [Undecided,New]
<bdrung> slangasek: hi. You did many uploads of hdparm. can you merge version 9.27-2 from Debian (bug #516249)?
<ubottu> Launchpad bug 516249 in hdparm "Please merge hdparm 9.27-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/516249
<DktrKranz> mvo: Debian gdebi branch with common ancestor from LP ready
<mvo> sweet, many thanks DktrKranz
<lamalex> Is there a way to install debs to an alternate location for testing?
<DktrKranz> mvo: thanks for letting me know, it's definitely more manageable now! :)
<lamalex> I'm working on some modifications to dpkg I need to test- but I'm understandably weary about replacing my system's dpkg :P
<mvo> :)
<mvo> DktrKranz: cool, I hope it was not too much fiddling around
<lamalex> mvo: I think you're probably who I want to talk ask specifically :)
<DktrKranz> (right now there are 6 conflicts, but nothing troublesome)
<lamalex> s/talk//
<mvo> lamalex: cjwatson is our best dpkg expert currently I think, but I may be able to help as well
<lamalex> mvo: you at least know about hacking on parts of your system you dont want to break
<mvo> haha - oh yes
<lamalex> :)
<mvo> chroot and kvm FTW!
<lamalex> yeah, I was hoping there was an easier way. some dpkg flag. but I guess when I'm installing dpkg, if I break dpkg, a dpkg flag won't help me haha
<lifeless> or lvm snapshots
<lifeless> but they are pretty crude
<lifeless> +1 on kvm (or uec even :))
<lamalex> and I dont think I have lvm on this machine anyway
<mvo> lamalex: well, it depends on what bits you are working on, a copy of the status file is certainly a good idea :) what changes are you making?
<lamalex> mvo: I emailed you a while ago about dynamic dependencies
<lamalex> we decided to do it at the dpkg level
<mvo> lamalex: ohh, right. I remember that mail. didn't I reply? I think I did
<lamalex> you did
<bigon> could someone have a look at papyon merge? the new version is really needed in ubuntu
<seb128> jono, I doubt it, we stay on 2.28 which is the karmic version...
<mvo> DktrKranz: I merged the debian branch now into trunk, I think we are there for a unified version :) if you could double check, that is most appreciated
<DktrKranz> mvo: looking
<persia> Could an archive-admin take a look at the swt-gtk binary NEW?  The new packages are handovers from eclipse, which has already been uploaded to not build them anymore.
<DktrKranz> mvo: sounds good, your soultion for ubuntu-specific patches is great
<Caesar> I thought the outcome at UDS was for the Sun Java packages to move to the partner repository?
<persia> Caesar: swt-gtk isn't Sun Java.  VM vs. libraries.
<Caesar> parse fail
<persia> Caesar: I had the impression the UDS discussion was just about the sun-java6 package.
<Caesar> Yes, that's what I'm asking about
<persia> heh.  Gets confusing sometimes.  But other stuff, like swt-gtk, netbeans, etc. should just be in the regular repo.
<Caesar> There's no sun-java6 to be found anywhere
<persia> Hurrah!
<Caesar> No, not really
<persia> Why?
<Caesar> I was expecting to be able to find it in the partner repo
<Caesar> We have business requirements for it
<Caesar> Or so our Java people tell me
<persia> Aside from about 3 API calls and some function renames, we're mostly good with OpenJDK, and OpenJDK has lots of bugfixes (even from Sun) that sun-java6 still doesn't have fixed.
<Caesar> The Android SDK explicitly says it wants Sun Java, last time I looked
<Caesar> and I once tried to use it with OpenJDK and it broke in weird and wonderful ways
<Caesar> Where once is ~ 6 months ago
<persia> Ugh.  Yeah, unfortunately there is still some stuff that needs porting work to deal with distributed libraries.  Nothing like the volume that will be required with Java 7, but without code, some stuff can't yet run on OpenJDK (and even with code, some stuff is obnoxious to port)
<soren> Hm... Firefox has forgotton about all my search engines except Ask.com.
<[reed]> soren: iirc, that's because of the way ubuntu does the packaging
<soren> I can't help but notice that the search plugin things in the firefox package are kept in a directory called en-US, so perhaps they're limited to that locale?
<soren> Guess not..
<soren> set default searchplugin locale pref to en-US - which is used as a fallback if no matching searchplugins/LOCALE directory exists for the current locale directory
<soren> from firefox' changelog.
<micahg> soren: we're working on localized plugins
<soren> micahg: ..but until then, anyone not on en-US is without search plugins?
<soren> micahg: Oh, found the problem. Yay.
<micahg> soren: great, what was it?
<soren> micahg: /usr/lib/firefox-addons/searchplugins was a symlink to '.' rather than en-US.
<micahg> soren: is that in the package or you mad that?
<soren> Oh, sorry, I meant /usr/lib/firefox-addons/searchplugins/common
<soren> In the package, I suspect. I certainly didn't make it so.
<soren> https://bugs.edge.launchpad.net/ubuntu/+source/firefox/+bug/520682
<ubottu> Ubuntu bug 520682 in firefox "Only search provider is Ask.com" [Undecided,New]
 * micahg is looking at teh packaging now
<soren> micahg: Lovely, thanks.
<soren> grep search debian/firefox.links
<soren> /usr/lib/firefox-addons/searchplugins /usr/lib/firefox-addons/searchplugins/common
<soren> micahg: ^^ There's our problem.
<micahg> hmm
<soren> That should read "/usr/lib/firefox-addons/searchplugins/en-US /usr/lib/firefox-addons/searchplugins/common"
<micahg> soren: I don't know if we want to do that...but I'll check...I think we're shooting for localized plugins this time around
<micahg> asac: ^^
<seb128> siretart, siretart_: hi
<seb128> siretart, siretart_: thanks for your seahorse change, when you do upload something maintained in bzr could you update bzr too though?
<seb128> siretart, siretart_: or ping somebody to sponsor your change if you don't want to do that
<StevenK> seb128: I've accepted launchpad-integration, I'm going to do a no-change upload for tomboy and gbrainy so they link against the right binary package
<seb128> StevenK, ok thanks
#ubuntu-devel 2010-02-12
<geser> someone from ubuntu-release around? I want to ask if it's still enough time to start a OCaml "transition" (new upstream version) with FF only a week away. From a look at the (long) list of affected packages mostly only no-change rebuild will be necessary and only a few syncs.
<geser> (see bug #519199)
<ubottu> Launchpad bug 519199 in ocaml "Sync ocaml 3.11.2-1 (main) from Debian sid (main)" [Undecided,Triaged] https://launchpad.net/bugs/519199
<Hellow> I would say it's possible; Then again, I am far from an expert on the topic :).
<slangasek> geser: yes, that's possible
<geser> slangasek: getting FF exceptions (when necessary) won't be a problem then?
<slangasek> shouldn't be, no
<geser> thanks
<StevenK> geser: If you need help, I'm happy to do so
<geser> StevenK: I'll certainly need sponsoring for the packages in main, thanks for the offer
<StevenK> geser: If it's just rebuilds I can do them, too
<geser> StevenK: mostly rebuilds as we have the same version as Debian testing/unstable. see the page from dmentre for the status and the rounds: http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html
<geser> I guess dmentre will monitor it and announce when the next round can be started like he did during the last transition
<arakthor> hi
<arakthor> I'm looking to help by developing with ubuntu or related projects on my spare time. I chekced the wiki and it looks like I can start trying packaging and fixing bugs. Which sort of bugs would be best to start looking at?
<arand> arakthor: #ubuntu-motu might be a better starting point.
<arakthor> arand, thank you for the suggestion. the wiki seemed to say the motu was more appropriate for people with more packaging experience; however, I will look there.
<persia> arakthor: What sort of packages interest you?
<persia> arand: Why is -motu a better starting point?  Does it not depend on people's interest?
<arakthor> hi persia, from my perspective I usually enjoy programming for low-level applications (on embedded platforms anyway - but I'm not an algorithm wizard). I also would like to learn more about security. I enjoy being able to see the changes from my code so desktop and utilities are probably my best starting point.
<arand> persia: just figured it a generally more active channel, and as a *startup* I though it would be more helpful, just as a channel...
<persia> arakthor: #ubuntu-desktop is the right channel for desktop stuff, and #ubuntu-hardened for security.  We don't currently have much embedded stuff, although "embedded" is a funny term, and there's lots of Ubuntu that can run on very small hardware (as long as there's a couple gig flash).
<arakthor> most of my experience with embedded has been on hardware that cannot run ubuntu; usually with no OS or uCOS
<persia> Work on the low-level applications tends to happen here, but that's usually left to our most expert developers: I'd recommend working in other areas until you've gotten some experience with how we work.
<persia> arand: I guess I'm oversensitive: we used to force all new contributors to work with MOTU first, but now we're working on enabling interest-based groups to do stuff instead of forcing MOTU->core.  As a result, I prefer to send people to channels that interest them, rather than pointing at MOTU who usually end up telling people to fix FTBFS or help with transitions and the like, which doesn't interest everyone.
<persia> arakthor: That's stuff we just can't handle :)
<persia> arakthor: There are ports to powerpc and armel though, some of which can run on devices some people consider "embedded".
<arakthor> yeah, not as hard anymore. I have maemo on my phone and that's rather nice in some ways.
<persia> and hardly "embedded" :)
<Caesar> slangasek: ping
<arakthor> well persia, thank you for the pointers. I will try to talk with somewhere there in the next day or two. have to go study now though. have a good night (or day; or morning)
<persia> arakthor: Good luck.
<lifeless> ev: https://code.edge.launchpad.net/~mbp/usb-creator/477529-cruzer/+merge/18311 please comment.
<lifeless> Fixes Are Good
<Caesar> bdmurray: I'm not exactly sure why bug #519119 hasn't been automatically marked as fixed
<ubottu> Launchpad bug 519119 in autofs "Transitional packages need some reworking" [Low,Triaged] https://launchpad.net/bugs/519119
<Caesar> The fact that it got uploaded by zul doesn't seem to have been noted on the bug
<persia> That would happen if the .changes file didn't have the Launchpad-bugs-fixed: header.
<Caesar> Oh
<Caesar> So zul did something wrong when he built the package with my debdiff?
<persia> Last upload seems to be 14 weeks ago, according to https://launchpad.net/ubuntu/+source/autofs
<persia> Your patch appears to have the correct notation.
<Caesar> Hmm, ogra was pointing me at something yesterday that indicated two uploads
 * Caesar consults rmadison
<Caesar> rmadison says it's at 5.0.4-3.1ubuntu4
<persia> For binaries, but not for source.
 * persia is confused
<Caesar> autofs5 | 5.0.4-3.1ubuntu4 |         lucid | source, amd64, i386
<Caesar> That says to me the whole box and dice
<ajmitch> autofs vs autofs5
<persia> the bug is against autofs, not autofs5
<Caesar> Ah
<Caesar> It's all messy, the autofs5 source package is taking over some of the autofs(4) packages
<persia> Is the autofs source still needed with the presence of the autofs5 source?  If not, it may be worth filing a removal bug.
<persia> Only some, or all?
<Caesar> No, it's no longer needed
<persia> So there are transition packages for all the binaries produced by autofs source?
<Caesar> Yes
<Caesar> There are now
<persia> Then yeah, file a removal bug :)
<Caesar> Will do
 * persia can't ACK it, but maybe zul will
<Caesar> I'll just bump this bug over to autofs5 for anatomical correctness
<persia> But anyway, regarding the specifics of bug 519119 : ideally the bug task would have been changed to be against the autofs5 source if that was where it was being fixed.
<ubottu> Launchpad bug 519119 in autofs5 "Transitional packages need some reworking" [Low,Triaged] https://launchpad.net/bugs/519119
<persia> And if that was done, then the bug should have been automatically closed by the upload.
<Caesar> Yeah I think I was a bit confused when I filed it
<Caesar> Okay, so I'll just mark the bug as fixed now?
<persia> No worries.  Just mark it Fix Released manually, and note the package source and version that was uploaded to fix it.
<persia> Yes.
<Caesar> Done
<Caesar> Now to file the removal bug for autofs (source)
<persia> Any other questions about how this happened that I can answer, or was the above clear enough?
<Caesar> persia: no, that was all very helpful, thanks
<persia> Cool.
<Caesar> Does https://bugs.launchpad.net/ubuntu/+source/engine-pkcs11/+bug/512368 just need a sync request?
<ubottu> Ubuntu bug 512368 in engine-pkcs11 "Sync request: engine_pkcs11 0.1.8-2 from debian unstable (incoming)" [Wishlist,New]
<Caesar> It's fixed in Debian
<persia> Caesar: That *is* a sync request.
<persia> It's just waiting on an archive-admin to process it.
<ajmitch> but no sponsors subscribed, just the archive admins
<persia> fabricesp doesn't count as a sponsor?
<persia> Oh, subscribed.
<persia> But he subscribed the archive-admins, so it oughtn't matter.
<ajmitch> even with the status still at New?
<persia> Hrm.  That's a good question.
<persia> StevenK: As a procedural matter, would an archive admin consider something actionable if the archive-admins were subscribed by a developer with upload permission to the affected package, but there wasnt an explicit ACK, and the bug state was "New"?
<crypt-0> i have a question about kernel module
<twb> Am I mad?  It looks like ubuntu-keyring STILL isn't using jetring
<crypt-0> where can i check on the status of a kernel module? i want to see if a specific module is considered "stable" yet.
<NCommander> Can any GCC guru shed some light on https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009?
<ubottu> Ubuntu bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed]
<NCommander> I don't know enough about GCC's internals to understand if OpenOffice.org is goofing its test up or not, or theres a regressionin GCC
<slangasek> Caesar: pong
<Caesar> slangasek: hi
<Caesar> I wanted to float the possibility of a import freeze exception for Puppet and Facter
<StevenK> Caesar: We have stopped automatic syncs, but manual syncs are still permitted until FF.
<StevenK> Unless we've changed it for Lucid.
<crypt-0> anyone have info why the cryptsetup package inst upgraded to the 1.1.0?
<crypt-0> its still using a release candidate for Lucid
<crypt-0> the final has been released at http://code.google.com/p/cryptsetup/
<Caesar> StevenK: ok thanks
<pitti> Good morning
<dholbach> good morning
<dholbach> pitti: is it expected that a jockey window pops up during a ubiquity installation?
<dholbach> (with an empty window)
<dholbach> pitti: http://people.canonical.com/~dholbach/Bildschirmfoto-QEMU.png
<pitti> re
<pitti> dholbach: I fixed that yesterday
<pitti> dholbach: is that jockey 0.5.7?
<dholbach> pitti: it's yesterday's image, so yeah, it probably wasn't fixed back then
<pitti> ah, *phew* :)
<ttx> cjwatson: ping about some eucalyptus-udeb magic...
<ttx> cjwatson: to support the case where there are multiple CCs (clusters) on a single network, spec says SC / NC should advertise which one (ideally by cluster name) they want to join
<ttx> cjwatson: Ideally we would preseed eucalyptus/cluster-name in the SC or NC installs based on discovery
<ttx> cjwatson: I'm just unsure how to best plug that into eucalyptus-udeb.postinst... At that point only the NC has a cluster selection, and it's IP address only.
 * ttx wonders if multiple clusters on a single network really make any sense.
<smoser> i'm starting a new package, trying to use bzr distributed development mode
<smoser> how can i do what merge-upstream-release would do for the initial packaged release
<smoser> james_w, ^?
<smoser> it fails with :
<smoser> bzr: ERROR: Unable to find the tag for the previous upstream version, 1.1.0, in the branch: upstream-1.1.0
<siretart> seb128: re: my seahorse-plugins upload: I did use bzr, and I did push my work to lp:ubuntu/seahorse-plugins
<seb128> siretart:...
<siretart> was that wrong?
<seb128> siretart: apt-get source tell you what to use
<seb128> or look to control
<seb128> yes
<seb128> it's under ubuntu-desktop with the debian dir only in bzr
<siretart> oh, indeed. my bad, I'm sorry
<seb128> siretart: np, I've fixed it yesterday since I had an another upload to do
<siretart> hm. I generally dislike seperating debian/ from the upstream source.
<siretart> in this case, it wouldn't have mattered since I didn't touch upstream code
<siretart> so I was quite happy with the branch lp:ubuntu/seahorse-plugins
<siretart> seb128: speaking of seahorse: do you know someone who could be bribed with an smartcard reader and a gpg smartcard to (finally) implement support for that in seahorse-agent?
<seb128> siretart: not really
<siretart> seb128: I notice that the seahorse-plugins packaging branch has a root directoy that contains only a subdirectory. can you explain my why not moving the contents of that subdirectoy one level up?
<seb128> because that's how you use debian dir only with bzr-buildpackage
<seb128> it will get the tarball and copy the debian dir over and build
<siretart> bzr-buildpackage certainly doesn't require it
<seb128> that's how we always did debian dir in vcs for gnome
<seb128> since debian svn for pkg-gnome to current ubuntu-desktop workflow
<seb128> nobody questionned it before ;-)
<siretart> I'm questioning this practice since years
<seb128> I find it handy to have the debian dir being named debian
<siretart> for svn, it makes more sense because you have partial checkouts
<seb128> rather than having ubuntu/ being the debian dir
<seb128> well with current scheme you can cp debian over to a source
<siretart> for bzr, I consider it utterly inconvenient and unnecessary
<seb128> without having to mkdir debian
<seb128> and cp ubuntu...
<siretart> well, if the packaging was toplevel, you could just *checkout* in an upstream source directory
<siretart> currently you have to clumsily fiddle around with cp/mv to have things in the right place
<seb128> no you couldn't
<seb128> since the directory is named ubuntu, not debian
<siretart> I think I'll continue using the lp:ubuntu/$package branches and mail you the diff
<seb128> you would get ubuntu with the debian dir content
<siretart> of course you can: 'bzr get :~ubuntu-desktop/seahorse-plugins/ubuntu debian'
<seb128> siretart: please don't, open a sponsoring request rather than private emailing me
<siretart> of course you can: 'bzr get lp:~ubuntu-desktop/seahorse-plugins/ubuntu debian'
<seb128> if you don't want to update the official bzr
<siretart> that will create the branch in a subdirectory called 'debian'
<Laney> is there something like svn-do for these branches?
<frafu> Hi pitti, do you have a minute? Should the version of python-distutils-extra not be the same as the version of DistUtilsExtra.auto?
<seb128> Laney, what does svn-do do again?
<Laney> starts a subshell with the upstream source + debian dir
<frafu> https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/520548
<ubottu> Ubuntu bug 520548 in python-distutils-extra "DistUtilsExtra.auto.__version__ gives wrong version" [Undecided,New]
<Laney> useful for doing patches, for exmaple
<seb128> Laney, bzr bd-do
<Laney> cool
<siretart> seb128: opening sponsoring request? that sounds like an awful lot of burocracy and added latencies when I could also just upload it. this way my patch went into the official branch in hours (without attribution in the bzr log, but still)
<seb128> siretart: not the official one
<seb128> one which we are not using
<frafu> Or does anybody else know the answer?
<seb128> which break next upload since the official vcs is outdated
<Laney> seb128: you can have those lp:ubuntu/xxx branches update to the ~ubuntu-desktop ones I think
<Laney> to point to the^
<siretart> Laney: that is what I was using
<seb128> Laney, we don't have a full source there
<seb128> would that work too?
<Laney> is that a requirement?
<Laney> I don't know
<seb128> james_w, ^
<seb128> siretart: you are just breaking other people package and workflow by doing that
<james_w> it is a requirement
<seb128> siretart: either update the official bzr or ask for sponsoring
<siretart> I thought for UDD lp:ubuntu/$package was 'official'
<siretart> I'll revisit the ubuntu wiki, need to run now, though.
<frafu> Does anybody know who I should contact to not hide by default the menu items of the onscreen keyboard onboard that is part of the Ubuntu distribution?
<seb128> siretart: dunno what is official or not but we don't use those for desktop components
<seb128> see control file or apt-get source for the vcs to use
<cjwatson> ttx: maybe the preseed file generated on the CC (debian/eucalyptus-udeb.finish-install) should set cluster-name to match the name of that cluster
<ttx> cjwatson: that wouldn't solve it for the SC (which downloads from the CLC)...
<cjwatson> ttx: it may well be a bug that SC installation doesn't do CC selection if it found more than one
<ttx> cjwatson: I'm testing a fix right now
<ttx> cjwatson: question: I'm using netboot for testing the latest crack, but apparently eucalyptus-udeb is downloaded before apt-setup/local0 takes effect
<cjwatson> correct
<cjwatson> apt-setup doesn't affect udeb installation anyway
<cjwatson> apt => deb, anna => udeb
<ttx> cjwatson: is there any way to preseed additional repositories in a way that would make it retrieve udebs from an alternate repo ?
<ttx> I'm trying to netboot from my localmirror + a repo that has my eucalyptus WIP
<cjwatson> ttx: you can't acquire udebs from more than one repo; the acquisition code isn't smart enough
<cjwatson> you can change it to acquire from just a single repo
<cjwatson> by setting mirror/http/hostname (and if necessary mirror/http/directory) on the kernel command line, I think
<ttx> cjwatson: arh.
<cjwatson> ttx: to fetch eucalyptus-udeb from somewhere else, I just use this trick:
<cjwatson> d-i preseed/early_command string wget http://url/to/your/package && udpkg --unpack eucalyptus-udeb_whatever_whatever.udeb
<cjwatson> and then boot with url=http://url/to/that/preseed.cfg
<ttx> cjwatson: nice
<ttx> I'll try that, thanks.
<soren> Oh, we've dropped tracker by default?
<soren> I suppose this could be years ago. It's been a while since I've done a regular desktop install :=)
<seb128> soren, since hardy
 * soren chuckles
<soren> Ok :)
<soren> Did we replace it with something else?
<seb128> no
<soren> Alright.
<seb128> we decided that it was not useful enough to justify the io cost
<seb128> linux is not good at handling io load nicely
 * soren tends to agree
<soren> I was just curious to see that state of it and was surprised it wasn't installed. No worries at all.
<ttx> cjwatson: testing the early_command trick: I get "Menu item 'eucalyptus-udeb' selected" before 'download-installer', so eucalyptus-udeb.postinst fails with missing avahi lib
<cjwatson> you might need to add in some manual wget/udpkg pairs for dependent udebs
<cjwatson> bit of a hack
<ttx> cjwatson: no way to run 'download-installer' module before 'eucalytpus-udeb' ?
<cjwatson> dunno, sorry, can't think about this right now
<ttx> cjwatson: no pb :)
<cjwatson> don't see why udpkg --unpack would affect menu item ordering, you didn't change it to udpkg -i did you?
<ttx> no...
<ttx> cjwatson: fyi, looks like this works: early_command=anna net-retriever && wget eucalyptus-udeb... && && udpkg --unpack eucalyptus-udeb...
<pitti> jdstrand: would be grand if you could do the udisks source NEW today; it's just an upstream product/source package renaming, not really a new thing
<jdstrand> pitti: ack
<pitti> jdstrand: thanks (just uploaded, should hit the queue in 2 mins)
<jdstrand> k
<smoser> Keybuk, around ? I'm wondering if you're expecting to address bug 504883 in near term.
<ubottu> Launchpad bug 504883 in udev "job with "mounted MOUNTPOINT=/ and net-device-up IFACE=eth0" blocks boot" [Medium,Triaged] https://launchpad.net/bugs/504883
<pitti> jdstrand: thanks, that was fast!
<jdstrand> pitti: ask and ye shall receive :)
 * persia watches for a wild flurry of requests
<pitti> I want a pony!
<pitti> actually, can I _give_ you a second of boot time? with getting rid of that, we'd be almost there :)
<jdstrand> hehe
<Keybuk> cjwatson: this grub-install issue is odd
<Keybuk> so I press enter, and it prompts me what to do (including choose a different device)
<Keybuk> I choose /dev/sda
<Keybuk> it goes back, whirrs, and tells me that grub-install (hd0) failed again
<Keybuk> smoser: bugs get addressed after FF
<Keybuk> I have a bunch of updates before FF I want to do
<Keybuk> then I'll fix bugs
<Keybuk> because I'm sure my updates will cause lots of new bugs :p
<Keybuk> (and may even fix that one anyway)
<smoser> Keybuk, fair enough. my interest in this one is that when i then move cloud-init to running much earlier in the boot process, i'll likely have bugs myself.
<smoser> so sooner rather than later would be nice
<Keybuk> smoser: though I can't remember what solution to that one we decided
<smoser> i think its a bug in udev and then those rules "should work", per slangasek
<Keybuk> was that just the bug where the event went missing?
<cjwatson> Keybuk: unfortunately my response to you is approximately the same as your response to smoser, because I have about three hours of work time left before FF :-/
<Keybuk> cjwatson: that's fine ;)
<smoser> Keybuk, right, missing event
<Keybuk> cjwatson: obv it's critical for alpha 3 since you can't actually install right now ;)
<Keybuk> but I can run grub-install by hand :p
<cjwatson> Keybuk: I never did manage to reproduce your bug, but I only had a chance to try it through once in manual mode
<cjwatson> Keybuk: manual mode worked fine for me ...
<Keybuk> cjwatson: auto mode fails every time for me
<Keybuk> even on a usb key with me being the chicken
<cjwatson> oh, even auto mode with no preseeding?
<Keybuk> right
<cjwatson> *that* I can probably set up quickly
<Keybuk> that's how I know it failed when I got to choose a different disk
<Keybuk> I don't remember getting that choice with preseeding
<cjwatson> though it could be related to using a USB key of course
<cjwatson> my tests are in KVM with one disk, at the moment
<LaserJock> superm1: around?
<Keybuk> could be, though the automated stuff is NFS
<cjwatson> hm
<cjwatson> grub-installer shouldn't notice that
<Keybuk> right
<cjwatson> ScottK: do you know where Lucas' rebuild test for foundations-lucid-supportable-binaries is?
<cjwatson> ScottK: I'm sure I could do some quick analysis of it if that's what's required to unblock this spec
<persia> cjwatson: lucas just posted a new rebuild test : https://lists.ubuntu.com/archives/ubuntu-devel/2010-February/030230.html
<persia> cjwatson: From what I've heard (although this may not be complete), the idea is to try to get the number as low as possible, and then start filing removals later.
<cjwatson> persia: thanks.  we should prepare the method for getting the list in advance, though
<cjwatson> because it isn't just Lucas' list; it's anything in Lucas' list that hasn't been otherwise rebuilt since karmic
<persia> cjwatson: Ah, so we need to compare against http://qa.ubuntuwire.com/multidistrotools/unchanged/unchanged_since_karmic
<cjwatson> well, or the trivial python thing I have to do the same test
<cjwatson> but sure
<persia> heh, that works too, but doesn't have a handy URL :)
<superm1> LaserJock, what's up?
<cjwatson> lp:~cjwatson/+junk/suite-diff
<LaserJock> superm1: I just got bit by bug #506816
<ubottu> Launchpad bug 506816 in dkms "wl missing after Karmic -> Lucid upgrade" [High,Confirmed] https://launchpad.net/bugs/506816
<superm1> LaserJock, cool! so hopefully you can help figure out the root cause :)
<LaserJock> superm1: I saved the /var/lib/dkms/bcmwl directory and did the dpkg-reconfigure
<LaserJock> superm1: what all do you need?
<superm1> LaserJock, there is a make.log in there for the kernel that it didnt build on hopefully
<LaserJock> superm1: the only kernel dir is for the Karmic kernel
<LaserJock> superm1: I have a 5.10.91.9+bdcom dir and kernel-2.6.31-19-generic-i686
<superm1> LaserJock, ooh weird.
<persia> Could it potentially be that it built for the *running* kernel, rather than the newly installed kernel?
<james_w> smoser: hey, you can use bzr dh_make from lp:bzr-builddeb or the upload I will be doing today
<smoser> james_w, so heres what i did... tell me if i should bothe rwith dh_make
<superm1> persia, i wouldnt suspect so at least, because the /etc/kernel/postinst.d scripts are called with the argument of the kernel to process
<superm1> LaserJock, but it wouldnt hurt to run modinfo on the kernel module in that bcmwl directory to see if its built against the proper kernel
<smoser> bzr init; mkdir debian; bzr add debian; (add some basic debian dir, with version 0.0) ; bzr add debian; bzr commit ; bzr tag upstream-0.0 -r 1; bzr merge-upstream
<smoser> that seems to work with the only exception that i had to 'bzr resolve debian'
<LaserJock> superm1: modinfo gives me: vermagic:       2.6.31-19-generic SMP mod_unload modversions 586
<tseliot> slangasek: do we include plymouth in the initramfs?
<slangasek> tseliot: not unless we have to (cryptsetup)
<tseliot> slangasek: ok, so things should work without an initramfs, right? Provided that we have a framebuffer device and kms
<superm1> LaserJock, well can you post the tgz of your /var/lib/dkms/bcmwl directory prior to dpkg-reconfigure'ing to the bug and this information so far from IRC.  I dont have any other ideas off hand though unfortunately right now
<tseliot> slangasek: I mean by getting rid of the initramfs (not that I want to do that in Lucid but it may come in handy for oem)
<superm1> slangasek was there a deliberation about whether it will be included in the casper case, or is that still up for discussion?
<ogra> it should efinately stay in casper ... unless we speed it up a lot
<superm1> i've currently got some tools that would be dependent upon that, but could possibly be refactored otherwise
<superm1> ogra, well casper should be significantly faster thanks to JamieBennett's recent changes
<ogra> not on arm though
<ogra> he cut of a third from the bootptocess ... but thats not much with 1.5min
<smoser> james_w, does the above look not ok ?
<james_w> smoser: that works I guess
<james_w> it gives you a slightly odd branch in that you will have two roots, but it's not illegal to have that
<superm1> ogra, well I suppose perhaps the decision of whether or not plymouth is in the initramfs could also be arch dependent though, so x86 doesn't get it, but arm does
<superm1> ogra, but what's the slowest piece now on arm?  is there still a lot of room for improvement you think?
<ogra> there likely is but not in lucid
<cjwatson> plenty of x86 casper boots are still clearly slow enough to require a splash screen, and I don't anticipate that changing given typical CD read speeds
<ogra> and indeed it could be based on arch detection
<cjwatson> arch detection is a bit of a red herring there I think
<cjwatson> you're right that it could, but I don't think it should
<ogra> yeah, but technically you could do that
<ogra> right
<superm1> ogra, for lucid would ripping the extra scripts out that aren't used at all on arm help?  Like moving the scripts that are say for UNE to a UNE casper package and those for KDE to a KDE casper package.  I'm not sure how slow individual invocations of sh are though, so that might not do too much
<ogra> no, there are more essential bits ... like locale-gen running at boottime
<JamieBennett> superm1: take a look at http://www.linuxuk.org/2010/02/ubuntu-live-cds-now-33-faster/
<JamieBennett> has some bootcharts
<ogra> given that we only run english by default and have no language selection on the image boot i'd vote for pregenerated en_GB/en_US for armel images, but that needs proper speccing and discussion, so nothing for lucid
<persia> ogra: But surely that's just because there's no gfxboot equivalent, no?
<superm1> i'd think that would be useful across the board to have pregenerated english, and if other locales are chosen at language selection to generate them
<ogra> persia, right
<ogra> superm1, ++, lets have a spec at next UDS for that :)
<cjwatson> superm1: as English speakers, I'm sure we both think that ;-)
<superm1> hehe
<JamieBennett> ogra: superm1: agreed
<cjwatson> but I always have to double-check my thinking every time that sort of thing crosses my mind
<cjwatson> and I can never actually justify it to myself
 * persia would think selecting the "top 5" locales would make more sense, perhaps following similar logic to that used to select langpacks to go on CDs, but can wait until May to be particularly interested
<ogra> well, having them there and only generate additional langs surely doesnt do any harm
<ogra> apart from costing a little space
<cjwatson> 3MB for all English locales right now; although I'm not clear on why en_AG is so big
<superm1> cjwatson, well if you try to look for the default case of what automatically times out if no selection is picked, and you try to optimize to that scenario at least.  then you make a conscious decision that deviating the default scenario increases boot time
<ogra> another issue we often have are broken board clocks that only are right after first boot  .... fallout of that is that apt gets unhappy about the gpg keys somehow
<ogra> for the pool dir on the image ...
<cjwatson> superm1: and I think that goes against our commitment to give the best service we can to localised users; it seems like sloppy thinking to me, honestly
<cjwatson> it's only justifiable if it's really a very tiny amount of space indeed, so perhaps just generating en_US.UTF-8 wouldn't be so bad
<ogra> yeah
<cjwatson> but otherwise we're crowding out other useful stuff that could go on the CD (including translations!) for the sake of making English faster
<ogra> and indeed defaulting to that if no selection exists
 * ogra would be happy with an arch specific hack for arm though
<ogra> we have lots of space atm
<cjwatson> $ du -cs /usr/lib/locale/en_US.utf8
<cjwatson> 1256    /usr/lib/locale/en_US.utf8
<cjwatson> that is not a trivial amount of space
<ari-tczew> dholbach: ping
<cjwatson> ah, the reason that en_AG showed up as so big in my earlier test was hardlinks; all the English locales come out to about that size in isolation
<dholbach> ari-tczew: I was just about to head out
<dholbach> ari-tczew: how can I help?
<ari-tczew> dholbach: got a minute for sponsoring main?
<cjwatson> basically I don't think we can justify an extra megabyte for live CD boot speed, at least not on x86.  if you want to do that on armel then that's your business. :)
<ari-tczew> I have refreshed debdiff
<dholbach> ari-tczew: is this something nobody else can do?
<ari-tczew> dholbach: heh, doubt
<dholbach> ari-tczew: best to just ask in here
<dholbach> no need to block on me
<ari-tczew> dholbach: but there are not any active sponsors for main like for universe
<dholbach> ari-tczew: I'll see what I can do about it, but I really need to head out now
<ari-tczew> ok
<persia> ari-tczew: There are some, just not many.  Just ask, and maybe someone will do it.
<ari-tczew> ok, so I'm looking for sponsoring @ bug 517297 bug 512430
<ubottu> Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/517297
<ubottu> Launchpad bug 512430 in geronimo-jta-1.0.1b-spec "Fake sync geronimo-jta-1.0.1b-spec 1.1-1 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/512430
<cjwatson> ari-tczew: looking
<cjwatson> ari-tczew: FWIW, you will get a better response if you say which things you want sponsored up-front, rather than starting with "anyone got a minute for sponsoring main" or similar
<cjwatson> since then people know how much work they're signing up for
<superm1> cjwatson, since the translations are kept within debconf for ubiquity, would that localegen stuff only be relevant for live mode, not --only mode?
<cjwatson> superm1: yes and no, I suspect that some things will still be unhappy if setlocale() fails
<cjwatson> superm1: but feel free to try it out obviously
<superm1> Ok
<cjwatson> certainly ubiquity is much less likely to have a problem; but remember that there are some failure modes in which ubiquity ends up falling through to gdm
<superm1> That should be going away moreso with you adding a vesa fallback though, wont it?
<cjwatson> not really
<cjwatson> I'm talking about if ubiquity itself fails
<superm1> but if that scenario is still a possibility, can always generate the locale "after" the fall through to gdm but before gdm gets started
<cjwatson> sure
<cjwatson> it's all soluble, just needs to not be forgotten
<LaserJock> superm1: uploaded my bcmwl dir and added a comment, thanks
<Mirv> cjwatson: I quoted some of your good points regarding usb-modeswitch in my blog http://losca.blogspot.com/
<cjwatson> Mirv: you should discuss the quirks question with the kernel team; I was under the impression that updating that sort of thing might well be feasible
<Mirv> cjwatson: ok. next I was mostly thinking about asking usb-modeswitch developers if they'd rather like a more clear way for them to contribute the information they gather to both upstream and distribution kernels.
<Mirv> but yes, discussing with kernel team about it would be a good idea in the case of Ubuntu
<cjwatson> I wouldn't be particularly surprised if the usb-modeswitch developers just plain like doing it in userspace
<cjwatson> but different people are allowed to like different things ;-)
<Mirv> might be
<slangasek> tseliot: yes, even if we were shipping plymouth in the initramfs by default, we would still support initramfsless booting w/ splash
<slangasek> superm1: it's staying with casper, though we need some bits of casper fixed to talk to plymouth
<persia> Regarding usb mode quirks: please consider when looking at any solution that a single device may have interesting reasons to do multiple things.  For instance, one may have a USB connection to a handheld and want to variously use it for storage, networking, audio, etc. over time.
<cjwatson> the quirking in the kernel that I'm talking about doesn't prevent that
<cjwatson> also, decent devices include a USB hub so that all the possible endpoints appear simultaneously
<cjwatson> this mode-switching thing is AFAIK only done by ultra-cheap devices that want to force advertising on you by mass-storage; I've genuinely never seen it anywhere else
<maco2> persia: or a wacom tablet with a pen and eraser and various other devices?
<smoser> how do i make 'bzr builddeb -S'  not include orig source tarball?
<persia> cjwatson: My smallest handheld (Sharp 922SH) needs it to switch between storage and networking.
<james_w> smoser: why don't you want one?
<persia> maco2: Another good example.
<smoser> because i already uploaded one to ppa
<smoser> and i think that if i do it again it will be rejected, no?
<persia> cjwatson: Mind you, it's still storage/networking, but when I have independent editors and browsers on the device, storage is more interesting.
<cjwatson> persia: I see.  My concern is that installing udev rules by default that futz about with the identity of the device is going to create unreliability where it did not previously exist.  I don't object to the *tool* being present, merely to the udev rules.
<cjwatson> smoser: shouldn't care, but you can use bzr bd -S -- -sd
<cjwatson> smoser: though I'm surprised that it's included by default; see dpkg-genchanges (search for -si) for the default policy
<persia> cjwatson: I completely agree that the current solution doesn't meet needs.  I haven't been able to get it to *work* with my 922SH, I just object to the idea that it only matters for the cheap 128M of ads + 3G modem devices.
<cjwatson> persia: fair enough, I wasn't aware of devices such as yours
<smoser> cjwatson, i think its because i'm misusing... i did not create a new changelog entry
<smoser> but just bumped the one
<cjwatson> though if usb-modeswitch doesn't work on your device anyway ... :-)
<cjwatson> smoser: oh, well DDTT :)
<tseliot> ok, good to know
<tseliot> slangasek: ^^
<smoser> cjwatson, well i just realized that now.
<persia> cjwatson: The current stuff needs work (and like you say, a cleaner implementation), but I think we'll see more of them as handhelds shrink.  I know that at least in the ARM space, there's lots of hardware with usb gadget ports (which users might use for all sorts of stuff).
<cjwatson> persia: I don't think our goals are incompatible; I merely want the mode switching to live in the kernel and be done at device initialisation time, rather than having to make round trips through userspace and risk things popping up and claiming the mass storage before userspace has time to switch it away.  There's no fundamental reason why the *policy* couldn't live in userspace.
<cjwatson> This is not a theoretical concern; attempting to use my device with userspace mode switching tools of various stripes simply didn't work due to such race conditions.
<persia> cjwatson: That makes perfect sense, actually.
<cjwatson> Unfortunately I don't think the mode switching is in any particularly generic form right now
<persia> So what would need doing is teaching the kernel that some devices can handle multiple modes, and having the kernel ask some userspace policy agent which mode to use when initialising the device?
<cjwatson> persia: ideally I think I'd like it to be possible to tell the kernel *in advance*, but I don't know how feasible that is
 * cjwatson has no intention of actually working on this, so ...
<crypt-0> hi cjwatson
<cjwatson> hello
<persia> In advance?  That sounds like it either requires the kernel to load some *huge* data store, or not know what to do with heaps of devices.
<persia> (2^^64 is big)
<crypt-0> anyone have info why the cryptsetup package inst upgraded to the 1.1.0?
<cjwatson> no reason it couldn't have sane defaults
<crypt-0> its still using a release candidate for Lucid
<crypt-0> the final has been released at http://code.google.com/p/cryptsetup/
<cjwatson> no idea, don't know why you're asking me
<cjwatson> Debian doesn't have it yet, and we normally wait for that, though
<crypt-0> its strange that they would keep a release candidate in there for over a month
<cjwatson> there has to be a good reason to upgrade beyond Debian
<cjwatson> "it's a release candidate" isn't a good reason
<crypt-0> cjwatson, its *probably* safe to assume that it will get upgraded to the stable release before the release of Lucid right?
<cjwatson> no
<crypt-0> hmm
<cjwatson> we're beyond Debian import freeze and nearly at feature freeze; like I say, there has to be a good reason
<crypt-0> a lot of bugfixes?
<cjwatson> normally, somebody would take responsibility for it and be specific
<crypt-0> in crypto software, especially a package that does the FDE for Ubuntu i would expect to be a stable build.
<cjwatson> if there's a good reason, great; but you just turned up and asked why the version hadn't been bumped :)
<cjwatson> in isolation, that doesn't cut it
<cjwatson> anyway, it's not a package I normally work on, so
<crypt-0> right
<cjwatson> any reason you started on IRC, rather than by filing a bug?  that's usually the best first step
<cjwatson> ah, maybe you did, bug 502699?
<ubottu> Launchpad bug 502699 in cryptsetup "cryptsetup is out of date in lucid" [Undecided,New] https://launchpad.net/bugs/502699
<crypt-0> i thought it would be non-trivial to do, and solve bugs because they are apparently deciding to go with 1.1.0, i dont know why the dont use the final stable build
<crypt-0> yes i did :)
<cjwatson> err, you know, we have tens of thousands of packages.  we don't necessarily apply a decision process to every single one.  normally we base off whatever's in Debian
<cjwatson> it's important to understand this
<crypt-0> is there a mailing list where i could participate in discussions? right but i think cryptsetup should be stable, because its not just some app you play tetris with. And it is one of the core pacakges.
<cjwatson> anyway, I'll target this bug to lucid, since it seems like a good idea
<cjwatson> did you google for Ubuntu mailing lists before asking that question? :-)
<crypt-0> thanks
<crypt-0> well yes, i think i spotted the right one, but i dont want to troll it like i am here :p
<cjwatson> oh, you think it's ok to troll here?
<crypt-0> i would also like th test the XTS mode
<cjwatson> that's surprising
<cjwatson> acceptable use of #ubuntu-devel and ubuntu-devel@lists are pretty similar really
<crypt-0> im not tying to troll , im joking
<cjwatson> ok
<crypt-0> but thanks for the help cjwatson
<cjwatson> the best way to get it upgraded in Ubuntu would be to get it upgraded in Debian first
<cjwatson> that way we don't have to worry about .orig.tar.gz mismatches and other such tedious things
<cjwatson> I don't know why the maintainers there haven't picked it up; they may just not have noticed
<cjwatson> I can go and file a bug there asking for a new version
<crypt-0> right, but i think they will before April, nonetheless the sooner the better, it would be good to have it tested now then 3 days before a release.
<cjwatson> actually that doesn't seem necessary, apparently an upgrade is in progress: http://svn.debian.org/wsvn/pkg-cryptsetup/cryptsetup/trunk/debian/changelog
<crypt-0> ahh cool :)
<crypt-0> well i gotta get going to class
<cjwatson> so I assume Jonas is either testing it, or busy
<crypt-0> i can help test it, ive been running rc1 since it was out, and upgrading with each release from google code
<cjwatson> most maintainers like to take at least some responsibility themselves :)
<crypt-0> static compile failed on amd64 with rc2
<crypt-0> was fixed in rc3+
<crypt-0> anyway class/work
 * crypt-0 vanishes
<crypt-0> thx again for your time cjwatson.
<qense> Do we build gnome-settings-daemon with PackageKit enabled? I have a bug report(bug #516384) of someone who's getting the warning: "Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory"
<ubottu> Launchpad bug 516384 in nautilus "desktop theme inside nautilus is corrupted" [Low,Incomplete] https://launchpad.net/bugs/516384
<seb128> qense, I doubt it
<seb128> qense, the bug is probably a packagegit one though
<qense> seb128: wouldn't that be weird considering the fact that Ubuntu doesn't use PackageKit?
<seb128> qense, ubuntu doesn't but some users do
<seb128> qense, this warning is not there in the default installation it must come from some installed component
<seb128> qense, google first hint is bug #389766
<ubottu> Launchpad bug 389766 in packagekit "Gtk-Message **: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory at" [Undecided,Confirmed] https://launchpad.net/bugs/389766
<qense> seb128: that makes sense, I'll look into the bug you named. Thank you for your help!
<kirkland> jcastro: where's the new patches page?
<jcastro> kirkland, they ended up having to land some db changes so it didn't make edge
<jcastro> kirkland, 1 march is what they're telling me
<jcastro> :-/
<kirkland> jcastro: what's the best way for me and an upstream to look at the patches Ubuntu is carrying?
<jcastro> how have you done it in the past?
<kirkland> jcastro: i use apt-get source
<kirkland> jcastro: upstream is not debian/ubuntu, doesn't have apt-get
<jcastro> yeah that's probably the most straightforward.
<jcastro> I know, that's why we started making +patches
<jcastro> perhaps throwing the patches on people.u.c prior to review for him?
<Caesar> slangasek: can I have your opinion on bug #520715 ?
<ubottu> Launchpad bug 520715 in ruby1.8 "building ruby1.8 with pthread support causes puppet hangs" [Undecided,Triaged] https://launchpad.net/bugs/520715
<Caesar> mathiaz might also care about it, depending on how widespread the problem ends up being
<slangasek> Caesar: I would certainly prioritize the ruby-using applications in main over the ruby extension in universe that this will break
<slangasek> if lucas can find a solution to the bug when pthreads are used, great, but otherwise puppet should be the priority
<lucas> slangasek: that's a joke?
<slangasek> lucas: why would you think it is?
<lucas> there has been *no* checking at all of other ruby libraries
<lucas> what if ruby on rails breaks?
<directhex> i wonder if ironruby-on-rails will be working in time for lucid...
<cjwatson> there's some precedent in other languages, grotty though it is, of building two versions of the interpreter when there's no way to make everything work at once
<Caesar> slangasek: thanks for your input
<Caesar> cjwatson: it's not even known if it's going to be a problem
<cjwatson> my comment is based on the assumption that it may, which I think is not hopelessly ill-founded
<slangasek> lucas: rails is also not in main.  I would obviously prefer to have the package working for all applications, but supported apps in main take precedence
<jp--> hi guys
<jp--> what's the best way to upgrade glib-c from 8.04 to the one that's on 9.10?
<cjwatson> upgrade your distribution to 9.10; upgrading glibc alone is one of the riskier things you can do to a stable release, and certainly obviates many of the points of running a stable release
<jp--> cjwatson, I'm working on a special device, I've invested a lot of time to get it working with 8.04, I can't just upgrade it to 9.10, I've made a lot of customizations to 8.04 to make the device work well with it
<jp--> there might be a way, I guess
<jp--> anyways, thanks!
<cjwatson> jp--: it is technically possible to just dpkg -i the libc6 package (and whatever else it complains about when you try that), but I expect that things would break
<Caesar> spectacularly
<cjwatson> jp--: I would certainly spend quite a bit of time investigating workarounds before doing that
<slangasek> there tends to be an unfortunate degree of coupling between glibc and the kernel, yes
<slangasek> ("unfortunate" from the POV of people trying to do this, anyway)
<jp--> thanks cjwatson :)
<lucas> slangasek: I don't think that's an acceptable solution. you might break ruby by changing a parameter deep inside the interpreter, and then explain "oh, we broke ruby? sorry, but puppet is the only thing that matters."
<cjwatson> rails depends: libsqlite3-ruby depends: libsqlite3-ruby1.8 depends: libsqlite3-0, and libsqlite is linked to pthreads, so there is a possible source of breakage there
<slangasek> I'm hoping that libsqlite doesn't /spawn/ threads, though
<Caesar> The "might" needs to come out of this argument
<Caesar> lucas: How do we satisfy you that we haven't broken Ruby by disabling pthreads?
<cjwatson> Caesar: I don't think anyone is arguing against doing substantially more testing
<lucas> Caesar: you are proposing the change. I'm proposing to be conservative. you should prove that it still works.
<Caesar> lucas: I'm asking what proof will satisfy you that it does
<jbebel> We'd need a list of requirements for proving that it works to do that.
<lucas> Caesar: the problem is, really, you can't, because it's so deep in the interpreter that you might not notice the consequences
<Caesar> lucas: that's not conservative, that's head in the sand
<cjwatson> personally, I like the option of finding the relevant change between the --enable-threads version that used to work, and the --enable-threads version that now doesn't
<Caesar> cjwatson: that's been done
<jbebel> I found it.
<cjwatson> I didn't see it in the bug report
<jbebel> It's in the ruby bug I filed.
<cjwatson> ah yes
<jbebel> http://redmine.ruby-lang.org/issues/show/2739
<jbebel> But it's too deep into other changes to just roll that back.
<lucas> cjwatson: /usr/lib/ruby/1.8/x86_64-linux/gnome2.so is linked with libpthread as well
<slangasek> lucas: that's a) not a standard Ubuntu can reasonably accept as a blocker for a fix that might be needed for puppet, b) inconsistent with the fact that upstream provides this as a configure option
<cjwatson> so I think lucas is entirely within his rights to suggest that that should be the focus of investigations
<cjwatson> I'm going on memories of similar issues in perl
<cjwatson> which went through a very similar kind of thing where people flipped pthreads to try to fix individual issues before realising that it wasn't a tenable approach
<Caesar> It'd be lovely if we could come up with a self-contained test case
<cjwatson> the upstream bug was filed one (1) day ago, so I'm not sure I see that we should be panicking over it right away
<jbebel> The problem "appears" to be fixed in the rub 1_8 svn branch, but that has other syntax changes that break things.  I'm hoping ruby can merge some change from the 1_8 branch into the 1_8_7 branch which fixes it.
<Caesar> We've removed the blocking issue by forking Ruby internally
<lucas> slangasek: the ruby threading code is black magic. we have been running with --enable-pthreads since at least dapper. flipping that now in the standard ruby package is too risky.
<Caesar> So, no, there's no cause for panic
<lucas> slangasek: a solution could be to add a ruby-just-for-puppet package
<jbebel> -and-also-if-you-experience-problems-with-threading-which-has-been-shown-to-be-unreliable-in-ruby-1-8-7
<lucas> only with puppet so far
<Caesar> Only with Puppet with a particular configuration on particular hardware
<Caesar> It's awesome
<jbebel> And without pthreads has been shown to be unreliable with nothing except tcltk.
<jbebel> which is unused.
<cjwatson> slangasek: libsqlite3 uses pthread_create in code paths which are not obviously-to-me unused
<slangasek> jbebel: which is not equivalent to showing that it's reliable with other things...?
<slangasek> cjwatson: twitch
<jbebel> agreed.
<lucas> jbebel: you haven't tried with anything besides tcltk :-)
<jbebel> I dont' know how.  I just expect that others would be more interested in evidence that ruby has a regression in the version going into Lucid.
<cjwatson> jbebel: honestly, I don't think it makes sense to explore this contentious option until we've explored the ruby bug you linked to
<Caesar> It would help if we could reliably reproduce the problem
<cjwatson> we have at least one known fallback which is less risky than flipping the configure option
<Caesar> True, if you're okay with reverting to an older version of Ruby
<cjwatson> hmm?
<cjwatson> that wasn't what I said at all
<lucas> jbebel: you have amd64 packages without pthread somewhere?
<Caesar> I figured that was the fallback that was less risky
<cjwatson> no
<cjwatson> what I meant was a separate ruby build
<Caesar> Oh, right, sorry
<jbebel> I do, internally here.  I can put them up somewhere.
<lucas> jbebel: that would be nice
<jbebel> http://moses.mybox.org/~jbebel/ruby1.8/
<lucas> thanks, but not installable on Debian. anyway, will rebuild them using your patch
<jbebel> Sorry.  I built them under Lucid.
<lucas> yup, different libc version
<jbebel> The source with my patch included is also on that page.
<lucas> rbbr (user of ruby-gnome2) crashes on startup with the --disable-pthread version
<lucas> I haven't tried to rebuild ruby-gnome2 against the non-pthread version, it might help
<Nikratio> I'm trying to create a branch with a patch for Bug #457702, but I can't quite figure it out. The BzrContributorHowto says to execute "bzr push bzr+ssh://nikratio@bazaar.launchpad.net/~nikratio/ltsp/ubuntu.bug457702", but I just get an error "Working tree has uncommitted changes".
<ubottu> Launchpad bug 457702 in ltsp "nbd+squashfs errors when rebooting ltsp thin clients" [Undecided,Confirmed] https://launchpad.net/bugs/457702
<Nikratio> What do I need to do?
<geser> Nikratio: did you "bzr commit" your changes to your local branch before you tried pushing?
<Nikratio> No. I guess I'm used to SVN, where that would be bound to fail.
<Nikratio> So I just execute bzr commit?
<cjwatson> yes
<Nikratio> Hmm: Permission denied (publickey).
<Nikratio> bzr: ERROR: Connection closed:
<geser> cjwatson: any chance you might have time to review bug 509900 before FF?
<ubottu> Launchpad bug 509900 in vim "Merge vim 2:7.2.330-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/509900
<geser> Nikratio: did you do a "bzr branch" to get a local branch?
<cjwatson> Nikratio: on commit?
<cjwatson> Nikratio: you did a bzr checkout, DDTT, use bzr branch for commit
<cjwatson> Nikratio: to repair without having to branch it all again, run 'bzr unbind'
<Nikratio> cjwatson: no, the commit worked. The push falied.
<cjwatson> ok
<cjwatson> where are you pushing to?
<Nikratio> I'm executing  "bzr push bzr+ssh://nikratio@bazaar.launchpad.net/~nikratio/ltsp/ubuntu.bug457702"
<cjwatson> geser: not before FF (I'm on holiday next week), but OTOH I don't think this is subject to feature freeze
<geser> cjwatson: ok, will you do it after your holiday or should I try to find someone else?
<cjwatson> geser: latter might be better but otherwise I'll do it when I get back
<Nikratio> cjwatson: so far I have done: 1. bzr get, 2. made the changes, 3. bzr commit, 4. bzr push (failed)
<geser> Nikratio: have you a SSH key configured on your LP account?
<cjwatson> Nikratio: do you use an ssh-agent, and if so does it know about your key?
<cjwatson> geser: yes he does, https://launchpad.net/~nikratio
<Nikratio> I'm not using an ssh agent
<cjwatson> that might be the easiest fix
<geser> without an ssh agent should ssh ask about the passphrase?
<bdrung> hi, can a core-dev trigger a second try to build libmx4j-java ( https://launchpad.net/ubuntu/+source/libmx4j-java/3.0.2-8 ). javahelper is now in main and it should build now.
<cjwatson> geser: yes, though I can't remember whether it does when used via bzr
<cjwatson> Nikratio: do you have multiple ssh keys, or just one?
<Nikratio> geser, cjwatson: the ssh key on launchpad was obsolete. I updated it and now the push worked. What do I need to do next? Just add the branch URL as a bug comment?
<cjwatson> bdrung: kicked
<bdrung> cjwatson: thanks
<cjwatson> Nikratio: there are several possibilities, but that's one of them, yes
<sistpoty> ah, that explains why I get "cannot retry this build" ;)
<geser> Nikratio: for the future: https://wiki.ubuntu.com/DistributedDevelopment/Documentation is also a nice documentation on how to work with bzr on packages
<cjwatson> Nikratio: I edited BzrContributorHowto to point out that you have to commit before pushing; thanks
<Nikratio> geser, cjwatson: Will look over the link. Thanks for your help.
#ubuntu-devel 2010-02-13
<jp--> guys... how can I find out the name that will get the filesystem partition of a usb flash drive? I've tried using sda1, sdb1, sdc1... but can't get it to boot using exec, after a dist-upgrade--- btw, it didn't upgrade the kernel :/
<jp--> it's the same one that was on 8.04
<jp--> I did a dist-upgrade from 8.04 to 9.04
<jp--> do I have to change the /boot/grub/device.map file?
<sistpoty> jp--: probably a question more suitable for #ubuntu?
<jp--> (hd0) /dev/sdc
<jp--> it said that, I changed to (hd0) /dev/sdb, which was originally working on 8.04
<jp--> ok sistpoty
<jp--> anyways.
<jp--> arg, didn't work, still showing "Begin: Waiting for root file system
<cjohnston> Anyone know if evolution 2.30 will be included on lucid?
<ari-tczew> cjohnston: why not?
<cjohnston> why not what.. why would it not?
<directhex> it won't
<Amaranth> cjohnston: no, it's close to a rewrite
<directhex> too many changes apparently
<cjohnston> so 10.10 probably?
<chicagonpg> oreily school
<LaserJock> does anybody know off-hand how the gnome panel is controlled in UNE?
<LaserJock> so it looks to me like ubuntu-netbook-default-settings is locking people out from adding/changing applets
<LaserJock> that doesn't seem quite right does it?
<genii> Do the daily builds support zsync?
<lucas> are automatic debian imports from squeeze still being done? or was that disabled?
<dupondje> lucas: how you mean
<lucas> dupondje: the release schedule says we are past debian import freeze, but I don't remember reading that it was actually disabled.
<dupondje> don't know if its really disabled :)
<maxb> Given that "automatic" is actually just "archive admins run it manually semi-regularly", I think it's safe to assume it's disabled
<geser> jelmer: Hi, do you know an easy solution to make bzr-gtk installable again in lucid again (lucid has bzr 2.1.0~rc2)?
<ari-tczew> please sponsor fake sync bug 521337 thanks
<ubottu> Launchpad bug 521337 in pyclamd "Fake sync python-pyclamd 0.1.1-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/521337
<bigon> could some one have a look at that merge request? https://bugs.edge.launchpad.net/ubuntu/+source/papyon/+bug/520699
<ubottu> Ubuntu bug 520699 in papyon "Please merge papyon (0.4.4-1) from debian testing" [Wishlist,New]
<ari-tczew> bigon: have you asked d.filoni about merging new version?
<bigon> ari-tczew: not sure on which channel he is
<ari-tczew> his nick is dfiloni and current propably he is offline, you can sent mail to him
<ari-tczew> bigon: if he is not interested in merging new version, I'll take this
<ari-tczew> just notify me on IRC, or if I'm offline please send me a mail
<bigon> ok
<bigon> thx
<cjwatson> genii: zsync> they're supposed to
<cjwatson> pitti: did a work items tracker update fail?  lucid.db != lucid.db.20100213
<cjwatson> pitti: hmm, or rather they're the same but different timestamps, seems odd that it hasn't updated since 2010-02-12 20:17 - how often are the updates?
<jdstrand> slangasek, james_w, Riddell, cjwatson, kirkland, StevenK: I am processing NEW now, since I wasn't able to get to it yesterday
<ari-tczew> cjwatson: could you merge clock-setup with latest release from Debian?
<cjwatson> ari-tczew: for the epoch fix?  sure
<ari-tczew> would be nice
<cjwatson> ari-tczew: done, and adjusted ubiquity to cope
<ari-tczew> cjwatson: thanks!
<james_w> cjwatson: dpkg imported and new bzr-builddeb in lucid that you may want to use. Sorry for the delay.
<rohit01> I am Rohit from India. I want to do some development work in ubuntu with python as a programming language. I need a mentor to guide me.
<directhex> rohit01, this channel is for development *of* ubuntu, not *with*
<persia> We clearly need a channel for development *with* Ubuntu.
<Tm_T> persia: feel free to create one (:
 * persia instead hunts for someone who might have an interest in regularly attending such a channel
<cjwatson> james_w: yay!  thanks
<Hexxeh> Hi
<Hexxeh> Is it appropriate to ask a question about how Wubi works here?
<Rawxor>  So i just installed Ubuntu Karmic (9.10) on a little mini PC (Acer Revo) - sound seems to work fine - except for in flash movies in firefox... i've read a ton of stuff that says to remove pulseaudio, but i'd rather it work _WITH_ PulseAudio - Any ideas?
<Hexxeh> Rawxor: #ubuntu
<Rawxor> Hexxeh: That channel is utterly useless
<Hexxeh> It's the support channel, this channel is for development.
<Rawxor> Hexxeh: there are far too many people coiming in and out of it constantly to be useful
<Hexxeh> Regardless, this channel is not for support, read the topic.
<Rawxor> Hexxeh: so lets develop a solution to my problem :)
<kklimonda> Rawxor, then use ubuntuforums.org
<Rawxor> :( off to the forums again
<sistpoty> cjwatson: quick question about p-a-s: I want to add more arches to libunwind (see bug #519996), is it sufficient to commit/push to lp:packages-arch-specific and then do a non-change rebuild for libunwind? anything else I need to pay attention to?
<ubottu> Launchpad bug 519996 in google-perftools "Sync google-perftools 1.5-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/519996
<sistpoty> cjwatson: nevermind, libunwind FTBFS on i386/amd64 so it needs to fixed there first anyways :/
<jp--> hi guys... how can I cleanly umount the root ext2 partition on my system when I shut it down so I avoid fsck to reboot my system when fixing nodes of the ext2 partition on every startup? thanks!
<lifeless> the normal shutdown should do that; you might consider a FS newer than 1990 as well ;)
<IDWMaster> Why can't DEB packages be uploaded in binary format to Launchpad, and compiled locally? I sometimes send in packages and they don't always build properly in a virtual environment.
<IDWMaster>  Why can't DEB packages be uploaded in binary format to Launchpad, and compiled locally? I sometimes send in packages and they don't always build properly in a virtual environment.
<ion> Does it echo in here?
<ion> Thereâs something wrong with the package if it fails to build from source.
<ion> generally
<IDWMaster> I just resent the same package and it built the second time.
<IDWMaster> Maybe some error in transmission?
<IDWMaster> I was sending in a P2P chat/file sharing application.
<IDWMaster> It builds most of the time, but sometimes it just doesn't work right.
<cjwatson> sistpoty: it's fine to push, although I think it may take a while for the LP buildds to update.  However the Debian buildd maintainers have specifically asked that we file bugs on the buildd.debian.org pseudopackage in Debian if we make changes there
<sistpoty> cjwatson: thanks. I guess the change is already in debian, let me dig it up
<sistpoty> cjwatson: ah, no it isn't. but as I wrote, it doesn't build for i386/amd64, so I'll try to get it fixed in unstable first before acting on p-a-s there
<cjwatson> sistpoty: *nod*, thanks
<sistpoty> thanks for the info! :)
#ubuntu-devel 2010-02-14
<jp--> hi guys. can I compile/downgrade the kernel using apt-get install linux-source and then copying to /usr/src a copy downloaded from kernel.org and then compile it and make deb packages?
 * persia idly wonders if make-kpkg works properly for Ubuntu
<billy12> Im sorry to bother ya'll, but dose any know what the BIN file name for "Hardware Drives" is in 9.10?
<czajkowski>  /c
<cjwatson> jp--: why would you do anything at all in /usr/src? :-)  Even Linus has been telling people to stop compiling kernels in there for a good decade now ...
<jp--> cjwatson, anyway, I didn't finally compile it. Just switched to a better version of ubuntu :) thanks for replying though!
<cjwatson> jp--: to answer your question, the upstream kernel has 'make deb' targets I believe, but of course on your head be it - you'll have to be careful about the config.  I would start from 'apt-get source linux' rather than 'sudo apt-get install linux-source', if I hadn't delegated all my personal kernel-building to my distribution years ago :-)
<jp--> :) hehe thanks
<sebner> cjwatson: thanks for merging dpkg!
<jp--> cjwatson, I need your help, if you can.
<jp--> I play this using sudo: sudo aplay /usr/share/sounds/alsa/Front_Center.wav
<jp--> but when I try to do it on a normal user, it says: audio open error: No such device
<jp--> any ideas?
<jp--> ouch. user groups.
<ari-tczew> hello ubuntu-main-sponsors, please sponsor fake sync @ bug 511448 thanks
<ubottu> Launchpad bug 511448 in libxml-security-java "Fake sync libxml-security-java 1.4.3-2 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/511448
<bdrung> pitti: i have some questions how the batch sync works (and how we can implement the XfakesyncY)
<kees> alright, who broke apache
<kees> zul: mysql-cluster-7.0 breaks libmysqlclient-dev
<kees> mysql-dfsg-5.1 and mysql-cluster-7.0 provide libmysqlclient16 libmysqlclient16-dev but the latter is version 7, which breaks mysql-dfsg-5.1's libmysqlclient-dev
<geser> and the problem is only visible on AMD64 currently as the i386 build of mysql-cluster-7.0 FTBFS
<kees> geser: ah, good call, I was wondering why I'd only seen the amd64 failure emails
<kees> I've opened bug 521815
<ubottu> Launchpad bug 521815 in mysql-cluster-7.0 "breaks all builds requiring libmysqlclient-dev" [Critical,New] https://launchpad.net/bugs/521815
<dupondje> asac: <window id="main-window" when starting firefox since last update ...
<asac> dupondje: new lang packs?
<asac> ArneGoetje: ^^
<asac> dupondje: what locale are you running?
<dupondje> dutch (nl-BE)
<asac> maybe hop into #ubuntu-mozillateam
<dupondje> running it with LANG=C firefox it works
<asac> dupondje: what locale are you using?
<dupondje> dutch (nl-BE)
<asac> ok ... i am updating now ... let me see if its also for -de
<asac> takes a bit. stay tuned
<dupondje> pitti: you there ?
 * persia suspects not, given the hour and day of week
<dupondje> seems like language-pack-nl(-base) is broken :(
<persia> Ugh.
<dupondje> language-pack-nl seems to provide a broken mozilla language file
<persia> Best bet is to file a bug.
<dupondje> it overwrites the mozilla language file of language-pack-nl-base
<dupondje> i'll do :)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/language-pack-nl/+bug/521876
<ubottu> Ubuntu bug 521876 in language-pack-nl "mozilla languages seems to get broken by last language-pack-nl upgrade" [Undecided,New]
<dupondje> its quite critical imo :)
<persia> Probably only "high" because it only affects nl
<persia> But definitely in need of fixing soon.
<dupondje> it affects some more languages it seems
<dupondje> mozilla doesn't run anymore because of it :)
<zul> kees: on it
<slangasek> zul: what's your idea for fixing this?
<zul> slangasek: i just removed it from mysql-cluster-7 for now
<slangasek> zul: that doesn't solve the problem in the archive, though, since it's already been accepted on amd64 and taken over the binary package
<IDWMaster> I found a workaround for the DEB upload problem I had yesterday. It is intermittent because Mono doesn't produce Debian-friendly makefiles.
<IDWMaster> I fixed it by manually editing the makefiles.
<zul> slangasek: ok then how do you suggest i fix it?
<slangasek> zul: if I had a good solution, I'd have mentioned it already (or done it) :)
<zul> slangasek: heh
<slangasek> zul: I'm inquiring whether we can get soyuz to accept downgrading the binaries in lucid on a one-off basis
<slangasek> and considering whether I should yank the broken binaries that have already been uploaded
<slangasek> in fact, I'm reasonably convinced that the latter is sane anyway
<slangasek> (it will break debootstrapping and CD builds and various package builds that are already broken, but will limit the spread of the damage)
<zul> frig...sorry about this
<kamalmostafa> I'm still having trouble with requestsync.  slangasek, you reported that this worked for you in Lucid but I get the same problem with Lucid or Karmic.   Any more advice?...
<kamalmostafa>    $  requestsync --lp -d unstable -s clxclient lucid
<kamalmostafa>    E: Did not retrieve any changelog entries. Was the package recently uploaded? (check http://packages.debian.org/changelogs/)
<slangasek> oh, this is odd; the source package says it ships libmysqlclient16-dev, but that's still at version 5.1.41-3ubuntu4 in the archive
<slangasek> kamalmostafa: DNS issue or web proxy that's preventing requestsync from downloading the changelog entries?
<slangasek> ah, because libmysqlclient16-dev is Arch: all and i386 FTBFS, heh
<kamalmostafa> slangasek: I don't use a web proxy, and I can see the updated changelog entry fine in my web browser http://packages.debian.org/changelogs/pool/main/c/clxclient/current/changelog so I don't think it could be a DNS issue.   I had wondered if perhaps requestsync itself was somehow caching it, but I get the same problem in a fresh VM of Lucid alpha2 where it couldn't possibly be cached.   I'm bewildered.  Perhaps I should file jus
<slangasek> kamalmostafa: you cut off at "should file jus"
<kamalmostafa> Perhaps I should file just file a bug?
<slangasek> but I really don't know what's causing the problem for you, sorry.  The next step would probably be to trace requestsync and see what it's doing
<slangasek> yes, filing a bug probably makes sense
<lifeless> kamalmostafa: uhm
<lifeless> kamalmostafa: I'd have a look at tcpdump / wireshark and see what actual request/response is going over the wire
<lifeless> that may well help you determine whether its environmental (and not something a software change will help) or a bug
<kamalmostafa> slangasek: I'm no python-guru, but I'd be happy to add whatever the equivalent of /bin/sh's "set -x" to the top of requestsync, to collect more info for the bugreport.
<kamalmostafa> lifeless: slangasek can't reproduce the problem, so I do think its likely to be something different about my env -- hence hoping to sort it out locally before filing a bug -- thanks for the advice, I'll see what I can determine.
<slangasek> zul: best idea I've come up with so far, which doesn't involve hard-resetting the package version number in soyuz, is to have mysql-dfsg-5.1 manually build the libmysqlclient16 package with a version number of 7.0.9-really-$curver
<slangasek> zul: that can be scripted in the build, and the delta cleans itself up in the future when libmysqlclient16 really does advance past version 7.09
<slangasek> the only caveat is that, if libmysqlclient16 7.0.x adds new symbols, the shlibs need to have a minimum version strictly greater than 7.0.9-really-5.*
<zul> slangasek: k looking
<slangasek> if you get something together that you think does the job, I'm happy to review it before upload
<zul> k
<zul> slangasek: so you are just changing the package name arent you?
<slangasek> no, the version number
<slangasek> dpkg-gencontrol can take an option to force override the version number of the binary package
<slangasek> (which can be passed via dh_gencontrol, if that's how you invoke dpkg-gencontrol)
<kees> zul: we should try to fix this in soyuz if we can; I'd like to avoid a XreallyY in binary packages if at all possible.
<zul> either or
<slangasek> right - I think it's good to have the package ready to go in case we decide that's the solution, but please don't upload it until we've exhausted other possibilities w/ soyuz
<geser> kamalmostafa: have you checked if the changelog on PTS for that package is uptodate?
<slangasek> geser: running the same command here, I don't get this error
<kamalmostafa> geser: Yes, it does appear up to date (includes 3.6.1-1.1):  http://packages.debian.org/changelogs/pool/main/c/clxclient/current/changelog
<geser> ok, as that caused some trouble in the past days as the changelogs didn't get updated
<zul> slangasek: couldnt we use makeshlibs as well?
<kamalmostafa> slangasek, geser: bug 521904
<ubottu> Launchpad bug 521904 in ubuntu-dev-tools "requestsync fails: Did not retrieve any changelog entries" [Undecided,New] https://launchpad.net/bugs/521904
<slangasek> zul: use it for what?
<zul> slangasek: nm i was just reading the man page
<zul> slangasek: i was thinking something like this http://paste.ubuntu.com/376472/ but i have go feed my son so ill be back later thanks for you help
<geser> kamalmostafa: good news, I can reproduce it
<kamalmostafa> geser: really!  Well, that is good news!
<geser> kamalmostafa: the debian LP mirror didn't sync the new version yet, and LP still believes that 3.6.1-1 is the most recent version
<slangasek> zul: aren't there other calls to dh_gencontrol already in the rules?  I would expect 'dh_gencontrol -Nlibmysqlclient16; dh_gencontrol -plibmysqlclient16 -v$version' to be sufficient
<geser> I should make the error message more useful
<slangasek> zul: also, you shouldn't hard-code the value of the -v option in rules, it should be derived from debian/changelog (it needs to automatically increment with each package upload)
<zul> slangasek: ok ill fix when I get back
<kamalmostafa> geser: Oh, okay, so is this the same problem I keep having with "bzr branch" not yielding the latest version then?
<slangasek> zul: ok - my apologies if lvm2 wasn't using debhelper, I didn't actually look at it before pointing to it as an example (it's hard to even come up with any examples of this)
<kamalmostafa> geser: and how is it that slangasek doesn't also experience the problem?
<geser> kamalmostafa: no, as the package branches are independent of the LP mirror
<slangasek> apparently I have REQUESTSYNC_MAGIC=1 set in my environment ;)
<geser> kamalmostafa: slangasek didn't use --lp
<slangasek> yes, I did
<kamalmostafa> geser: and actually, I can reproduce the problem with or with --lp.
<slangasek> I was trying to reproduce his problem, and copied his commandline verbatim
<geser> hmm
<kamalmostafa> No, I take that back.  I can **no longer** reproduce the problem without --lp but I certainly could 5 days ago.
<geser> with --lp I can reproduce it, without --lp it works here (I've an editor open with the changelog entry)
<kamalmostafa> I remembered that --lp versus no --lp was the solution to my previous requestsync problem, so it was the first thing I tried.
<geser> I don't know when exactly the changelogs get fixed but they weren't up-to-date in the recent days
<slangasek> oh, y'know what
<slangasek> $ requestsync --lp -d unstable -s clxclient lucid
<slangasek> Changes have been made to the package in Ubuntu.
<slangasek> Please edit the report and give an explanation.
<slangasek> Not saving the report file will abort the request.
<slangasek> Press [Enter] to continue. Press [Ctrl-C] to abort now.
<slangasek> kamalmostafa's output didn't include that message, so I assumed I couldn't reproduce the bug
<slangasek> but if I hit enter, I get the error
<kamalmostafa> Ah... no REQUESTSYNC_MAGIC after all then?  ;-)  glad of that at least!
<kamalmostafa> geser: I will leave bug 521904 to you then, as a "make the error message more useful" request, yes?  Okay if I proceed with my clxclient request or will you need it left as is?
<ubottu> Launchpad bug 521904 in ubuntu-dev-tools "requestsync fails: Did not retrieve any changelog entries" [Undecided,New] https://launchpad.net/bugs/521904
<geser> kamalmostafa: I will as the soyuz guys why the LP mirror is not up-to-date for clxclient
<kamalmostafa> geser, slangasek: thanks for all the help sorting this one.
<geser> slangasek, zul: looking at the new FTBFS log for mysql-cluster-7.0: doesn't it now need to build-depend on libmysqlclient16 to let dpkg-shlibdeps succeed? (once this got resolved)
<dutchie> hi, apologies if this is the wrong place, but would it be an enormous pain to sync texlive 2009 from debian testing? It seems a bit odd to be shipping 2007 in a distro released in 2010
<lifeless> dutchie: see the ubuntu wiki for developer docs; you want https://wiki.ubuntu.com/SyncRequestProcess
<dutchie> saw that, it looks quite scary
<geser> dutchie: lucid will have TeXLive 2009
<dutchie> geser: ah, sweet
<dutchie> thanks
<lifeless> dutchie: that is however the thing to check; irc is the wrong place ;)
<dutchie> lifeless: notice I didn't ask "Please sync it", I asked "Would it be a pain to sync it"
<dutchie> if someone had come out and said "no, and here are reasons x, y and z", I would have said "Oh, OK, I won't bother going through the process"
<dutchie> if nothing had happened, I would have gone ahead and done it
<dutchie> but, as it is, I don't have to care
<lifeless> sorry for misjudging the request
<dutchie> I probably didn't quite make it clear enough
<lifeless> we get a fair number of 'please do x' from folk that haven't looked at all
<dutchie> I'm sure you do
#ubuntu-devel 2011-02-07
<achiang> i've an odd question -- if someone else makes a *.changes/*.dsc and signs it, can i re-sign it to make an upload to a PPA?
<micahg> achiang: yes, but you should use something like backportpackage from u-d-t instead so it has your name in teh changelog
<achiang> micahg: hm, how will the package be versioned then, after using backportpackage?
<micahg> achiang: unless you're sponsoring the PPA upload for someone
<achiang> micahg: yes, the situation is more similar to me sponsoring the PPA upload
<micahg> achiang: so, yes, you can, just use debsign -k
<achiang> micahg: i don't really want to re-version the package, because it's a kernel package, and there are ABI issues i dont' fully understand
<achiang> micahg: thanks, i'll play around with debsign -k
* Burpaps_ changed the topic of #ubuntu-devel to: I sucked God's dick and fingerblasted Jesus Christ up his tight, smelly Ã¤nÃ¼shÃ¶lÃ«, while the Holy Spirit sat in the corner, jerking off and watching.
* Burpaps_ changed the topic of #ubuntu-devel to: j/k
<lifeless> bah, anyone have the previous topic
<Burpaps_> so how are you today
<lifeless> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<Burpaps_> !ops
<lifeless> mneptok: around?
<lamefun> will the invisible window resize border backported to 10.10?
* Pici 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:
<lamefun> was the channel hacked?
<Pici> no
<Pici> Its set -t, anyone can change the topic.
* lamefun changed the topic of #ubuntu-devel to: Really? | 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:
* lamefun 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:
<lamefun> O_o
<Pici> yes, really.
<lamefun> O_o why?
<RAOF> lamefun: Unlikely, I think.  It's not an SRU candidate, and it requries gtk changes IIRC, which makes it unlikely to be put into -backports.
<lamefun> btw will there be a GUI control to control size of invisible resize border?
<RAOF> I wouldn't expect so.
<StevenK> RAOF: O hai?
<RAOF> StevenK: Hai o?
<StevenK> RAOF: Can I instruct Do to forget what I want for a particular key?
<StevenK> (So I can retrain it)
<RAOF> No.  You can get it to forget everything (by deleting the history file), but not specifics.
<RAOF> what's your use-case?
<RAOF> (ie: convince me to implement it, or to fix your problem in a better way âº)
<StevenK> RAOF: If I query the weighting, I can do it manually
<StevenK> Er, If I can query
<StevenK> RAOF: But I can explain the whole story if you like
<RAOF> Yeah, that'd be good.
<StevenK> RAOF: I use the Rhytmbox plugin to control it -- means I can summon Do, hit n, e for Next and skip to the next song easily. I also do the same thing for Pause.
<RAOF> Ok.
<StevenK> RAOF: Play is where I have a wierd issue. It would always put an album of mine in the queue whenever I used Do to instruct Rhythmbox to Play. Turns out the top result for "Play" is "Play an item in Rhythmbox", which always picks this album. The second result is "Play music in Rythmbox", which is the more generic play
<StevenK> So, I'd like to tell Do to default to the second result for "Play"
<RAOF> Ok.  Well, you can kinda work around this by just exectuting the âplayâ that you want over and over.  HittingÂ <shift>+<enter> when it's selected will execute it without dismissing Do, so you could just do that over and over again for a while :)
 * RAOF now has an *awful* lot of terminals on his desktop :)
<StevenK> Haha
<StevenK> RAOF: The shift-enter trick has done it, thanks!
<RAOF> Feel like uploading some X input drivers very few people use, then?
<RAOF> http://cooperteam.net/Packages has a fine selection to choose from :)
<StevenK> Can't I just buy you a beer, like non-core-dev's have to do? :-P
<RAOF> Well, you could do that :)
<micahg> RAOF: are those all in main?
<RAOF> micahg: No, I think they're all in universe.
<micahg> RAOF: ok, I can try to do a few if you like
<RAOF> Yup, all universe, as befits input drivers that noone uses.
<RAOF> micahg: Ta.
<StevenK> RAOF: Or, 'out of the archive'
<StevenK> ?
<RAOF> StevenK: Well, they *are* maintained upstream, and there does exist hardware that uses them.
<RAOF> You can expect a couple of archive removal bugs from the X team shortly, though; some of the drivers *aren't* maintained upstream.
<RAOF> Time to restart so that unity doesn't keep killing my terminals!
<RAOF> Gah.  Unity, stop eating the 320 left-most pixels of my screen with an invisible window.
<lifeless> its a mesage
<lifeless> you need a wider screen
<RAOF> My display is 2720 pixels wide!
<lifeless> see, 2400 is just wrong.
<RAOF> How is there not already a bug for this?
<micahg> RAOF: the A's are done
<micahg> RAOF: I've almost got the rest of them ready
<RAOF> Awesomesauce.
 * RAOF regrets accidentally letting his MOTU powers lapse.
<StevenK> RAOF: When is the meeting for your core-dev application?
<micahg> RAOF: when you get core-dev, you can return the favor ;)
<RAOF> micahg: Certainly.
<RAOF> StevenK: I should get on to that part of the organisation :)
<StevenK> Haha
<micahg> RAOF: I noticed some have the merge from experimental and some don't, is that an issue?
<RAOF> micahg: No.  The ones which don't have a merge from Debian are the ones where we don't (yet) want to merge from Debian.
<micahg> RAOF: ok, np, about to upload
<RAOF> micahg: Debian's added a shiny new dh series which we don't yet have in our xserver package.
 * micahg is happy their names are so different, make tab complete easier
<micahg> RAOF: all uploaded
<RAOF> Danke
<c2tarun> chrisccoulson: ping
<micahg> c2tarun: he probably won't be around for a few more hours
<c2tarun> micahg: ok, can you please look on the comments on the bug 713023.
<ubottu> Launchpad bug 713023 in bibshelf (Ubuntu) "Newer Version Available" [Wishlist,Fix released] https://launchpad.net/bugs/713023
<c2tarun> micahg: need updated build-depends I get, but what are broken po files?
<micahg> c2tarun: idk
<dholbach> good morning
<RAOF> micahg: Are you up for a little more sponsoring?  Easier this time; they're all no-change rebuilds.
<micahg> RAOF: not tonight, I can do them tomorrow night while building some VMs though
<RAOF> That's ok, thanks.  I can cast a wider net.  If I still need it tomorrow, I'll ask again :)
<evfool> mvo: are you around?
<mvo> evfool: hello, yes
<evfool> regarding bug #409532, could you please check it? especially whether the file share/apt-auth-failure.note is used or not at all? I haven't found any references to it in the apt code, but I might have missed something
<ubottu> Launchpad bug 409532 in apt (Ubuntu) "Poor wording of suggestion box message for "Apt authentication issue"" [Undecided,Fix released] https://launchpad.net/bugs/409532
<evfool> mvo^
<didrocks> good morning
<mvo> evfool: thanks, let me look at the bugreport
<pitti> Good morning
<mvo> evfool: hm, my ubuntu apt branch has share/apt-auth-failure.note
<evfool> mvo: yep, but I haven't found any references to it in the code, it doesn't seem to be used
<mvo> evfool: indeed, I will check the log, that might be a mistake
<evfool> mvo: ok, thanks
<amitk> any mutt user seeing mutt maxing out number of open processes in natty?
<mvo> amitk: I use it (and have fairly big mailboxes) but haven't seen tis problem yet
<DktrKranz> mvo: hi! gdebi uploaded to debian and sync request filed (waiting to be ACKed). I also pushed a branch with a simplified packaging at lp:~dktrkranz/gdebi/overhaul. If it's fine for you, I'm going to test it a little bit then push on trunk.
<mvo> DktrKranz: thanks, I saw the upload, great :) I look at the branch now
<amitk> mvo: Does "ls -l /proc/<pid>/fd | cut -d'>' -f2 | sort" show the same mailbox being opened several times?
<mvo> amitk: hm, I use a maildir
<amitk> mvo: yeah, I meant maildir
<mvo> amitk: the command shows almost nothing, just pts and if I open a message that (one) message
<mvo> amitk: do you use mutt or mutt-patched?
<mvo> amitk: I had some (differnt) issues with mutt-patched recently
<amitk> mvo: mutt-patches
<mvo> DktrKranz: branch looks fine, thanks for this update! I commited it right away :)
<amitk> mvo: I wonder if I'm suffering from migrating my /home across two releases. Lots of application crashes all over the place
<DktrKranz> mvo: cool, thanks. That will save us multiple uploads for python-defaults transitions
<mvo> amitk: hm, might be, I would try removing the mutt-patched for now and using the stock mutt
<mvo> amitk: that is pretty stable for me on a2 now
<bigon> Hi, could someone rebuild webkit in natty? looks like it's needed since last gtk3 api break
<bigon> s/api/abi
<cdbs> Exams over. Back to business
<pitti> cdbs: oh, congrats! successful?
<marcus> hi all. i am searching for a build of the rt8168 module for maverick. is there something available, already?
<bigon> Riddell: hi, do you think you could reintroduce gjs? the current version in debian build correctly on natty
<Riddell> bigon: sounds gnomeish, best ask someone who knows about gnomeish things
<chrisccoulson> bigon - what do we need gjs for?
<chrisccoulson> we got rid of it because nothing uses it
<bigon> chrisccoulson: well gnome-shell will use it (even if it's not in the official archive), and other project could use it too in the futur
<chrisccoulson> bigon - for gnome-shell, it's in the gnome 3 PPA (or should be)
<bigon> I know, but I thought that the policy was to put stuff that could be co-installed in the official archive
<janimo> pitti, -dbg packages from the main archive and ddebs have some overlap right?
<pitti> janimo: yes, they conflict; usually -dbg is the union of all -dbgsym
<janimo> pitti, can they be used seamlessy by nm/objump or just gdb?
<pitti> janimo: yes, just as with -dbg
<janimo> for instance finding symbols from stripped system libs using the dbgsyms packages
<pitti> both debhelper and pkg-create-dbgsym set the debug link in the ELF files
<janimo> pitti, and a dbgsym lib contains the original lib plus dbg symbols or only debug symbols?
<janimo> I tried objdumpng one and it does not show code
<pitti> janimo: only debug symbols, just like the -dbg packages
<janimo> pitti, ok, thanks
<ari-tczew> ogra: of course I ask you only for ACK, I know that syncs are done by archive admin :) there is also sync bug 713425
<ubottu> Launchpad bug 713425 in aspell (Ubuntu) "Sync aspell 0.60.6-5 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/713425
<ogra> ari-tczew, yep, saw that too
<DJKorbit> hi
<DJKorbit> can i discuss unity development here?
<ogra> DJKorbit, #ayatana might be better for that
<DJKorbit> ok, thanks
<SpamapS> hrm.. should apt-file work in natty?
<barry> SpamapS: um, yes, i use it all the time, but i installed it a long while ago
<SpamapS> seems to not have universe in it
<SpamapS> or rather
<SpamapS> universe seems to not have an index
<barry> SpamapS: how weird, is there a specific package you tried?  i can try it here
<thebishop> is anyone from the utouch team here?  i have some questions about extending multitouch support
<didrocks> thebishop: you should try #ubuntu-touch
<thebishop> didrocks, thanks
<didrocks> yw
<ari-tczew> does anybody know whether Debian wheezy will base on gcc 4,6?
<yofel> pitti: I tried to update the bash completion for apport - but with the recent changes, what exactly is the completion support to complete? only the options from --help? or all that work?
<yofel> s/support/supposed/
<pitti> yofel: hi
<pitti> yofel: --help should be precise now for ubuntu-bug, apport-collect, and apport-cli, so only those
<yofel> ok, apport-cli too? since that gives me the old help here
<pitti> yofel: yes, that's supposed to have the full suite of options
<pitti> like -f, --pid, etc.
<yofel> doesn't work though:
<yofel> $ apport-cli --package=bash
<yofel> No pending crash reports. Try --help for more information
<pitti> yofel: needs -f
<pitti> or just apport-cli bash
<yofel> aaah, ok
<ari-tczew> hmmm, I can't find cjwatson or doko
<SpamapS> @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: SpamapS
<ari-tczew> SpamapS: did cjwatson piloting today?
<SpamapS> ari-tczew: Not sure.
<SpamapS> ari-tczew: I don't see him in the logs for the last few hours.
<NCommander> is there anyone around from ubuntu-toolchain on building qt with gcc 4.4 vs 4.5 due to regressions in 4.5?
<janimo> slangasek, do you plan on using the no var tracking flag on the regulat qemu-kvm package as well?
<slangasek> janimo: wasn't planning anything wrt qemu-kvm, please check with hallyn
<janimo> slangasek, ok
<janimo> thanks
<kirkland> bryceh: hey, fyi, re: X breakages... my x201 no longer works with an external monitor (24" Samsung)
<kirkland> bryceh: just flickers red and black in a seizure-inducing manner
<RAOF> kirkland: Which kernel is that with, and does booting a previous kernel fix it?
<kirkland> RAOF: good question ...  this is 2.6.38-2-generic
<kirkland> RAOF: i can go and try an older one
<RAOF> The last 2.6.37 one might be worth a try.
<kirkland> RoAkSoAx: okay
<kirkland> RAOF: okay
<RAOF> Unless you have some other information, like the last time you remember it working?
<kirkland> RAOF: confirmed, 2.6.37 works as expected
<kirkland> RAOF: is there an existing bug I can subscribe to?
<kirkland> RAOF: or shall i file a new one?
<RAOF> kirkland: I'm not aware of one, no.
<RAOF> Feel free to file a new one.
<kirkland> RAOF: okay, i'll file a new one
<kirkland> RAOF: who should i subscribe/assign?
<RoAkSoAx> kirkland: lucky you that you have an Intel video card :P
<RAOF> It would also be helpful to see if 2.6.38-1 works; if so, that's a substantially smaller history to wade through.
<kirkland> RoAkSoAx: i don't feel so lucky these days
<RAOF> kirkland: You can subscribe JFo; that'll bring it onto the kernel team's radar.
<kirkland> RAOF: it doesn't work either
<kirkland> RAOF: k
<RoAkSoAx> kirkland: at least your driver works :) I have an nvidia... so i had trouble getting my laptop screen working again
<kirkland> RoAkSoAx: btw ... my system is powernapping, when i don't think it should
<RoAkSoAx> kirkland: how so?
<kirkland> RoAkSoAx: i dont' think the input (keyboard/mouse) monitors are detecting my activity correctly
<RoAkSoAx> kirkland: external?
<kirkland> RoAkSoAx: i'll try to get it fixed tonight
<kirkland> RoAkSoAx: no, laptop keyboard, onboard
<RoAkSoAx> kirkland: that's ConsoleMonitor only then, and PS2 Input
<RoAkSoAx> kirkland: is this with your X201 specifically, or with all HW?
<RoAkSoAx> bryceh: Any StarTech USB2VGA adapter should work out-of-the-box right?, or at least the drivers included would work for any model?
<RAOF> RoAkSoAx: You'll need (at least) an xorg.conf for those; there's no usb autoprobe anywhere in the graphics stack.  I'm not familiar with those adaptors.
<RoAkSoAx> RAOF: yeah just found some doc's about it. At least the drivers are included and should not be that hard to get it working
<kees> rickspencer3: btw, here's the gnome-keyring bug we mentioned we'd open: LP: #714908
<rickspencer3> hey kees
<kees> hi rickspencer3 :)
<rickspencer3> cool, thanks kees
<kees> np
<bryceh> RoAkSoAx, yeah just needs xorg.conf-age like RAOF mentions.  X doesn't probe the USB bus for video devices automatically (and questionable if it should...)
<RoAkSoAx> bryceh: cool! thanks! At least I know it won't be a waste of money to get one cause it will work with customization. Though, would be nice to have a wikipage with all the steps to get this working for all of us to be aware of it
#ubuntu-devel 2011-02-08
<RAOF> bryceh, RoAkSoAx: Although, now that drm's getting USB support it's quite possible that those framebuffer devices *will* get autoprobed and kms'd at some point in the not-too-distant future.
<bryceh> RoAkSoAx, I recall finding adequate directions via google when I was testing one, but if you feel motivated to setting up a wiki page somewhere linked under wiki.ubuntu.com/X/ that could help other folks
<soren> I'm actually quite surprised to learn that you can do video over USB. I didn't think there'd be sufficient bandwidth.
<RoAkSoAx> bryceh: yeah I got one from forums, but once I get the device and get it working, will provide the wikipage
<RoAkSoAx> soren: neither did I
<RoAkSoAx> soren: http://www.amazon.com/gp/product/B000WTI6CI/ref=s9_simh_gw_p23_d0_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-2&pf_rd_r=15JRYSZV13NJS5PABQ2V&pf_rd_t=101&pf_rd_p=470938631&pf_rd_i=507846
<soren> Hm... I guess you can actually to 1440x900 (what my laptop has) at 24 bit and 60 hz with just 186 Mbps.
<soren> +error correction and whatnot, of course.
<soren> 1080p is a different story, though.
<RoAkSoAx> soren: this one claims to though: http://www.amazon.com/gp/product/B002F9NSMQ/ref=s9_simh_gw_p23_d0_i2?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-3&pf_rd_r=0GHBCHAEPZ8RHD44KK38&pf_rd_t=101&pf_rd_p=470938811&pf_rd_i=507846
<soren> 10 fps, 24 bpp, 1920x1080 = 497664000 bps. USB2 is 480 Mbit/s.
<RoAkSoAx> "maximum 2048 x 1152 pixel resolution or 1080p"
<soren> Looks cool.
<soren> I'd be interested to hear how it works out.
<RoAkSoAx> indeed! I'm definitely getting te StarTech one
<SpamapS> @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:
<\sh> hmm...since when is aptitude "Priority: optional" and not "Priority: important" anymore, is there any way to track ubuntu archive overrides file?
<\sh> good morning :)
<micahg> \sh: since it's not default?
<\sh> micahg: it was in former releases marked as important...this "change" changed behaviour in one of my important admin packages ;)
<micahg> \sh: in Maverick it was no longer the default cli package manager, idk about Priority per se
<\sh> micahg: I see now, since maverick it changed the priority, therefore debootstrap never installed it anymore by default inside the chroots...hooray for \sh, to never created a maverick chroot ;)
<\sh> in lucid it was still "Priority: important"
<micahg> \sh: right
<\sh> ok...fixing package ;)
<dholbach> good morning
<didrocks> good morning
<\sh> highvoltage: happy birthday :)
<dholbach> yeah, happy birthday highvoltage
<dholbach> salut didrocks, sabdfl
<didrocks> hey dholbach
<didrocks> happy birthday highvoltage!
<sabdfl> morning dholbach, how are you? hey didrocks
<sabdfl> and happy birthday jonathan
<dholbach> sabdfl, great - thanks - how's life over there? :)
<sabdfl> well
<sabdfl> very interesting, in the spy thriller sense
<nigelb> that sounds interesting
<sabdfl> tell you all about it some time, but this is a big week for my tropical project
<dholbach> sabdfl, you're not very good at letting people let you go easily :-P
<pitti> Good morning
<\sh> moins pitti
<zyga> pitti, hi, around?
<zyga> pitti, I'd like to discuss bug #706603 for a moment
<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
<Daviey> @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: Daviey
<\sh> zyga: oh again this gem topic...every year the same ;)
<pitti> zyga: is there a new approach to this rubygems thing then?
<persia> Dunno why gems are special.  Same for eggs and jars and CPAN, really.
 * dholbach hugs Daviey
<pitti> zyga: btw, it's actually possible to add to $PATH at least for login shells by dropping a file in /etc/profile.d/
<pitti> zyga: and GUIish ones could just install .desktop files?
<\sh> persia: well, local eggs are installed in /usr/local which is really a strange behaviour in regards to gems...(dunno for jars or cpan..it's a long time ago that I installed something from CPAN with the cpan shell)
<zyga> pitti, I'd like to ask just one question
<zyga> pitti, why don't we install pip stuff in /var the same way?
<persia> \sh, Dunno.  When I was a RoR developer, everything was in /usr/local :)
<zyga> pitti, currently gems are treated "worse" than pip installs are, is there a reason for that?
<pitti> zyga: pip?
<zyga> pitti, python "gem" manager just deals with eggs
<zyga> pitti, it also installs executables
<zyga> pitti, into /usr/local
<\sh> persia: at least puppet works out of the box and that's important ;) and s/RoR/django/ ;)
<zyga> pitti, if we treat gem the same way we treat pip then, IMHO, the ruby community will not be annoyed anymore
<persia> \sh, django eggs are in /usr/local, right?
<zyga> persia, it depends on how you configure things
<persia> zyga, By default, based on the pip implementation we ship.
<zyga> persia, but if you use out-of-the-debian-package-box pip today and use sudo to install them then yes
<zyga> persia, if not they go to .local
<zyga> persia, same as gems
<persia> The non-sudo case is well documented, which makes it easy to implement :)
<zyga> persia, I'm just trying to show that python gets better treatment here and perhaps if we revert our gem stance ruby community will welcome this change
<zyga> persia, both pip and gem behave the same way in their upstream versions, we just patch gem to install to odd place when using sudo
<\sh> persia: when you install django from upstream source, they will be installed under /usr/local/lib/python*/{site,dist}-packages/ , the same goes for every python source installed manually with setup.py
<zyga> persia, note that this is not about gem --upgrade-system - this is a separate topic
<zyga> right
<zyga> I'm asking that we allow gems to behave the same
<zyga> or explain why we treat them differently
<pitti> zul: so, /usr/local/ seems okay to me, but NB that I didn't really follow the original discussion and thus don't know the arguments against it
<\sh> zyga: what about third party libs, which are deps of gems, which are also installed by ubuntu/debian dpkg system?
<zyga> \sh, what about them? IMHO there is no difference to what pip and gem do in this respect
<\sh> zyga: there was this gem (something to do with imagemagick) which wanted to not use the system lib installed, but a newer version
<persia> \sh, Hrm?  Stuff is either installed by dpkg or gem: what is this hybrid install?
<zyga> \sh, pip will install a more recent version in that case
<zyga> \sh, I'm pretty sure gem will try to do the same if the package is installable via gem
<zyga> I can dpkg install django 1.1 from lucid
<zyga> and pip install django 1.2.4 from upstream _on_ lucid
<zyga> at the same time
<pitti> /usr/local/ is pretty much meant for stuff like that, after all
<pitti> that, or /opt/
<zyga> let's just answer one question:
<\sh> zyga: honestly, I never had the opportunity to install a python lib which has a native lib
<zyga> why do we install gems to /var/lib/ ?
<persia> I don't remember the details, but it's worth looking up.
<persia> I seem to recall something along the lines of needing to create directory structures and metadata in /usr/local, which was bad somehow.
<zyga> (we should be consistent, either there is a good reason to and we need to do the same for pip and python)
<zyga> or there is no good reason anymore so we can make ruby community happy
<persia> The documentation is likely in the relevant debian bugs, or mailing list archives.
<zyga> persia, all I could find was that _in the past_ the default install location was not /usr/local but /usr
<persia> Last time I watched the discussion, I didn't have the impression the "ruby community" had a consistent view of an ideal solution.
<zyga> so they switched to /var/lib instead of /usr without looking at /usr/local
<persia> Who is "they" in this context?
<zyga> AFAIR the debian package maintainer for gems
<\sh> zyga: did you check your PYTHONPATH when you do that? the last time I had a mess with django installed by dpkg and installed under /usr/local, the same with a local install in ~/.local/lib/python* , because our default pythonpath defaults somehow to the /usr/lib/python* dir  and follows all the other directories after that (whysoever)
<zyga> \sh, I always use virtualenv when I use pip so it's not really a problem for me
<persia> zyga, And did you ask?  I suspect there was a reason for the choice.
<zyga> \sh, python path is derived from PATH
<zyga> persia, from the thread I found there was just arguments (sane) against /usr and then an announcement of a decision to use /var/lib/
<zyga> persia, I can to talk to the maintainer again but perhaps we can decide this by ourselves and win some PR points :P
<persia> I don't see how it would win PR points to announce a decision that didn't involve key stakeholders.
<persia> Moriwaki-san ought be able to provide a relatively clear answer about the selected location.
<zyga> persia, it does, the ruby community discourages anyone to use debian packages for ruby/gems and advises to install from source because our two patches break a lot of ruby world assumptions
<zyga> persia, so at least one stakeholder - end users - is considered
<\sh> zyga: http://www.lucas-nussbaum.net/blog/?p=617 <- that happend with the most active ruby maintainer in debian...it's not a happy environment
<zyga> \sh, I know about that
<persia> zyga, It's lots more complicated than you describe.
<\sh> zyga: and I don't think we should make a step into whatever direction without having debian on our side...
<zyga> \sh, that's true
<zyga> persia, how is it more complicated?
<zyga> lucas, around?
<\sh> if people want to install gems are on their own...and normally an admin knows what he does..(developers of {java,python,ruby,perl,<insert your favorite language>} apps sometimes not ;))
<\sh> insert a "there" between "gems" and "are"
<persia> I've been away for a while, but last I looked, there were multiple disjoint ruby communities, rather than just one, and the majority of interesting discussion on forward use of ruby was inaccessible to those who didn't read Japanese.
<zyga> \sh, this discussion is not about that
<\sh> s/he/he && she/
<zyga> \sh, this discussion is about the default install path of ruby gems once you actually want to use them
<persia> I'd need a lot of convincing to accept anyone claiming to speak on behalf of "the ruby community"
<zyga> \sh, and why this path is changed by debian when we are not doing equivalent changes for pip or CPAN
<persia> zyga, Who made the change?  Ask them.  They have the answer.
<zyga> persia, the change was made long time ago by the gem maintainer
<zyga> persia, I should talk to him, that's true
<\sh> zyga: it's about the ruby gem package of debian/ubuntu, which installs ruby binaries under /var/foo...and that's the discussion since ages. Ruby devs are using mostly a more recent gem version which they installed manually from upstream source and not from the debian/ubuntu package...so they have a different default somehow
<persia> By Moriwaki-san?
<zyga> persia, but this is still a _ubuntu_ bug on launchpad and I'd like to ask (pitti originally) about his thoughts on this topic
<zyga> persia, let me check that - I think it was him
<persia> If it was a long time ago, the maintainer may have changed.  It's important to check.
<persia> But I very strongly suspect the answer to why it's different than the other tools exists, either in the documentation surrounding that change, or is available by contacting the person who made the change.
<zyga> \sh, it's not about a more recent version, it's about a single patch that debian introduced - if this patch is very important and cannot be dropped then the same decision should apply to python - since it did not perhaps it's possible to revisit this decision and see what the reasons were
<persia> Indeed.  We should have consistency when installing stuff with gems, pip, cpan, maven, etc.
<persia> Mind you, we should probably deprecate the use of all of them, but that's a different issue :)
<\sh> honestly, I wonder which type of users we want to catch with something like that? Admins, Application Developers or plain users of Ubuntu who want just work?
<zyga> persia, that's a different story, we should be consistent first
<\sh> my devs here @work they are installing whatever comes into their mind, thinking that the latest version is the best they can get...without consulting their local sysadmin who needs to deploy, install and configure the machines where the app runs later.
<persia> \sh, For consistency, everyone: the key is that things shouldn't be confusing for all categories.  In terms of use/non-use of those tools, that's a different issue (and reaching "Just Works" without them is a lot of work)
<\sh> and with my admin hat on, I don't like having software on board which doesn't come from the distro vendor
<zyga> \sh, IMHO developers - when you use debian/ubuntu version of gems then all the scripts tend to break if you don't change your PATH to include that place, and you only need to do this on two systems so it's annoying
<persia> But let's avoid the discussion as to whether these tools *should* exist,and focus on what they ought do since they do exist.
<zyga> right
<zyga> okay, so I found this bug report in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480250 it's about the (very broken) behaviour of installing everything to /usr - the resolution by the maintainer was to change the path to /var/lib (the maintainer then was indeed Moriwaki-san)
<\sh> I had that discussion with our devs here, regarding mono...they came up with a more recent version of the mono suite which lucid doesn't ship..anyways, I would like to see the gems/pips/cpans/etc. all packaged for debian/ubuntu in the first place...and then devs are coming back to us with bug reports about "the version of ruby-gem-foobar is too old" or "your python-netaddr pkg is outdated, please update it for <whatever supported and stable release
<\sh> we have>
<zyga> I cannot find any bugs in _debian_ that relate to the request to set the installation path to /usr/local - there is on a launchpad bug about this
<persia> zyga, It appears it was never discussed as a bug then: it may be that it was just done because it seemed like a good idea at the time.
<zyga> persia, yes, perhaps - that was some time ago, 2008
<brendand> hey everyone
<persia> Potentially overwriting /usr/bin/foo is exceedingly dangerous.  Whether the solution is the right one deserves discussion.
<brendand> i've found something that could be a bug (could be a 'feature') involving scrollbars + touchpads
<zyga> persia, there is no doubt about no-no for installing anything in /usr - but nobody is asking for that fortunately
<\sh> persia: think about this behaviour: someone installed source A which installs to /usr/local/ and delivers /usr/local/bin/foobar-binary
<broder> pitti: what's the best thing for me to do with a potential ddebs issue? add a pkg-create-dbgsym task for it?
<\sh> now someone does gem install ruby-A which is a binding to source A and it needs a newer version of source A.
<broder> pitti: (bug 660360, specifically)
<ubottu> Launchpad bug 660360 in openafs (Ubuntu) "openafs debug information CRC mismatch" [Undecided,New] https://launchpad.net/bugs/660360
<\sh> persia: adhere: this applies to PIP/CPAN/PEAR as well
<pitti> broder: yes, and subscribe me
<brendand> basically, what happens is that in certain applications (main culprit i'm thinking of is one i wrote myself, in PyGtk) - when you put the cursor on a scrollbar it messes with the touchpad scrolling behaviour
<broder> pitti: cool, thanks
<persia> \sh, And, arguably, maven
<zyga> \sh, I'm not familiar with perl that much but I assume cpan stuff ends up in /usr/local, correct?
<zyga> pitti, hi, could you please give us some insight into 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
<brendand> so, if the cursor is on the horizontal scrollbar and you use the touchpad to do vertical scrolling, it scrolls *horizontally*
<\sh> persia: the fun part: /usr/local/ is something where admin can install locally needed software..should a third party package manager (like gem, pip, pear, maven, ant, whatever) install also to /usr/local , or should it install somewhere else
<persia> \sh, So admin-controlled ${INSTALL_TOOL} is dangerous because it overwrites admin-installed /usr/local/bin/foo?  I'm not convinced of that.
<\sh> zyga: as said, the last time I used cpan shell was in 2002...and not on debian
<persia> \sh, Indeed.  That's the core of the argument :)
<brendand> i.e. it scrolls according to the scrollbar the cursor is on, not the scrolling action that you're performing
<pitti> zyga: I already said, /usr/local/ seems fine to me, as it's meant for this kind of local installation; I just haven't heard the argumetns against it
<zyga> pitti, oh, I did not see that - thanks
<brendand> i'm inclined towards 'bug' categorisation, for two reasons:
<zyga> pitti, what would be the required steps to make that change happen (from /var/lib to /usr/lib?)
<\sh> persia: depending on your admin thinking ;) I would like to see a configurable support of your install directory for all of them...(which gives at least pear a bad taste afaik)
<persia> brendand, I believe that's a feature, intended to support cases where people didn't have HID controls for the W dimension.
<zyga> pitti, sorry, /var/lib to /usr/local
<persia> \sh, For gems, I believe there's GEM_INSTALL, but yeah, at least needs consistency and better documentation.
<brendand> 1.) If you use the scroll wheel on a mouse then it follows the mouses behaviour, never the scrollbars
<persia> brendand, Ah, if you've a case for it, please file a bug.
<brendand> 2.) It doesn't work like that in all applications (Firefox works the 'expected'(?) way)
<\sh> persia: adding debconf question to the install process of <designated third party language package manage> asking: "Where do you want to install your <language dependend> packages?"
<persia> \sh, Makes autoinstall ugly, but I suppose.  Still, would need glue scripts to make it just work regardless of install location.
<pitti> zyga: technically? I don't know, I have no clue at all about ruby or gems
<pitti> zyga: the bug sounds like it'd be a ./configure option kind of switch?
<pitti> or perhaps a conf file, I don't know
<persia> It's a change to a variable setting in a patch.
<zyga> pitti, technically we just drop the debian patch
<zyga> pitti, I'm asking about the policy/steps to take
<pitti> \sh: why would an user care?
<persia> pitti, An admin of several developer workstations might care.
<zyga> pitti, how do I contact the debian maintainer if necessary
<pitti> zyga: I'd send a message to u-devel@, and do it if there is no major (and well-founded :) objection
<zyga> pitti, awesome
<\sh> pitti: you mean "why would a developer care"...I don't think our standard desktop user base uses package managers other then apt/aptitude/dpkg
<zyga> pitti, thanks
<pitti> zyga: and I'd talk to the Debian developer
<pitti> ah, you said that
<persia> zyga, It's more than just dropping the patch: consider migration scenarios: someone is sure to be annoyed if an upgrade breaks their carefully arranged gem behaviour.
<zyga> pitti, I'll ask the debian maintainter too
<zyga> ok
<pitti> \sh: well, but there should IMHO be one official system place (which is pretty much /usr/local) and per-user place (~/.local); otherwise the entire thing will just continue to be an incompatible mess IMHO
<lucas> zyga: yes
<zyga> persia, well it's partially true but if we just install to /usr/lib then people will not need to change PATH anymore, if they already did all the old gems will still be noticed
<pitti> \sh: ok, so why would a developer care?
<zyga> lucas, hi
<zyga> lucas, can you give me some insight into this?
<lucas> wait, reading the backlog
<zyga> lucas, why do we install to /var/lib in the first place?
<zyga> ok
<persia> zyga, What about folk who are using the /var/lib path?
<brendand> persia - turns out i was mistaken about 1 - but not 2
<lucas> ouch, it's huge
<brendand> persia - why would Firefox act differently?
<persia> brendand, 2) is just an artifact of the feature being enabled only for some toolkits.
<zyga> persia, to use executables they had to change their path first, that will continue to work
<tkamppeter> pitti, any chance to upload CUPS today?
<zyga> persia, I'm not sure about libraries though
<persia> zyga, That's not universally true.  There's lots of ways to start executables.
<\sh> pitti: they don't care actually..not on their local workstations...they are not sysadmins...but all the actions we do now, gives sysadmins a headache...
<pitti> tkamppeter: is it that urgent? ok
<persia> zyga, More importantly, their gem catalog, upgrade status, etc. may be confused if GEM_HOME is randomly changed.
<zyga> persia, yes but a lot of existing scripts assume that if you install rake then rake is on your path, you don't patch those scrips to look at /var/lib/gems/ etc - you just drop a PATH= before that
<pitti> \sh: well, the entire idea of pip/gems/etc. does, as they are essentially a parallel and much less robust packaging system
<zyga> persia, that's probably true, I'll dig deeper
<persia> zyga, Sure.  I'm not saying everything works, I'm just saying that there likely exist some folk for whom it does work now, and so you need to consider a painless migration path.
<zyga> persia, but even if the change is disruptive I'd say it's better than not having the change at all - we can work around that - a debconf setting that for new installs uses the /usr/local path and for existing installs continues to use /var/lib
<persia> That said, it's a good time to discuss this in Debian, as just-after-release is the best time for sweeping changes.
<zyga> persia, with possible dpkg-reconfigure to start from scratch with /usr/local if someone wants to
<zyga> right, that's true
<persia> debconf is a bad place to store information.  Better to adjust patches to have it be a config file (and maybe ask debconf questions to set initial values)
<zyga> pitti, (they also tend to work on other platforms and that's why people still use them)
<zyga> persia, that makes sense
<lucas> ok, backlog read.
<zyga> ok
<zyga> lucas, so what do you think about this bug?
<lucas> so. there are two conflicting visions on this rubygems stuff. if you see rubygems as a tool that manages ruby libraries in some obscure way the user doesn't need to know about, then it makes perfect sense to install to /var/lib
<\sh> pitti: when app devs KNOW what they are doing, but most app devs DON'T. this is my experience from several years working as sysadmin in bigger companies, that's why we go to the way of "app dev needs to ask sysadmin first what to do when they need software x and y"
<lucas> it's not _that_ different from mysql, for example.
<lucas> it's just some data storage.
<lucas> the other vision is to see it like "tar on steroids". and then it makes sense to install to /usr/local
<zyga> right, for libraries users don't care as this use case works out of the box _with_ this patch
<zyga> lucas, is there anything apart from executable scripts that may be broken if we stick to /var/lib?
<lucas> my position is that the ruby community is making a fuss about this, while it's not really important
<zyga> lucas, (in  other words) can we fix this by changing path somehow or do we really need to install stuff to /usr/local
<lucas> but I'm tired of the rants, so I would agree to push for going to /usr/local
<lucas> zyga: please let me finish:)
<zyga> (sorry)
<persia> Any gem that uses a static path rather than relatives and variables is potentially subject to issues if the path is other than that expected.
<tkamppeter> pitti, I only want to give the users more testing time, so that I can make the best decision between the two pdftoraster filters.
<lucas> now, there's the problem of executables. by default, rubygems put them in /usr/bin, which is really wrong and dangerous
<lucas> debian put them outside $PATH in /var/lib. that causes usability problems
<lucas> if we put the rest of the gem in /usr/local, I think that it would make sense to put the executables in /usr/local/bin
<lucas> so they are in $PATH, overriding stuff installed via packages
<lucas> that might break some users' machines, but they are asking for it, so why not
<zyga> lucas, that's consistent with other similar tools
<lucas> yup
<zyga> lucas, and with the purpose of /usr/local so I agree with you
<zyga> lucas, so, one more question what about 1.8 and 1.9
<lucas> so, for this to happen, the correct way, we need:
<lucas> - someone to update the current debian rubygems package to the latest rubygems version
<lucas> - patches to revert the path changes, and install executables to /usr/local/bin
<lucas> - a migration/upgrade plan that works
<lucas> and that work needs to be done for the standalone rubygems package (for ruby1.8) and for the ruby1.9.1 package, which includes rubygems
<zyga> (I think that first step is optional but I agree in general)
<pitti> tkamppeter: right, see /query
<zyga> lucas, what migration path do you think we can provide?
<zyga> lucas, does the option to change this on future installs and retain the old path on existing installations seem sensible to you?
<lucas> I'm not motivated to work on this personally, but will weight in the discussion, and am willing to apply the patches and maybe do the upload
<lucas> I think that we should change the path also for old installs
<lucas> (somehow)
<lucas> not to add to the confusion
<zyga> lucas, that would be an option to dpkg-reconfigure the package I think - otherwise we would break stuff that's already installed
<lucas> well, we could mv + add a symlink or something
<zyga> (or not if there is a way to "fix" this by moving all gems from /var to /usr/local)
<zyga> hmm, symlink is a simple solution, yeah
<lucas> that needs to be investigated, but as I said, I'm not motivated to work on this myself :)
<zyga> lucas, I understand, I read your blog post on this
<zyga> lucas, I'm asking for advice, you know much more than I do about this topic
<lucas> well, I think that the way to start is to experiment with the current rubygems package
<zyga> lucas, do you think it's necessary to update it to the most recent upstream version first?
<lucas> zyga: it would be better
<zyga> lucas, okay, let me see how much work is needed for that first
<zyga> lucas, would you care to add your thoughts to that bug?
<zyga> lucas, if you don't mind we could also confirm it
<lucas> well, maybe you can summarize the discussion there and then I'll adjust if it doesn't match my thoughts
<lucas> it's a good way to check that we understand each other
<zyga> lucas, sure, that's a good idea
<zyga> lucas, done
<zyga> lucas, I have an email to ubuntu-devel and diago moriwaki so if you don't find anything wrong with my comment I'll send it and we'll see what he thinks
<pitti> tkamppeter: uploaded to D and U, thanks
<tkamppeter> pitti, thanks for uploading.
<sjokkis> hi guys. anyone from the package maintenance team here?
<zul> pitti: ummm what?
<pitti> zul: I didn't say anythign; perhaps I mis-tab-ed "zyga"
<pitti> ah, so I did
<zul> pitti: ah ok
<pitti> that also explains why zyga didn't see my initial response
<pitti> zul: sorry about the confusion
<zul> pitti: no worries
<highvoltage> \sh, dholbach, didrocks: thanks! :D
<jdstrand> @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: jdstrand, Daviey
<mdz> pitti, whose turn is it to chair tech board?
<pitti> mdz: Scott according to previous report
<mdz> he doesn't seem to be online atm
<pitti> mdz: next rotation would be cjwatson then?
<mdz> will we even have quorum today?
<pitti> ah, I think kees said he could cover if Scott wasn't available
 * kees nods
<pitti> mdz: we did the last one with three persons as well, we didn't have to vote, though
<nigelb> bdrung: Hey, around?
<bdrung> nigelb: yes
<nigelb> bdrung: hey, with your new dd hat, want to talk about Debian as an upstream at UDW?
<bdrung> nigelb: i suspected that you ask that. i don't enjoy doing that. can't you find someone else?
 * bdrung tries to hide. ;)
<nigelb> bdrung: well, the someone else I asked suggested you :p
<nigelb> bdrung: but yeah,I can ask around :)
<cyphermox> cjwatson, hi, I know it's pretty late to be noticing this, but network-manager-vpnc appears to be missing from the network-manager package set
<cjwatson> cyphermox: odd, it was in the original list.  I must have made a mistake creating the set.  Fixed.
<cyphermox> thanks
<nigelb> rickspencer3: hi, got a few mins? :)
<rickspencer3> hi nigelb
<rickspencer3> sure
<rickspencer3> 'sup?
<nigelb> rickspencer3: hey, I was wondering if you'd have time to take a Q and A at UDW
<nigelb> It would rock to have one of those sessions at UDW
<rickspencer3> I would be happy to, though when specifically would you need me there?
<nigelb> You can pick an empty slot from here https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
<rickspencer3> nigelb, what topic should i put in?
<nigelb> rickspencer3: feel free to put in something creative, like I did for jcastro's session ;)
<rickspencer3> nigelb, well, what do you want me to discuss?
<manish> nigelb: can me with others in zeitgeist team take one session?
<nigelb> rickspencer3: general q and a would work or anything specific you want to put in :)
<nigelb> manish: I've been loojing for you! but then i was looking for m4n1sh
<nigelb> manish: YES!
<manish> Zeitgeist Internals
<manish> is the topic fine?
<nigelb> yup
<manish> Mon 28th Feb
<manish> 20UTC
<nigelb> manish: adding
<nigelb> rickspencer3: shall I add you in?
<nigelb> manish: who else with you?
<manish> nigelb: need to look
<manish> probably seiflotfy or mhr3
<manish> kamstrup is already taking a session
<nigelb> manish: right now, I've only put you down for it
<nigelb> manish: feel free to update later
<manish> sure
<rickspencer3> nigelb, sure, I think that the Thursday slots will work best for me
<nigelb> rickspencer3: 1800 UTC? :)
<nigelb> 'Talk to Rick'
 * Laney prepares some fiendish questions ;-)
<rickspencer3> nigelb, 1800 UTC is fine
<rickspencer3> thanks Laney ;)
<nigelb> rickspencer3: heh, Thanks :)
<rickspencer3> nigelb, I'm happy to do it, but does anyone even know who I am?
<rickspencer3> maybe "Q+A with Ubuntu Engineering Director"?
<nigelb> heh, ok
<nigelb> added
<manish> rickspencer3: people know you
<chrisccoulson> hi rickspencer3!
<manish> people know you because you mythbusted about rollign release
<mdeslaur> cjwatson: do I need to file graphical boot corruption against grub2 also, or is plymouth sufficient?
<cjwatson> mdeslaur: do you know which it is?
<cjwatson> mdeslaur: if not, just one place would be preferable
<mdeslaur> cjwatson: unfortunately no, it's bug 713088 and I filed it under plymouth
<ubottu> Launchpad bug 713088 in plymouth (Ubuntu) "[natty] plymouth boot screen corrupted with nouveau on Thinkpad T61" [Undecided,New] https://launchpad.net/bugs/713088
<mdeslaur> cjwatson: thanks
<tjaalton> mdeslaur: I'm seeing the same, but not with alpha2 livecd
<mdeslaur> tjaalton: huh
<mdeslaur> tjaalton: I wonder why the live cd would be different
<tjaalton> right
<tjaalton> me too :)
<cjwatson> tjaalton,mdeslaur: the live CD uses syslinux and doesn't start the kernel in graphics mode
<cjwatson> (this doesn't necessarily mean it's a grub2 bug though, perhaps merely something triggered by that)
<nigelb> tumbleweed: ping, hey
<mdeslaur> ah, cool. thanks for the explanation cjwatson
<nigelb> tumbleweed: Looking for someone talk about debian at UDW, would you be interested?
<bdrung> kees: ubuntu-dev-tools fails to build.
<dholbach> kees, watch out! bdrung is the ubuntu-dev-tools police! ;-)
 * dholbach hugs bdrung
<bdrung> dholbach: :P
<kees> bdrung: eek, did I typo my commit?
<bdrung> kees: no. you didn't check if debian/rules exist. the testcases didn't contain a rules file.
<kees> arrrgh
<kees> bdrung: sorry. I didn't check since the prior checks validated we were in a real source tree, and debian/rules is required.
<bdrung> kees: please extent the testcases and add one for checking for the missing rules file and one for finding xscb-original-maintainer in rules
<kees> yup
<kees> actually, the test-data does have a rules file. anyway, I'll go build it.
<bdrung> kees: yes, but we don't use the "test-data". we create virtual files.
<kees> bdrung: noted. I'll fix it up.
<bdrung> thanks
<SpamapS> jhunt: FYI, i've taken to tagging bugs that we may want to discuss/watch with the tag 'upstart'..
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for  http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: Daviey
<jhunt> SpamapS: great!
<SpamapS> jhunt: should help keep our bug squashing sessions more focused
<jdstrand> Daviey: fyi, I will upload getfem++ once I confirm it builds ok
<jhunt> agreed :)
<jdstrand> Daviey: re piloting
<kees> bdrung: okay, should be fixed up now.
<ogra_> hmm, does the utouch team have a dedicaterd channel ?
<ogra_> *dedicated
<vish> ogra_:  #ubuntu-touch
<ogra_> ah. thanks !
<vish> np..
<seb128> slangasek, hey
<seb128> slangasek, do you know if freetype is going to be updated from 2.4.2 to 2.4.4 in debian before natty?
<seb128> slangasek, context is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612484
<slangasek> seb128: planning to
<seb128> slangasek, I was wondering if I should do some backporting on update in ubuntu or just wait on debian
<seb128> on -> or
<alexbligh1> I am building lots of ubuntu packages using "debuild" from a script. Some build one package, some build more than one. How can I *programatically* tell what the filenames are of the packages that would be / have just been built?
<manish> alexbligh: you know about control file? right?
<slangasek> seb128: what timeframe do you need it in?  I probably can't commit to getting the update done in Debian for about 2 weeks
<seb128> slangasek, I would like to get the update in natty, 2.4.2 to 2.4.4 seems bug fixing so I don't think we need to aim for ff for it
<seb128> slangasek, before natty beta would be nice
<seb128> slangasek, what do you think?
<slangasek> seb128: I can do that, no worries
<alexbligh1> manish, sure, I know about the control file. That would tell me the package name(s). And the changes file would tell me the version. But I don't really want to go parse them all myself, plus work out whether it's amd64 etc.
<alexbligh1> i.e. I need the full filename, not just the package name
<manish> full name of?
<alexbligh1> Full name of the deb file "debuild" has buld, e.g. ../my-package-name_1.3.0.11822_amd64.deb
<seb128> slangasek, thanks, I will wait and sync from debian when you do the update then, less work for me, thanks
<slangasek> seb128: happy to help! :)
<alexbligh1> manish, I am autobuilding from an svn repository, which is why it is not "just obvious".
<manish> cdbs: you are needed for help
 * cdbs to the rescue
<cdbs> alexbligh1: you want to alter the filename of the resultant deb?
<cjwatson> alexbligh1: will be built: can't necessarily reliably tell in all cases.  have been built: debian/files, or parse the .changes ('dcmd' can help)
<alexbligh1> cdbs, no I just want to know what it will be called. Alternatively, if I could specify some form of hook at the end of the build process where it could execute some known command (without that being involved in EVERY build, that would be ok)
<cjwatson> man debuild /HOOKS
<cdbs> alexbligh1: I think the name is based like this: PACKAGENAME_FULLVERSION_ARCH.deb
<cdbs> cjwatson: 'man' rocks because of you
<alexbligh1> cdbs, Sure, but I don't know what that is going to be without parsing them
<alexbligh1> cjwatson, thanks will take a look
<cjwatson> cdbs: not enough to support actually typing 'man debuild /HOOKS' on the command line though ;-)
<cjwatson> I should make that work, some day
<ogra_> ++ :)
<cjwatson> you can do 'LESS=+/HOOKS man debuild'
<alexbligh1> cjwatson, ok, that's what I looked at before. I didn't understand how the hook finds out the name of the .deb either?
<cjwatson> alexbligh1: as I say, you can parse .changes if you know (or can construct) its name, or you can look at debian/files
<alexbligh1> AH! debian/files. So obvious
<alexbligh1> Doh!
<alexbligh1> thanks
<aljosa> is there a ppa for ubuntu maverick which has alsa 1.0.24 release packages?
<cjwatson> the reason I say you can't tell reliably before the build is that a handful of packages manually add extra deliverables to debian/files (using dpkg-distaddfile), and a package isn't actually obliged to build all the things listed in debian/control
<cjwatson> although, in practice, debian/control + debian/changelog + the output of dpkg-architecture is an extremely good predictor
<maco> aljosa: i dont know when 1.0.24 was released, but https://launchpad.net/~ubuntu-audio-dev/+archive/ppa has daily builds of alsa
<aljosa> maco: thanks
<alexbligh1> cjwatson, any idea why debian/files contains 2 identical lines, both of which are of the form "my-package_1.3.0.11822_amd64.deb unknown extra"
<cjwatson> alexbligh1: some bug in the package I imagine
<alexbligh1> cjwatson, indeed. it is my package though - what generates "files"?
<cjwatson> a stack whose bottom elements are dpkg-gencontrol and (sometimes) dpkg-distaddfile
<cjwatson> but you probably aren't calling those directly
<cjwatson> can I see the source package?
<alexbligh1> I have a manual "rules" file
<alexbligh1> contributed by sladen
<alexbligh1> and probably broken by me
<alexbligh1> I can put that up on pastebin
<cjwatson> sure
<alexbligh1> cjwatson, http://pastebin.com/aBbJFrNU
<alexbligh1> cdbs, no
<alexbligh1> cdbs, ignore that - scrollback error!
<cjwatson> you could just convert the whole thing to dh7 for about 90% less work
<cjwatson> make debian/compat say '7'; make sure the Build-Depends entry for debhelper is at least (>= 7); make debian/rules be a copy of /usr/share/doc/debhelper/examples/rules.tiny
<alexbligh1> I tried to convert to dh7 and it wanted to do configure, and automake and blah
<cjwatson> that's easy to override
<cjwatson> e.g. to stop dh_auto_configure doing anything:
<cjwatson> override_dh_auto_configure:
<cjwatson>         :
<cjwatson> it would only do that if your source package *looks* like it's autoconf etc. though
<alexbligh1> it looks nothing like autoconf
<alexbligh1> I probably did it wrong.
<cjwatson> perhaps I could see the whole source package; it would be quicker
<alexbligh1> OK. There are about 30 of them. But they are similar-ish.
<cjwatson> you could alternatively fix it by using -s in binary-arch and -i in binary-indep, in place of that ${BINARY_PACKAGES} and ${INDEP_PACKAGES} stuff
<cjwatson> (since it looks like the bug is some kind of duplication in which binary packages you're telling dh_* to operate on, so it would be sensible to let debhelper work that out itself)
<alexbligh1> cjwatson, Well I'm up fo converting to dh7 if it is not to much work
<cjwatson> alexbligh1: the procedure I gave above appears to work for your extility-config package, at least
<cjwatson> both procedures work actually
<alexbligh1> the dh7 stuff?
<alexbligh1> cjwatson, ok, will try that.... :-)
<cjwatson> either dh7 or -s/-i
<alexbligh1> Oooh, it's nearly there. It's putting .svn crud in, and I get: "dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}", which I guess means I shouldn't be doing that in control
<cjwatson> it's harmless to leave it there; but it means that you have ${shlibs:Depends} in control but you don't actually have any binaries in the package that link against shared libraries
<alexbligh1> Hmm, but it's complaining about perl too, and there is definitely perl in there
<cjwatson> you have perl in your package, but no ${perl:Depends} in debian/control
<cjwatson> hence "unused substitution variable"
<alexbligh1> Ah, unknown vs unused. I see.
<alexbligh1> cjwatson, thanks, that seems to be working.
<bdrung> kees: can you add a testcase where debian/rules is missing?
<kees> bdrung: sure, though is that sane?
<bdrung> kees: it's possible (but a rules file is needed if you want to build the package)
<kees> bdrung: what behavior would you like from update-maintainer? exit 1?
<bdrung> kees: just skip the "XSBC-Original in debian/rules" test
<kees> okay, fair enough
<alexbligh1> cjwatson, one last question (I hope). Is it possible to do a build which through the debuild command line overrides the "changelog" file? (or more precisely, will build it with a specifc version number).
<cjwatson> alexbligh1: arrange to pass the -v option to dh_gencontrol (see 'man dpkg-gencontrol')
<cjwatson> but you can't change the source package version that way
<cjwatson> better to change debian/changelog if you can possibly arrange it; that's what we do
<alexbligh1> Yeah I'm currently changing debian/changelog then changing it back, which is pretty disgusting. I suppose I could just copy the directory :-)
<smoser> wouldn't http://releases.ubuntu.com/ in the past have had alphas  on it ?
<ogra> nope, they were always on cdimage
<ogra> unless i massively misremember
<smoser> i guess i must have mirrored cdimage in the past.
<bdrung> kees: thanks
<kees> bdrung: you bet!
<RoAkSoAx> tedg: ping
<tedg> RoAkSoAx, Howdy
<RoAkSoAx> tedg: howdy!! I was wondering if you have any quick python examples to use the Messaging Indicator ?
<RoAkSoAx> Indicator/Menu
<tedg> RoAkSoAx, http://bazaar.launchpad.net/~indicator-applet-developers/libindicate/trunk/view/head:/examples/im-client.py
<RoAkSoAx> tedg: awesome! thank you!
<RoAkSoAx> tedg: do you have any ideas why the image of the .desktop file is nto showing in the "server" http://me.roaksoax.com/Screenshot.png
<tedg> RoAkSoAx, No, not off hand.
<tedg> Sorry, I need to run.
<ohsix> are there daily or regular cd images available for natty?
<cjwatson> ohsix: yes, cdimage.ubuntu.com
<cjwatson> e.g. the Ubuntu desktop daily builds are http://cdimage.ubuntu.com/daily-live/current/
#ubuntu-devel 2011-02-09
<ohsix> cjwatson: thanks
<ohsix> cjwatson: does zsync work well with those images? (<10% transferred between versions)
<charlie-tca> ohsix: yes, it does. I use it everyday to keep my copies updated
<cjwatson> I don't have measurements myself, but I don't see why it wouldn't, certainly
<ohsix> neat
<cjwatson> one of the reasons we use squashfs is that it's rsync-friendly, which should hold for zsync too
<ohsix> do the aufs update options in update-manager actually work?
<maco> aufs still exists?
<ohsix> well i never tried it, but i've seen it there; and it'd be cool if it did
<cjwatson> aufs still exists
<maco> i remember that it did....i remember talk of it on the mailing list
<maco> but i thought the upstream kernel rejected it?
<maco> cjwatson: is it sauce? or did upstream change minds?
<cjwatson> there's no other option for our live CDs right now
<cjwatson> I don't know what the state of the update-manager work is; mvo had it working at one point but I don't know if that's current or what the provisos were
<cjwatson> we're looking at a similar facility using btrfs
<ohsix> man an fs that can do snapshots and jump back to them would be great :D
<ohsix> afaik you can do it with lvm but it's convoluted and expensive
<cjwatson> unfortunately the alpha-2 installer wasn't quite up to the required installation bits, but alpha-3 should be; I don't know how far mvo's got with the u-m side
<maco> ohsix: https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027747.html
<ohsix> maco: thanks
<maco> cjwatson: this is what i was thinking of https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030952.html
<cjwatson> yes, there have been problems with aufs maintenance
<cjwatson> but union-mounts are perpetually almost-there-but-not-quite
<cjwatson> we would love to use them eventually ...
<maco> and given valerie having left red hat, i don't expect them to reach "quite" any quicker
<JordiGH> So my package shows a bug in Ubuntu that it doesn't show in Debian. It hasn't been modified; looks like it's just a problem with how some libraries get pulled in as dependencies during build time in Ubuntu and Debian. How should I fix it/
<JordiGH> ?
<JordiGH> This bug, to be precise: https://bugs.launchpad.net/ubuntu/+source/octave3.2/+bug/546671
<ubottu> Ubuntu bug 546671 in octave3.2 (Ubuntu) "fltk backend does not load" [Undecided,New]
<JordiGH> If there is no Ubuntu maintainer for a Debian package, is there a way to automatically request bugs for an Ubuntu package be forwarded to Debian?
<micahg> JordiGH: there's a link in the PTS to Ubuntu bugs
<JordiGH> Yeah, can I just get them forwarded to my email?
<micahg> JordiGH: you can subscribe to the package in launchpad if you like
<JordiGH> What's the point of reporting bugs to an Ubuntu package that has no Ubuntu maintainer? :-/
<micahg> JordiGH: Ubuntu doesn't have maintainers
<JordiGH> What are they called, Software Artists?
<cjwatson> it just means that packages do not necessarily have dedicated maintainers in the same way that they do in Debian
<micahg> JordiGH: unfortunately, we don't have enough people to get to all the bugs
<cjwatson> it doesn't mean that nobody will ever look at it
<JordiGH> Okay, I guess I'll subscribe to all of "my" Ubuntu packages... and figure out how to fix this bug that doesn't exist in Debian.
<maco> can start out just requesting a no-change rebuild in case it just needs to be rebuilt to go with current libraries i guess
<cjwatson> maco: best not to spend buildd resources on that until after confirming that it would fix the problem
<JordiGH> I don't that's the problem, I gotta figure out why it's not pulling in the right library at build time.
 * cjwatson peers at the build-dependencies
<JordiGH> I don't know that's
<micahg> maco: it's been rebuilt since it was reported with no succes
<maco> micahg: oh
<cjwatson> comparing the Debian and Ubuntu build logs would be a good plan
<micahg> JordiGH: I would suggest finding which package has that symbol and make sure that it was pulled in with the build-deps in Ubuntu, it could be something that the toolchain changes for natty/wheezy are trying to avoid
<cjwatson> the bug was reported long before those toolchain changes.
<JordiGH> So, how do I tell Launchpad to send me bug reports regarding these packakges?
<cjwatson> subscribe to the package, as micahg told you
<micahg> cjwatson: right, I'm saying the toolchain change might be meant to fix similar issues
<JordiGH> I know, where's the damn link?
<micahg> s/fix/expose/
<cjwatson> stop swearing and I'll tell you?
<JordiGH> Where's the beautiful link?
<cjwatson> heh
<cjwatson> https://launchpad.net/ubuntu/+source/octave3.2
<micahg> https://bugs.launchpad.net/ubuntu/+source/octave3.2/+subscribe
<cjwatson> top right, "Subscribe to bug mail"
<JordiGH> Alright, thanks.
<JordiGH> And now, I gotta do the same for the 30+ other packages, joy.
<cjwatson> the usual culprit for this kind of bug is alternatives in the build-dependency chain
<JordiGH> I gotta login?
 * JordiGH taps foot impatiently.
<cjwatson> you could use launchpadlib for that
 * cjwatson looks up the API
<maco> well you still have to login to use the api
<cjwatson> sure
<maco> in order to authorise your script to run
<cjwatson> but it saves clicking through 30+ links
<JordiGH> Look, guys, I don't want to get involved with Ubuntu; I just don't want my package making us look bad because nobody is looking at it in Ubuntu. I want to subscribe pkg-devel-octave@lists.alioth.debian.org to all of these packages, not my personal email.
<JordiGH> I guess I can use pkg-octave-devel@lists.alioth.debian.org as the subscription email address?
<micahg> JordiGH: well, you still have to log in, but then, create a team, set that e-mail as the team contact, subscribe the team
<cjwatson> you'll need an account whose preferred e-mail address is pkg-octave-devel
<broder> JordiGH: isn't this what the derivatives feature in Debian BTS is for?
<cjwatson> s/BTS/PTS/
<broder> or maybe it's PTS. i can't remember
<JordiGH> broder: What feature is that?
<broder> :)
 * micahg already suggested the link in the PTS to Ubuntu bugs (shows a count as well)
<cjwatson> it's in the developer's reference
<broder> http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system
<broder> you want to subscribe to the derivatives-bugs keyword
<JordiGH> broder: I see... thanks.
<broder> np
<cjwatson> hmm, no differences in the octave3.2 dependencies between Debian and Ubuntu that I can see
<cjwatson> (not meaningful ones anyway)
<cjwatson> I wonder if this is really a problem in octave itself, or a transitive problem somewhere else
<JordiGH> Where's the Ubuntu build log?
<cjwatson> https://launchpad.net/ubuntu/+source/octave3.2 links to all the versions
<cjwatson> (I have a browser keyword for https://launchpad.net/ubuntu/+source/%s, since that's nearly always my starting point)
<cjwatson> http://launchpadlibrarian.net/58223997/buildlog_ubuntu-natty-i386.octave3.2_3.2.4-8_BUILDING.txt.gz is the latest one on i386
 * cjwatson tries to install it here to look but it depends on the world so will take a while
<JordiGH> Well, I see it is pulling libfltk1.1-dev
<cjwatson> that seems to match Debian
<JordiGH> Wait, duh, fltk is not the problem, it's the opengl stuff.
<cjwatson> indeed.  it's pulling in the same libgl* packages too, though
<cjwatson> this is sort of why I wondered if it was a problem further down the stack
 * JordiGH wonders if it's a problem with C++ symbol mangliing.
<JordiGH> That could happen if there are several versions of g++ involved...
<JordiGH> Let's see, where is that Ubuntu libgl package...
<cjwatson> it's a while since that ABI changed
<cjwatson> octave3.2:1> backend("fltk")
<cjwatson> octave3.2:2>
<cjwatson> seems fine here
<JordiGH> Huh.
<JordiGH> Can you plot something?
<JordiGH> Type "sombrero".
<JordiGH> Without quotes.
<cjwatson> looks like a sombrero to me
<cjwatson> blue brim, red tip
<JordiGH> What version?
<cjwatson> 3.2.4-8, in natty
<cjwatson> so perhaps something between maverick and natty has fixed thig
<cjwatson> *this
<JordiGH> Oh, good.
<cjwatson> or perhaps it is architecture-specific
<maco> oh the if-statements
<cjwatson> I'm on i386; the only mention of an architecture anywhere in the bug report (most of the users don't say) is amd64
<cjwatson> I can't easily confirm that
<JordiGH> I dooooubt this is architecture specific.
<cjwatson> well, it's your package, but if it were mine I wouldn't like to rule it out until it's been confirmed, especially as we still don't know the cause :)
<JordiGH> Well, libftgl2 doesn't have that symbol for some reason.
<cjwatson> should it?
<JordiGH> Good question, ld seems to think so, at least when it created Octave.
<cjwatson> Google suggests opengl_renderer is part of the Octave API?
<cjwatson> e.g. http://octave.sourceforge.net/doxygen/html/classopengl__renderer.html
<JordiGH> Yes.
<JordiGH> That's our bare-bones Doxygen.
<cjwatson> so why should the vtable for opengl_renderer be supplied by some other library?
<JordiGH> Wait, I see, that is an Octave symbol...
<JordiGH> Hmmmm....
<cjwatson> it should be in liboctinterp; in the lucid amd64 package, at least, it isn't
<JordiGH> Okay, I'm feeling like a n00b... why does objdump tell me that liboctave has no symbols? Does that just mean it's been stripped? But don't you need symbols in order to link to it?
 * cjwatson unpacks a few more for comparison
<cjwatson> probably wrong options, I'm using 'nm -D' here
<cjwatson> there are different types of symbols and you may be asking for the wrong type
<JordiGH> Huh, I don't want to disassemble it.
<cjwatson> nm -D isn't a disassembler.
<cjwatson> so maverick amd64 is broken, natty amd64 works
<cjwatson> or at least has the right symbols
<cjwatson> same with i386 - lucid/maverick broken, natty fixed
<JordiGH> Huh.
<JordiGH> How very odd.
<cjwatson> so you're right that it's not arch-specific
 * cjwatson diffs the maverick and natty build logs
<JordiGH> Oh, cute, nm can demangle C++ symbols.
<JordiGH> That's pretty damn interesting.
<cjwatson> -checking for glEnable in -lGL... no
<cjwatson> +checking for glEnable in -lGL... yes
<cjwatson> looks like the first difference of note
<JordiGH> You diffed the build logs...
<cjwatson> yes
<cjwatson> GL/gl.h was present in both though
<cjwatson> and in fact GL/gl.h is identical in maverick and natty's mesa-common-dev
<cjwatson> curiouser and curiouser
<JordiGH> and it's the same Octave version, down to the Debian revision, isn't it?
<cjwatson> no
<cjwatson>  octave3.2 |    3.2.4-6 | maverick/universe | source, amd64, armel, i386, powerpc
<cjwatson>  octave3.2 |    3.2.4-8 | natty/universe | source, amd64, armel, i386, powerpc
<JordiGH> Well, well, well...
<cjwatson> I wonder if the removal of libgl1-mesa-swx11-dev and libglu1-mesa-dev from the build-deps was significant
<cjwatson> not a whole lot else changed
<JordiGH> http://bugs.debian.org/591333
<RAOF> Wait - libgl1-mesa-swx11-dev was in the build-deps?
<JordiGH> RAOF: Yes.
<JordiGH> So that could make the configure script fail.
<cjwatson> aha, I misread the maverick build log too - libgl1-mesa-dev *wasn't* installed then, of course
<cjwatson> (due to the Conflicts from libgl1-mesa-swx11-dev
<cjwatson> )
<JordiGH> Okay, mystery solved.
<JordiGH> cjwatson: Aren't you a DD?
<JordiGH> I've seen your name in Debianthings.
<cjwatson> I still don't entirely get it though; GL/gl.h is provided by mesa-common-dev, which is depended upon by libgl1-mesa-dev and libgl1-mesa-swx11-dev both
<cjwatson> so what's making the configure test fail?
<cjwatson> JordiGH: yes
<RAOF> It's quite possible that libgl1-mesa-swx11 is broken; I can't imagine many people use it, so we wouldn't notice.
<cjwatson> damn, I missed taking note of my ten-year anniversary in Debian :-)
 * maco sets cake in front of cjwatson
<cjwatson> Subject: New Debian maintainer Colin Watson
<cjwatson> Date: Mon, 05 Feb 2001 20:36:19 +0000
<cjwatson> anyway
<JordiGH> Happy decennial.
<cjwatson> thanks :)
<cjwatson> ah, octave3.2 is doing AC_TRY_LINK
<charlie-tca> cjwatson: Congratulations on 10 years in Debian! that is quite an accomplishment
<cjwatson> sorry, AC_CHECK_LIB
<JordiGH> cjwatson: Sorry, I've managed to get this far in life without understanding autotools. What's significant about those two macros?
<cjwatson> just that the output of configure would depend on the shared libraries providing those symbols as well as on the headers
<cjwatson> I suspect that if we really wanted to nail this down it would require seeing config.log, which hasn't been preserved here
<cjwatson> but it does seem as though those two build-deps are the culprit
<cjwatson> is it safe to remove those in both 3.2.3-1 and 3.2.4-6?
<JordiGH> Huh, can you backport fixes to older Ubuntu releases?
<JordiGH> I thought they only did security fixes.
<cjwatson> we can
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates
<cjwatson> this is broken functionality, I think it's reasonable to fix
<JordiGH> Well, we only use opengl for that particular function, so you can try backporting Thomas's fix to those two Ubuntu releases, and if you get the sombrero, then it works.
<cjwatson> I can take care of that
<cjwatson> thanks for the debugging
<JordiGH> And thanks to you too.
<didrocks> good morning
<Daviey> oops
<Daviey> @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:
<nigelb> Daviey: patch piloting over night? ;)
<pitti> Good morning
<cdbs> Good morning Martin sir!
<hdon> the cgdb in ubu10.04 does not properly ioctl() with TIOCSWINSZ
<hdon> the latest release from their website works, though
<hdon> err
<hdon> actually know, i just built from their bleeding edge
<hdon> but anyhow
<hdon> it's a simple fix. you guys should put it in
<hdon> d'oh
<hdon> nevermind, it still doesn't. i forgot i put in a work-around.
 * hdon fixes
<hdon> $ cgdb cgdb # YES!
<broder> hdon: best thing to do is file a bug, prepare a debdiff or a merge proposal (https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff), and ask for sponsorship (https://wiki.ubuntu.com/SponsorshipProcess)
<hdon> broder, sorry for the wrong information. the bug hasn't been fixed in any version of cgdb. i am fixing it now
<broder> well, once you do...
<dholbach> good morning
<hdon> i will have to send the fix to the cgdb maintainer
<hdon> someone else can get it into ubu
<dholbach> if you have a new project you want to introduce at UDW (5 minutes) and attract new people to help out, please consider signing up at the bottom of https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions
<nigelb> dholbach: does this look good? http://justanothertriager.wordpress.com/2011/02/09/have-an-interesting-project-you-want-to-talk-about/
<nigelb> arg, sorrywrong channel
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for  http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: dholbach
<cdbs> dholbach: yay!
 * pitti hugs dholbach
<hdon> broder, the bug is not in cgdb, it is in gdb. a warning occurs, though. you can see the bug in action here: http://codebad.com/~donny/gdb-tty-bug.png
<dholbach> hey seb128 - who maintains gnome-session upstream? can we ping them about https://bugzilla.gnome.org/show_bug.cgi?id=637449 ? :)
<seb128> dholbach, vuntz
<seb128> dholbach, he's on #ubuntu-desktop, you can ping him there if you want
<dholbach> I'm pinging him - thanks :)
<seb128> yw
<pitti> james_w: hm, do you still remember why I reverted the WI tracker blueprints branch back then?
<pitti> james_w: was it just because lillypilly was still running hardy?
<sabdfl> pitti: i know the feeling. the past recedes rapidly, doesn't it :-)
<sabdfl> like my hairline
<pitti> or "maverick"
<cdbs> :o sa-bdfl :)
<broder> ha! i think the sponsorship form is counting html entities as multiple characters
<broder> at least, that's my best explanation for why it thought my write-up was 11 characters longer than i did
<maxb> *blink*
<maxb> lillypilly?
<pitti> maxb: aka "people.canonical.com"
<maxb> Just when I thought canonical machine names couldn't get weirder....
<pitti> YK, http://lillypilly.canonical.com/ confirms that it works :)
<pitti> maxb: you think lillypilly is weird? have you looked at https://launchpad.net/builders recently, especially the armel ones?
<cody-somerville> Wow. I just realized I've been reading 'lillypilly' as 'lillypad' this entire time.
 * pitti hasn't attempted trying to pronounce actinidiaceae or #canonical anacardiaceae yet
<pitti> (eh, where did this "#canonical" come from)
<cdbs> Wow!
<cdbs> internal canonical discussions on #ubuntu-devel
<pitti> I guess IS ran out of Penguin names, fruits and Antarctica stations at some point
<pitti> and apparently the periodic table of elements as well :)
<cody-somerville> and berries
<broder> that's a lot of things to run out of
<Nafallo> pitti: you missed elements, but apparently we're still using the fruits scheme.
<pitti> Nafallo: "I missed elements"?
<pitti> Nafallo: oh, if you mean that buildds don't exhaust element names, we have more servers than just buildds :)
<Nafallo> pitti: we went through the periodic table between antarctica stations and fruits ;-)
<cdbs> I kinda like the names of the buildds
<cdbs> makes me feel hungary
<pitti> Nafallo: I mentioned that above :)
<cdbs> *hungry
<Nafallo> ah.
<jpds> cdbs: Some people feel anger.
<pitti> Nafallo: will you guys ever move to Comic characters?
<Nafallo> pitti: not my decision
<cdbs> Or Toy Story characters, like Debian does
<pitti> nah, NIH
<pitti> and too confusing :)
<directhex> debian already ran out of toy story characters
<directhex> hence using a toy story 2 character for 7.0
<broder> wheezy was the singing squeaky-toy penguin, right?
<directhex> yep. from TS2, which has absolutely no historical ties to debian, other than being the sequel to TS1
<Laney> what is the historical tie with TS1?
<directhex> Laney, bruce perens, bruce@pixar.com
<Laney> ah yes
<directhex> and related, e.g debian-bugs@pixar.com
 * amitk thinks IS should dedicating machine names to the top ubuntu contributors
<pitti> . o { Hey Nafallo, can you please poke sabdfl? it crashed again }
<pitti> amitk: I don't think that'll come across very well..
<amitk> pitti: you mean there will be friction against the Ubuntu Hall of Fame?
<amitk> pitti: or you think people don't want machines named after them :)
<pitti> rather, talking about people names when you speak about machines :)
<pitti> that, too
 * Laney fscks amitk 
 * amitk goes back to hacking on the kernel and leaves community sensitivity to others... :-p
<pitti> I have named my machines after Duck Tales characters
<Nafallo> pitti: lolnovetoed
<cjwatson> directhex: Debian hadn't quite run through everything in TS1 - scanning down wikipedia, there's at least RC, Mr. Spell, Rocky, Snake, Robot, Shark, Mike
<cjwatson> I assume the RMs just preferred Wheezy
<cjwatson> ("RC" would be more than a little confusing ...)
<directhex> cjwatson, i was under the impression RC was on the excluded list
 * cody-somerville names his machines after the dictionary.com word of the day.
<cjwatson> still leaves at least six though
<directhex> the machines at home are named delerium, death, desire & dream. cake to the person who guesses the scheme
<cody-somerville> directhex, The Endless?
<directhex> cake!
 * cody-somerville suspects the cake is a lie.
<tjaalton> what is the correct way to configure the console keymap? 'cached.kmap.gz' is a 20 byte file here
<tjaalton> tried reconfiguring console-setup
<mr_pouit> cjwatson: hi, what's the "correct" way of getting rid of the aubergine bg in grub-pc (the xubuntu plymouth theme is black, so it's a bit weird currently)? I tried to drop a 06_xubuntu_theme in /etc/grub.d to override the bg: http://paste.ubuntu.com/564912/. It works, but I guess it's not that nice, as it makes grub set the aubergine bg, and right after set a black one...
<pitti> james_w: ah, nevermind, https://code.launchpad.net/~james-w/launchpad-work-items-tracker/blueprints-api/+merge/43240 has the reason (overly long file names)
<dholbach> does anybody have a moderately educated opinion about bug 714838 (syncing newest gnutls26) - the sync generally looks good and we're still before FF - but it looks loads and loads changed (2.8â2.10)
<ubottu> Launchpad bug 714838 in gnutls26 (Ubuntu) "Sync gnutls26 2.10.4-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/714838
<cjwatson> tjaalton: reconfigure console-setup or edit /etc/default/keyboard - it may be that it currently requires a manual 'sudo setupcon' due to some bug
<cjwatson> mr_pouit: there's no correct way to do it in add-on packages right now - it'll need changes in grub2
<cjwatson> dholbach: I think it should be the reporter's responsibility to analyse reverse dependencies and prepare a transition if one is needed
 * dholbach nods
<cjwatson> and that he should be asked to do that
<cjwatson> mind you is it actually a transition?
<tjaalton> cjwatson: it looks fine though, just that the console keymap on my desktop is wrong, laptop has the same settings and it's fine there (though no umlauts with the vga font it seems)
<cjwatson> apparently not, it's still gnutls26
<Laney> no
<dholbach> cjwatson, yes, no transition - just a huge version jump
<cjwatson> then I have no educated opinion :)
<cjwatson> tjaalton: does 'sudo setupcon' fix it?
<tjaalton> cjwatson: no, it creates the 20byte cache file, if I've removed it before
<cjwatson> forget about the cache file, I mean does it fix the currently-in-use keymap?
<tjaalton> no
<cjwatson> then I need more details - what's the current behaviour compared to desired behaviour?
<tjaalton> cjwatson: it's the us layout
<tjaalton> on X it has been fine
<tjaalton> maybe it was broken before upgrading lucid->maverick->natty yesterday, can't remember..
<cjwatson> tjaalton: "it's the us layout" is that current state or desired state?
<cjwatson> show me /etc/default/keyboard and /etc/default/console-setup
<tjaalton> cjwatson: current, I want fi :)
<tjaalton> cjwatson: http://paste.ubuntu.com/564947/ http://paste.ubuntu.com/564948/
<cjwatson> tjaalton: now the output of 'sh -x /bin/setupcon' (run at the console)
<tjaalton> cjwatson: sigh, how do I get the output somewhere? script, screen, redirecting stderr all fail
<tjaalton> it just says "not on the linux console..."
<cjwatson> hmm
<cjwatson> tjaalton: use --force
<tjaalton> naturally :)
<tjaalton> cjwatson: http://paste.ubuntu.com/564951/
<cjwatson> tjaalton: could you remove /etc/console-setup/cached.kmap.gz and do the same again?
<cjwatson> (20-byte file sounds like the result of gzipping nothing)
<tjaalton> ok, got it. the error from ckbcomp is "Unknown name $sun_t6_custom"
<cjwatson> what version of keyboard-configuration and console-setup?
<tjaalton> uh, 1.57ubuntu5
<tjaalton> both
<tjaalton> I see there are newer ones available
<cjwatson> console-setup (1.57ubuntu6) natty; urgency=low
<cjwatson>   * Allow underscores in rules variables ($sun_t6_custom).
<cjwatson>  -- Evan Dandrea <ev@ubuntu.com>  Mon, 07 Feb 2011 15:14:44 +0000
<tjaalton> :)
<tjaalton> wonder why it wasn't installed yesterday during the upgrade
<tjaalton> main archive and all.. but
<cjwatson> tjaalton: ubuntu6 failed to build; ubuntu7 succeeded (yesterday)
<tjaalton> cjwatson: ok, that explains it. and the layout is good now
<cjwatson> good good
<tjaalton> :)
<barry> dholbach: ping, re: bug 686257 merge proposal (python-keyring)
<ubottu> Launchpad bug 686257 in python-keyring (Ubuntu) "upgrade to python-keyring 0.5.1 (and MIR)" [High,Triaged] https://launchpad.net/bugs/686257
<ogra> dholbach, hmm, you already acked all sync requests ari-tczew asked me for
 * ogra didnt know he had asked you too
<seb128> ogra, he probably didn't
<seb128> ogra, dholbach just do clean the sponsoring queue daily
<seb128> ogra, without need pings to do it
<seb128> needing
<ogra> ah
<seb128> ogra, seems he's patch pilot as well today ;-)
<ogra> oh, i missed that bit
<ogra> who reads topics anyway :P
<ari-tczew> DktrKranz: ping
 * hallyn just finally read the loom howto, figures he'll have to give those a shot
<hallyn> for his udd sanity
<ari-tczew> is there anyone with concerns about upgrade gnutls26 to 2.10*? bug 714838
<ubottu> Launchpad bug 714838 in gnutls26 (Ubuntu) "Sync gnutls26 2.10.4-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/714838
<hallyn> jdstrand: I"ve uploaded the debdiff and source package for libvirt 0.8.7 to people.canonical.com/~serge/libvirt_0.8.7-0ubuntu1.src.tgz, if you wanted to take a look.
<DktrKranz> ari-tczew: pong
<jdstrand> hallyn: ack, but I won't be able to look at it for a bit
<jdstrand> hallyn: thanks for doing it :)
<ari-tczew> DktrKranz: IIRC at the natty start we have discussed about something related to gnutls... could you give a feedback for my question asked 5 minutes ago here?
<dholbach> barry, pong
<barry> dholbach: hi.  comment updated on https://code.launchpad.net/~barry/ubuntu/natty/python-keyring/bug-686257/+merge/48967
<hallyn> jdstrand: thanks - no hurry, i'm gonna need sometime before i can get to testing it the way i want
<DktrKranz> ari-tczew: I think it was about gnustep
<dholbach> barry, will check in a bit
<barry> dholbach: thanks
<hallyn> (unfortunately I can't try loom right now bc I can't install packages - this is not good :)
<ari-tczew> DktrKranz: yea probably, have you got any concerns about upgrade gnutls to 2.10.4?
<DktrKranz> ari-tczew: non that I know of
<ari-tczew> dholbach: ^^
<dholbach> barry, I never saw tests packaged, but I haven't looked closely for a while - so I don't know - it just looked weird to me
<dholbach> ari-tczew, then get somebody else to ACK it - I just wasn't sure myself
<barry> dholbach: looking in my build log keyring/tests subpackage is included in the .deb afaict
<dholbach> barry, yes, that's what I noticed too and why I wrote the comment
<dholbach> I personally don't see the need (if people want code examples, they can grab the source - also users should be able to trust the package maintainers that the test suite was run) - but I'm very happy to be overruled - as I said: I don't know what "the standard" is there :)
<barry> dholbach: i get it now (the tests weren't included before but now they are)
<barry> dholbach: i'm not sure there *is* a standard ;)
<barry> dholbach: it was debated to no consensus in upstream mlists.  you know now which side i came down on :)
<dholbach> yep
<barry> dholbach: do you feel strongly that they should not be included?
<dholbach> no, as I said: I'm happy to be overruled
<pitti> FWIW, I think it's by and large a waste to include them in binary pacakges
<barry> pitti: please see my comment in the above mentioned merge proposal
<pitti> barry: I do agree to the argument that these make it easy to check the correctness of the installed package
<barry> pitti: i also like the simpler packaging when the tests are a subpackage (nothing to rm)
<barry> dholbach, pitti: in the absence of consensus, can we keep the tests in this case?
<dholbach> barry, I'm happy whatever
<pitti> yeah, I don't think it's a policy matter
<pitti> shoudl be the discretion of the maintainer
<pitti> I don't have a strong opinion against it
<barry> cool. thanks.
<dholbach> barry, I removed the "ppa0"
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for  http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<barry> dholbach: thanks.  that was an artifact of a test build.
<dholbach> ari-tczew, what do you want to know about Harvest?
<hallyn> hm, a freshly created package using 'dh_make' is calling '/usr/bin/make -C .', but a 'CFLAGS += XYZ" in the top-level Makefile is being ignored.  Is that expected?
<ari-tczew> dholbach: what kind of bugs are reported on harvest?
<dholbach> ari-tczew, you can see the list of "kinds of opportunities" on the left hand side and hover over them with the mouse
<dholbach> (outstanding merges, rc bugs in Debian, etc.)
<ari-tczew> dholbach: I'm clicking on kinds and nothing happened
<dholbach> hover
<dholbach> don't blick
<dholbach> click
<ari-tczew> ?
<hallyn> do i have maybe cdbs was overkill for this package
<dholbach> move the mouse of "bitesize" for example and don't move for a second
<dholbach> it will give you some information what "bitesize" is about
<ari-tczew> dholbach: ok I guess how it works
<dholbach> you can select package sets and opportunity types you're interested in
<ari-tczew> dholbach: I've received some informations that natty has got a lot of uninstallable packages. does harvest support this kind of bugs?
<dholbach> no, I don't think there's a list for it
<ari-tczew> dholbach: what do you think about expand harvest with department for uninstallable packages?
<dholbach> ari-tczew, the only thing you need to do is write a script that spits out data according to: http://daniel.holba.ch/blog/?p=838
<dholbach> I can then add it to Harvest easily
<dholbach> Harvest is decentral: you write a script that writes a simple enough list, I add it to Harvest
<dholbach> check out http://harvest.ubuntu.com for more information
<ari-tczew> dholbach: I'm not a code developer.
<dholbach> and I won't have the time in the next few weeks, but I agree that it's a good idea
<geser> smoser: Hi, are you perhaps working on the ec2-api-tools FTBFS? I've gave it a try but only run into a new issue once I fixed one (I've already run into 2)
<smoser> geser, i did not know it was ftbfs. i will make sure it does not. bug ?
<geser> smoser: no bug yet but http://launchpadlibrarian.net/58997063/buildlog_ubuntu-natty-i386.ec2-api-tools_1.3.57419-0ubuntu2_FAILEDTOBUILD.txt.gz
<ari-tczew> dholbach: No matching opportunities in 238 selected packages
<smoser> first issue is java depends ?
<ari-tczew> dholbach: why only 238 packages are supported?
<geser> smoser: I can file a bug and attach those fixes that I already have if it helps you
<dholbach> ari-tczew, which package set is currently selected?
<ari-tczew> dholbach: nothing
<dholbach> ari-tczew, there are much much more packages supported - it just shows you what you selected and what it has data available for
<dholbach> ari-tczew, please send me a screenshot
<smoser> geser, sure. it can't hurt.
<smoser> thank you.
<ari-tczew> dholbach: http://img204.imageshack.us/i/harvestx.png/
<geser> smoser: bug 715818
<ubottu> Launchpad bug 715818 in ec2-api-tools (Ubuntu) "ec2-api-tools FTBFS in natty" [Undecided,New] https://launchpad.net/bugs/715818
<dholbach> ari-tczew, ok - can you file a bug about it? http://launchpad.net/harvest/+filebug
<dholbach> I don't know what's going on right now - maybe Dylan will know
<pitti> barry: btw, the computer-janitor pygi branch should work well now with current natty's pygobject
<cdbs> smoser: euca2ools is no longer shipping the EUCALYPTUS_CERT for EC2. why?
<smoser> cdbs, that not be intended
<cdbs> smoser: really? in your blog post it appears its very much needed for AWS
<smoser> *not shipping it* would be not intended :)
<smoser> it is packaged in /usr/share/euca2ools/cert-ec2.pem
<cdbs> :o
 * cdbs missed that in dpkg -L
<smoser> cdbs, if this is broken, let me know, but it does not appear to me that it should be.
<barry> pitti: cool, i'll take a look, thanks
<jam> barry: just seeing if you're actually online right now, had some questions for you
<barry> jam: i'm here, though just finishing up a meeting
<jam> barry: k, just ping me when you're done, nothing urgent, but some udd questions
<barry> jam: all freed up
<jam> barry: I was thinking about the package-import stuff. And I thought it might be nice to prototype some stuff, and work with someone who is actually doing udd, and see what feedback we get
<jam> I can write code, but I really don't know a ton about packaging.
<jam> So I was thinking it might be nice to do some prototype conversions of packages you actually maintain, so that you can give feedback about what you like/don't like
<barry> jam: i'd be happy to be your guinea pig :)
<jam> rather than hypothetical "wouldn't it be good if the importer did X"
<barry> jam: unfortunately, i will not be at today's udd meeting
<lool> cjwatson: Oy!  We're lacking some modules in initramfs for btrfs and probably others on some architecture/kernels; if btrfs-tools is installed, the initramfs has the right modules though; I see partman-btrfs arranges for this to be installed, but I was wondering whether we wanted to seed this somewhere so that Ubuntu initramfses have support for btrfs?
<cjwatson> lool: perhaps standard along with the other filesystems there, but I'm not entirely convinced - most of the filesystems there are ones you might have on USB sticks or whatever, and btrfs isn't really in that category
<cjwatson> lool: the initramfs only needs it if / is btrfs, and surely the installer should take care of that
<lool> cjwatson: correct, d-i and ubiquity take care of that
<lool> via partman-btrfs
<cjwatson> indeed
<lool> cjwatson: btrfs is "special" in that its deps are broken in the kernel modules
<lool> just like ubifs
<cjwatson> "its deps are broken"?
<lool> cjwatson: The module dependencies are insufficient to pull the right stuff
<lool> long story, but basically multiple providers of the feature prevents the module from having a sensible dep
<cjwatson> oh, you mean the way btrfs-tools/debian/local/btrfs.modules lists libcrc32c crc32c zlib_deflate btrfs
<lool> Yes
<cjwatson> is btrfs.ko itself in the initramfses you care about, just not its dependencies?
<lool> correct
<cjwatson> btrfs is probably there because 'auto_add_modules base' in initramfs-tools adds it
<cjwatson> so in that case I'd recommend adding those extra modules in 'auto_add_modules base' too
<cjwatson> that seems better than seeding btrfs-tools
<cjwatson> and it should be upstreamable to Debian if their kernel is the same way
<lool> cjwatson: Thanks a lot; I wanted to do this too, pinged maks on #debian-devel, but I dind't specifically know where to fix this in initramfs-tools
<lool> cjwatson: wheredo you usually upstream hte initramfs-tools bugfixes?
<cjwatson> just grep for btrfs in the source, there's only one non-changelog match
<cjwatson> bugs.debian.org
<lool> cjwatson: thanks a lot
<jam> barry: so can you give a couple of packages that you would like me to play around with?
<lool> cjwatson: There is one btrfs utility which gets copied into the initramfs too; I don't know whether that'd be relevant enough to warrant seeding
<barry> jam: sure.  do you want ones with or without quilt3 patches?
<lool> I don't use btrfs at this point
<jam> barry: I want ones that you use :), but both is probably good
<cjwatson> lool: it's useful for control and I think for subvolume bits and pieces but I don't think it's vital
<barry> jam: okay :)  i'm going to grab some lunch and look at my set of branches.  will let you know
<jam> barry: grabbing lunch myself, thanks. You can just email me if you want
<lool> cjwatson: Ok; I will defer the seed part then, thanks
<barry> jam +1
<lool> cjwatson: while we're at it, I've noticed ubifs has a similar issue and an uglier workaround (if / is ubifs and MODULES=dep, add these modules); do you think it should be listed in base too, or is it just a weird filesystem?
<lool> cjwatson: Actually I'm just realizing that the base fix will only work for MODULES=most, probably not =dep
<cjwatson> lool: ubifs seems a bit too special-purpose for base
<lool> cjwatson: Ok; I think I will use the same approach for btrfs + MODULES=dep than for ubifs
<ari-tczew> cjwatson: you're admin with knowledge, maybe you have an opinion for bug 714838
<ubottu> Launchpad bug 714838 in gnutls26 (Ubuntu) "Sync gnutls26 2.10.4-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/714838
<cjwatson> lool: this does seem like it ought to be a set of manual hints to the dependency resolver, yes
<cjwatson> ari-tczew: I disclaimed having an opinion earlier when dholbach asked.  I think the basic questions should be: what's the reason for the sync, and are you prepared to take responsibility for any problems it causes?
<cjwatson> it seems like there should be more of a reason than just it being available
<ari-tczew> Found a total of 93 reverse build-depend(s) for libgnutls-dev.
<ari-tczew> not good
<cjwatson> I think that's why it made dholbach nervous; it's fairly core, and it's hard to roll back libraries
<cjwatson> so there'd have to be a substantial benefit to justify the risk
<ari-tczew> cjwatson: I think he was easy as usually.
<ari-tczew> cjwatson: I'll ask kees during his today piloting. If he won't be convinced, I'll delay sync to next devel cycle.
<lool> cjwatson: Turns out there's a nicer fix in tip initramfs-tools as maks pointed out; I guess it means I need to mergeit  :-)
<cjwatson> lool: I've got most of that merge in bzr, I'll do it if you like
<cjwatson> I just forgot to commit
<lool> cjwatson: Awesome
<lool> cjwatson: Well I'd love if you were to upload that, thanks a lot!
<cjwatson> I'm sure I can manage that :)
<cjwatson> I'd been meaning to anyway
<kees> activate super pursuit mode!
<kees> wait, that's not it.
<kees> @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: kees
<kees> ari-tczew: reading back-scroll doesn't help. what's the question?
<cjwatson> lool: done
<ari-tczew> kees: we are considering useful of sync bug 714838
<ubottu> Launchpad bug 714838 in gnutls26 (Ubuntu) "Sync gnutls26 2.10.4-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/714838
 * lool hugs cjwatson 
<kees> ari-tczew: the only reason gnutls26 appeared in unstable is because debian opened for development again. I don't think we should sync it this cycle without a more pressing reason.
<ari-tczew> kees: I'll delay it for next devel cycle then.
<kees> okay, thanks
<ari-tczew> kees: I'm counting on exim4. ;-)
<kees> ari-tczew: which bug# is that one?
<ari-tczew> kees: bug 713855
<ubottu> Launchpad bug 713855 in exim4 (Ubuntu) "Merge exim4 4.74-1 (main) from Debian experimental (main)" [Medium,Confirmed] https://launchpad.net/bugs/713855
<kees> ari-tczew: for exim4, can you change 71_exiq_grep_error_on_messages_without_size.patch to use the upstream fix (from that report), drop the "From" (this should have been Author: with Daniel van Eeden) and add an Origin: line, and finally mention the debian bug # in the changelog?
<ari-tczew> kees: FYI, I know about new way created by upstream, but I submitted debdiff before upstream patch.
<kees> ari-tczew: no worries. best we get the "real" fix in, though.
<hv> I read about a serious java bug on slashdot.  I cannot find a corresponding bug number on bugs.debian.org, or bugs.launchpad.org.  The bug is this: Double.parseDouble("2.2250738585072012e-308") produces an infinite loop.
<hv> Is this well known?
<ari-tczew> kees: I wanted get it by merging next upstream release, but that's right, we can get it right now and drop with merging next upstream release.
<ari-tczew> hv: #launchpad
<micahg> ari-tczew: no, he's asking about java
<ari-tczew> ah
<mtaylor> pitti: hi! is there a way to silence WARNING: the following files are not recognized by DistUtilsExtra.auto:
<kees> ari-tczew: right
<ari-tczew> kees: what's the deadline of your piloting today?
<ari-tczew> since I have to do some other stuff right now, I'll finish exim4 later
<kees> ari-tczew: I'm done in about 3.5 hours
<ari-tczew> ok
<kees> ari-tczew: no worries; it's an easy fix now that I've read through the rest of it.
<micahg> kees: can you sponsor my pidgin merge?
<kees> micahg: bug #?
<micahg> kees: I just a merge proposal, no bug: https://code.launchpad.net/~micahg/ubuntu/natty/pidgin/2.7.9-2/+merge/48721
 * micahg figured it would be picked up the next morning :)
<cjwatson> hv: best to file a bug if you find it in our Java implementation.  We don't normally trawl Slashdot looking for bug reports there. :-)
<hv> cjwatson: I don't expect bug reports in slashdot, either.  Last one I remember was the debian openssh fiasco ;)
<cjwatson> s/openssh/openssl/
<hv> apparently openjdk does not use launchpad for bug reports (or that is what launchpad says)
<kees> micahg: looking at it now
<cjwatson> you should file bug reports on Ubuntu packages in the package namespace, not the upstream project namespace
<micahg> kees: thanks
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/openjdk-6
<cjwatson> (or, better, 'ubuntu-bug openjdk-6')
<kees> hv: sbeattie may already be looking into that issue.
<kees> micahg: I find this merge confusing. :) /me isn't used to bzr merges for packaging yet.
<hv> cjwatson: thanks. /me is embarrassed.  kees: thanks.
<micahg> kees: ok, I guess leave it for someone else, or I can walk you through it
<kees> micahg: no, no, I got it; it's just I need to pull a lot of packages to actually review it. it's much easier to review debian-to-ubuntu deltas rather than ubuntu-to-ubuntu deltas across a debian change
<micahg> kees: ah, ok
<micahg> kees: yeah, I actually found a change I made was actually made by Debian, so I dropped it from the changelog
 * kees nods
<micahg> kees: BTW, the debian branches are on LP, so you can diff against them as well
<kees> micahg: true, but I only trust source packages. :)
<micahg> kees: no, I meant the Debian source package import
<kees> wow, there are _extensive_ changes between debian and ubuntu. seb128: shouldn't you enumerate the changes when doing a merge of pidgin? besides just control and rules, there are _8_ added patches.
<seb128> kees, they were enumerated like 2 changelog entries bellow
<micahg> kees: I'm wondering how I missed those
 * micahg only saw one change
<kees> seb128: yeah, I see that now.
<seb128> kees, I did just fetch the new debian revision, apply that and added a "sync on debian" entry
<kees> micahg: this is why I don't trust bzr. :)
<seb128> either that rebasing
<seb128> easier
<micahg> kees: maybe I should redo that then
<kees> well, my opinion is to always enumerate the delta, but if that's not how seb128 does it, then I guess it's less of an issue here.
<kees> let me still look at what actually changed, one sec...
 * micahg guesses he shouldn't trust bzr either
<seb128> kees, that's how I do it usually but I feeled lazy and just wanted to backport one revision from debian without redoing the merge
<kees> seb128: see, there are changes between the last full resync list and current.
 * kees nods
<kees> last full changelog list was 1:2.7.3-1ubuntu1
 * micahg can do a full list :)
<kees> micahg: yeah, I'd prefer that. I'll keep review the actual delta here, but I'd like to see a full delta report in the changelog.
<kees> *reviewing
<seb128> kees, well I could have copied the summary in the current entry
<seb128> it's basically a merge with a new revision grabbed after and a changelog entry added for upload
<kees> seb128: right. but between 1:2.7.3-1ubuntu1 and current there were 7 real changes, and 3 resyncs without enumeration. it can be confusing to someone new to the package. *shrug*
<seb128> indeed, sorrya bout thÃ©at
<seb128> doh, "sorry about that" rather
<micahg> I just found some stuff never made it into our package :(, minor things like Vcs-Svn changed to Vcs-Git
<RoAkSoAx> is there anyone expert in distutils extra that might be ableto help me with an issue of updating a .desktop file?
 * micahg needs to file a bug against bzr for not showing this stuff
<bcurtiswx> i downgraded a package from the gnome3 PPA to natty (nautilus), but it still links to libgtk-3.0.so.0 => /usr/lib/libgtk-3.0.so.0 (0x00007fd03e47b000)
<bcurtiswx> how can I change that to be -2.0 ?
<kees> micahg: the actual contents of the merge look fine. once you're ready with a new changelog, I'm happy to upload.
<bcurtiswx> as far as packaging is concerned, a merge you would bzr merge-upstream, what do you do for a sync ?
<lifeless> mdz: ping
<micahg> kees: it seems we missed a lot of changes in our version, i'm going to try to pull in some of the changes that Debian made to the packaging, I'll check the changelog to make sure it's not something specific that we changed
<kees> micahg: cool, thanks
<mdz> lifeless, hi
<lifeless> mdz: I'm wondering what my next step should be with the discussion about package name substring matching in bug search
<lifeless> mdz: I'm presuming you saw my thread on u-d, and blog post on blog.l.n
<mdz> lifeless, I had seen your blog post but not the u-d thread
<mdz> and I didn't see the comments on your blog post
<mdz> so I know what you proposed but not what the response was
<lifeless> there was little response
<lifeless> one strongly in favour of the current behaviour
<lifeless> some technical 'how can we help make what you do now fast'
<lifeless> and a few 'make it faster -please'
<lifeless> the u-d thread - https://lists.ubuntu.com/archives/ubuntu-devel/2011-February/032381.html
<lifeless> mdz: based on the feedback I've had, I don't think there would be an outcry at us changing this, but I want to make sure that I haven't missed a community depending on it
<mdz> lifeless, in that case, I think all you can do if you want to be more cautious is to wait a while longer and publicize the question more widely
<lifeless> mdz: can you suggest a good forum for wider publication ?
<mdz> lifeless, you've already hit ubuntu-devel and planet, so I'd say identi.ca and twitter if you haven't already
<mdz> lifeless, but frankly, I think it would be reasonable to throw the switch and see what happens, so long as it's easy to back out
<lifeless> I'll send something out on those channels today
<mdz> AIUI you're doing more runtime feature switches these days to facilitate that sort of thing
<lifeless> yes, we can phase it in conservatively with the ability to toggle it off in a second
<lifeless> if we're not sure about a change
<kees> slangasek: hi, do you have a moment to look at https://code.launchpad.net/~mathieu-tl/ubuntu/natty/plymouth/lsb-release-version/+merge/45095 ? I think it's ready, but since you had reviewed it before, it might make sense for you to double-check it now?
<slangasek> kees: <cough> reload the page ;)
<kees> slangasek: /me sees no difference....
<slangasek> kees: Status: Merged
<slangasek> kees: I merged it not 5 minutes ago :)
<kees> oh! hah.
<kees> okay, I was looking for comments or your review status to change. ;)
<kees> excellent timing!
<jam> barry: are you still around?
<jam> some Q's about pychecker
<barry> jam: yep
<jam> barry: so, it looks like it was fairly recently converted to v3 format, and before that there *weren't* any debian/patches files
<jam> (as of Lucid at least, since 'apt-get source' gave me something without any debian/patches)
<barry> interesting
<barry> jam: does that make it harder or worse to use as an example?
<jam> barry: I'm trying to figure out how things are supposed to be done
<jam> I thought I sort of understood debian/patches, but getting something that doesn't have it is both good and bad
<jam> good to know that things like this exist
<jam> bad because we have to plan for how to handle them
<barry> jam: right.  it's considered bad form to add a patch system when there isn't one already, unless you're the debian maintainer
<barry> jam: in those cases, we edit the source directly, and the change gets included in a diff.gz file against the original tarball
<jam> barry: I always thought it was bad form to edit the source directly :)
<barry> jam: as did i, until i chastised for doing it the other way :)
<jam> barry: so why don't I see your name in the pychecker history?
<jam> ):
<jam> :)
<jam> silly async hands
<jam> barry: so my goal with this is to put together a (possibly fully manual) import of a package, that you could poke around in, and see what you think of
<jam> I'd like something that you actively use, if possible
<barry> jam: okay, let me find a better example
<barry> jam: i guess part of the problem is that the packages i maintain i usually am also the upstream, so i don't tend to use quilt much in them.  where i've interacted b/w quilt and bzr is in projects i've fixed bugs in, i.e. adding patches
<jam> barry: I personally don't care about quilt as much as how should the import look
<jam> however, I assume you also tend to just fix upstream?
<jam> or do you actually do fixes in patches?
<jam> cjwatson: are you around ? i realize the timezone is probably pretty bad for you right now
<ari-tczew> kees: I tried to encourage Debian maintainer to enable hardening in exim4 but he seems to be not interested :(
<SpamapS> kees: thanks for uploading that upstart fix. :)
<barry> jam: when i submit branches that fix bugs in ubuntu, i adapt to the package's existing patch system.  if it uses quilt, that's what i use, but it could be one of several different patch systems - or none at all.  i know that probably doesn't help much ;).  the biggest impedance mismatch is where i'm developing a fix in a branch that has a patchsys and i need to submit a new debian/patches file for review.
<barry> jam: quilt is a good enough example of that, and this page shows the pain:
<barry> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem
<kees> SpamapS: you bet; glad to have that all sorted out.
<barry> jam: so i think any package that has a set of quilt packages would be decent to start with because it would give a sense of how we *want* to deal with it
<kees> ari-tczew: that's too bad :(
<jam> barry: I'll read through that.
<jam> There are, in fact, several co-mingled issues
<jam> one is how to handle 'I want the current tip in a fashion I can easily hack on it'
<jam> another is "how do we want to represent the history"
<barry> indeed. ;)
<barry> jam: if there's a conflict between those two goals, the first is (i think) more important.  a source package's history is largely determined by debian/changelog rather than 'bzr log' if that makes sense
<barry> jam: i'm leaving early today, so let's talk again tomorrow
<lifeless> barry: the history has an impact on 'merge two branches
<jam> barry: what is the "quilt import...; quilt push; quilt pop" ? (Just trying to understand why the multiple steps)
<jam> that seem to conflict
<barry> lifeless: ah, not something the user cares much about, but the machinery cares a lot about
<lifeless> barry: they user cares a lot when merging from debian, or linaro from ubuntu. or linaro from debian
<kees> SpamapS: https://code.launchpad.net/~clint-fewbar/ubuntu/natty/mountall/fix-mounted-tmp/+merge/48681
<kees> SpamapS: doesn't "env MOUNTPOINT=/tmp" mean the /usr logic will never fire?
<barry> jam: 'man quilt' will answer a lot of questions there, but basically think of quilt as a version control system.  it manages a stack of patches.  that's important because sometimes a patch is applied upstream and you can get rid of it in debian/patches
<jam> barry: right, but you just imported a patch, and then push and pop it, which seems pretty strange, I guess you talk about it
<barry> lifeless: i guess ime, a diff is useful, but debian/changelog tells me more about the history than bzr log does
<barry> jam: right.  it *is* strange. :)
<jam> barry: also, isn't that to remove the change from the working tree, which isn't what you are supposed to still do?
<barry> jam: and i don't know if it's the best way to do it, but it's the only way i found that didn't result in huge gobs of unresolveable conflicts
<barry> jam: someone (james_w perhaps?) did recommend that the changes could live in both the source tree and in debian/patches, but i found that confusing
<jam> barry: I thought that was the point of v3 quilt
<lifeless> barry: by representing history, I think you and jam may mean different things
<jam> that it would be in a patch system, but also in the WT, so that you actually build/test against the final code
<SpamapS> kees: no that only sets a default value
<lifeless> barry: things like 'should patches be a patch file or a changed revision
<lifeless> barry: and those changes radically alter the sorts of merge conflicts you get
<lifeless> barry: I'm not talking about /bzr log/ output *t all*
<barry> jam: right, but most packagers *only* use quilt.  iow, it's there vcs for changing the package.  we essentially have two competing vcses on the same source tree
<jam> lifeless: right. and everyone I've talked about seems to have internalized things differently :)
<SpamapS> kees: that is so that if somebody runs 'start mounted-tmp' the don't torch all files in / .. might be worth nothing how important it is.
<SpamapS> s/nothing/noting/
 * SpamapS really should get a new keyboard the typos are getting worse.. :p
<kees> SpamapS: heh, okay, cool
<barry> jam, lifeless i *really* have to go now, so we'll pick this up again tomorrow.  one thing that may be helpful is to think about not what we have to do today, but what we eventually want it to look like.  in that regard, i don't ever want to deal with the quilt until i have to generate something for external consumption, and then for folks who aren't using udd (read: the debian maintainer)
<jam> barry: in my head, it is a "bzr export-loom-to-debian-patches" or something along those lines
<kees> SpamapS: should the "cd "${MOUNTPOINT}" gain a "|| exit 0" ?
<SpamapS> kees: I don't think so. The logic of the if's will exit 0 on the chance that /usr is mounted before /tmp (there won't be a /tmp/.delayed_mounted_tmp_clean) and this way we flag problems where /tmp isn't accessible.
<kees> SpamapS: what about the totally insane case of: system comes up with no /tmp directory, /usr gets mount, entire filesystem is wiped.
<SpamapS> kees: upstart scripts are guaranteed to run with set -e .. but I agree.. hggdh brought up that it is a bit scary that set -e is our only guard.. so maybe even || exit 1 is better.
<kees> cool
<SpamapS> want me to a) add a comment to the env statement, and b) add the || exit 1 and re-push ? Or do you just want to do that and upload?
<kees> SpamapS: I'll just add it and push/upload. easy fixes.
<SpamapS> kees: once again, thanks for the reviews and uploads.
 * SpamapS thinks there must be a UTF-8 character for "gratitude"
<kees> SpamapS: you bet! :) thanks for the fixes :)
<ari-tczew> kees: exim4 updated
<ari-tczew> guess your browse remember bug number ;-)
<ari-tczew> s/browse/web browser
<kees> ari-tczew: yup, thanks, I'll go re-check.
<ari-tczew> kees: when you have done exim4, would be nice to get this one https://code.launchpad.net/~bkbox/ubuntu/maverick/munin/fix-for-699967/+merge/48984
<amitk> bryceh: hey bryce, around?
<amitk> bryceh: I'm running latest natty with an nvidia GeForce 8400. Nouveau was giving several problems, so I decided to try the binary driver (nvidia-current). Now X doesn't start any more and uninstall the binary driver doesn't help either. Any suggestions?
<RAOF> amitk: Uuurgh.
<amitk> RAOF: i know, bad idea :-/
<RAOF> amitk: Installing the binary driver has probably uninstalled X.  nvidia-current doesn't support the X server we have in natty at the moment (and the dependencies are a little messed up), so the xserver declares a Breaks: on nvidia-current.
<amitk> RAOF: really?!!! /me checks
<RAOF> (Or, technically, on xserver-xorg-video-8, which nvidia-current Provides:)
<amitk> RAOF: you're right, apt-get install xorg is installing a lot of stuff
<amitk> RAOF: thanks, X is back :)
<RAOF> :)
<kees> coming out of hyperdrive now...
<kees> @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:
<amitk> RAOF: how well are the discrete ATI cards supported? I need something other than nouveau
<RAOF> amitk: If you've got something less new than a Radeon X6800 it should be fully supported.
<RAOF> (By the open drivers.  Again, no proprietary fglrx for Xserver 1.10 yet)
<ari-tczew> kees: FYI, it could be ubuntu3 for SRU
<ari-tczew> because natty is 3ubuntu2
<kees> ari-tczew: it _can_ be, but it should not be.
<ari-tczew> kees: strange
<kees> best to just stick to the common convention to avoid needing to consider collisions.
<ari-tczew> but no problem for me
<kees> for example, I can give you a case where this caused a problem:
<kees> maverick release, natty opened for development
<kees> some SRUs went through into maverick and were distro-copied to natty
<kees> so maverick and natty had the same versions
<kees> they were, say ubuntu2 then ubuntu3. then natty gets a "real" bump to ubuntu4.
<kees> on the next SRU to maverick, following the package convention, it also tried to do ubuntu4, but that collides with natty
<ari-tczew> kees: nope. maverick - 1ubuntu2, natty -3ubuntu2
<kees> ari-tczew: right, in this case it's not a problem. I'm saying that when reviewing patches and doing sponsorship, it's best to set a good example and follow the expected conventions on package versioning.
<ari-tczew> kees: ok understand.
<ari-tczew> ;]
<kees> :)
<achiang> kees: i've a question re: chromium-browser... v8 is in maverick-security (i think), but i don't see a .orig.tar.gz here --- http://ports.ubuntu.com/pool/universe/c/chromium-browser/
<kees> achiang: hm, looking
<kees> achiang: I think the orig would just be in the regular archive.
<achiang> kees: ah, interesting. thanks
<kees> achiang: should be findable on LP though: https://launchpad.net/ubuntu/+source/chromium-browser
<achiang> kees: actually, i don't see it here either -- http://archive.ubuntu.com/ubuntu/pool/universe/c/chromium-browser/
<achiang> kees: i guess we don't actually want v8 anywhere
<achiang> because it doesn't appear in LP either
<kees> achiang: yeah, looks to just be v9
<achiang> kees: thanks!
<kees> achiang: you should still be able to dig it out of https://launchpad.net/ubuntu/+source/chromium-browser/+publishinghistory
<achiang> kees: nope, the latest is what i want, so v9 is perfect
<kees> achiang: e.g. https://launchpad.net/ubuntu/maverick/+source/chromium-browser/8.0.552.237~r70801-0ubuntu0.10.10.1
<kees> achiang: okay, cool
<achiang> thanks again
<szymon_g> hi
<szymon_g> could anyone tell me what are default cflags for ubuntu 32bit 10.10/11.04 :?
<szymon_g> is it, despite its name (-386) still runable on that architecture /apart from performance issues etc/- thats theorotical question
<micahg> szymon_g: minimum arch for x86 is 686 in Ubuntu now
<szymon_g> micahg, is it the same for the current one and the next one, or was it changed somehow? have you got a link to documentation etc about that /i discuss that on one of forums, i need a 'hard proof'/ :?
<szymon_g> ah, thanx for answer btw (my manner :/)
 * micahg looks for the pertinent mail on ubuntu-devel
<micahg> szymon_g: https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/031020.html
<szymon_g> oh, great thanx micahg!
<micahg> szymon_g: you're welcome
<szymon_g> btw, if may i ask: why the name is still 386? if can be (well.. it is) a bit confusing...
<micahg> szymon_g: legacy, Debian's default is 486, but we just call the platform i386
 * szymon_g still doesn't understand why not to call it simply i686 ;)
<broder> szymon_g: it's mostly because the string "i386" is baked into a lot of places, and changing it would be a huge ordeal
<hallyn> is there a 'dh_installxyz' command to install /etc/default files?  I know debian/package.default will get handled, but the package ships with a /etc/default/xyz file in its base directory, I'm wondering how to best get that installed
<broder> hallyn: i think dh_installinit handles default files
<broder> but what's wrong with just using dh_install for that?
<hallyn> broder: just that the file ships in the package's base dir.  should i just copy it into debian/ in a pre-build step?
<broder> dh_install can pull from the root of the package
<hallyn> i don't want to copy it myself and riskit getting otu of sync
<hallyn> broder: that's what i was hoping.  so you say dh_installinit?  lemme go re-read that one
<broder> no, dh_install
<broder> there's no reason to treat the file specially. it's in one place, you want it in another place, that's what dh_install does
<hallyn> broder: ok.  i was afraid there might in fact be a reason to treat is specially
<hallyn> (namely, perms/ownership)
<hallyn> broder: i'll do that then, thanks!
<broder> perms and ownership are all handled by dh_fixperms anyway
<broder> dh_installinit doesn't do anything special to the default file it copies over
<highvoltage>  /win 26
<hallyn> and so the first place dh_install looks for the file is the package topdir?
* mbarnett changed the topic of #ubuntu-devel to: Launchpad down/read-only from 23:00 - 00:30 UTC for a code update || 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 Frien
#ubuntu-devel 2011-02-10
<bdrung> kees, SpamapS, slangasek: Please fix the debian revision of upstart with the next upload (bug #693630)
<ubottu> Launchpad bug 693630 in upstart (Ubuntu) "upstart uses wrong Debian revision" [Medium,New] https://launchpad.net/bugs/693630
<kees> bdrung: ah, yeah, will do.
* mbarnett 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:
<ohsix> anyone know offhand the apt-fu or aptitude meta query for listing packages installed manually
<pitti> Good morning
<cyphermox> pitti,  good evening ;)
<pitti> mtaylor: not right now, but please feel free to open a bug an subscribe me, and we discuss it there; sounds interesting
<pitti> cyphermox: I can't sleep any more :)
<cyphermox> pitti, I haven't gone to sleep yet ;)
<cyphermox> it
<cyphermox> it's still wednesday here :)
<broder> pitti (and kklimonda): re our python-gtk discussion from a bit ago, andersk pointed out to me earlier today that you can do "import sys; reload(sys); sys.setdefaultencoding('undefined')"  :)
<pitti> broder: hah, nice hack
<mtaylor> pitti: cool. I'm trying to find a _sensible_ way to integrate i18n into openstack stuff
<pitti> kees: please don't ask for testing -proposed packages; if you upload to -proposed, they need to be reviewed/accepted by ~ubuntu-sru first
<pitti> and our sru-accept.py script will then do the call for testing
<kees> pitti: oh! eek, sorry about that
<pitti> kees: no problem, I'm processing the queues now
<pitti> so it's not too much time in between
<pitti> but lucid-proposed had been locked for a while for 10.04.2 prep
<kees> pitti: yeah, sorry, I went from doing security-proposed -> -proposed bugs to normal -proposed bugs and got carried away.
<kees> right.
<pitti> kees: no problem; just mentioning it for next time
<pitti> thanks for the sponsoring!
<kees> you bet! thanks for looking through the queues.
 * kees heads to bed
<pitti> sleep well!
<didrocks> good morning
<didrocks> @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: didrocks
<dholbach> good morning
<didrocks> hey dholbach
<pitti> james_w: since I merged the blueprints API patch, the linaro WIs have skyrocketed (they apparently were miscounted before), and I now get a lot of cron spam for "[WARNING] milestone "4.4-2010.07-0" is unknown/invalid"
<pitti> james_w: do you actually need the linaro configuration on people.c.c. these days? you guys have your own instance now, don't you?
<dholbach> lu didrocks
 * dholbach hugs didrocks
 * didrocks hugs dholbach
<hyperair> is there a cross platform way of printing out '\n' in sh?
<hyperair> in dash, echo -n '\n' dumps a newline to screen
<hyperair> in other shells, you need -e for it to dump a newline
<hyperair> so dash requires '\\n' to print out a literal \n, but in other shells, that comes out as \\n
 * hyperair facepalms
<hyperair> like for example, busybox's ash
<RAOF> hyperair: /usr/bin/printf
<hyperair> RAOF: hmm interesting.
<hyperair> RAOF: thanks for the idea!
 * hyperair goes about patching haserl
<nigelb> persia: hi, around/
<nigelb> persia: would you be interested in giving a session at UDW about talking to upstreams and debian in particular?
<didrocks> mvo: in case you didn't notice, you have two waiting grammar typo fix in apt: https://code.launchpad.net/~evfool/apt/fix641673/+merge/48689 and https://code.launchpad.net/~evfool/apt/fix418552/+merge/48695
<mvo> thanks didrocks
<mvo> I noticed, but forgot already
 * mvo points to https://launchpad.net/~blatant-and-awkward
<didrocks> mvo: heh :)
<nigelb> mvo: lol, nice team ;)
<nigelb> cdbs: ping
<nigelb> cdbs: Want to talk about somethign packaging-ish at Ubuntu Developer Week? :)
<csurbhi1> mvo, ping
<mvo> hey csurbhi1
<csurbhi1> hey mvo!
<csurbhi1> i wanted to verify something
<csurbhi1> bug 693630
<ubottu> Launchpad bug 693630 in upstart (Ubuntu Natty) "upstart uses wrong Debian revision" [Medium,Invalid] https://launchpad.net/bugs/693630
<csurbhi1> i have marked that invalid.. because upstart is not based on any debian package..
<csurbhi1> but wanted to make sure that sounds right
<cdbs> nigelb: back
<cdbs> nigelb: no, my exams are starting from March 2nd
<cdbs> so I will be really busy
<cdbs> and can't pull an hour out of my routine
<mvo> csurbhi1: well, yes and no :) its correct, but debian is using a -X schema as well. so there is the risk of having two identical versions (includiing debian revisions) but with different content
<nigelb> cdbs: yeah, sorry.  daniel told me later that he already asked you.
<mvo> csurbhi1: so there is some value in still doing the -0ubuntu1 dance (or asking debian to do -1debian1)
<csurbhi1> ok
<csurbhi1> but would we ever take the debian package ?
<mvo> csurbhi1: given that for us the change is minimal and it avoids confusion I would be inclined to just use -0ubuntu1
<csurbhi1> to cause the confusion?
<csurbhi1> i mean would not Ubuntu's upstart be upstream for Debian now?
<csurbhi1> so that we dont take full patches from debian
<csurbhi1> no?
<csurbhi1> like the problem of collision will occur only in case of a merge sync?
<mvo> that is true, we will most likely not take debian package but do our own, still it feels wrong to have two versions with the same number (including distro revision) that hae different content. IMO either we or debian should adjust the version
<csurbhi1> merge request?
<csurbhi1> mvo, ack
<mvo> anytime people compare version numbers
<csurbhi1> thanks!
<csurbhi1> ok, i will update the bug once again then :) and update it with your comments
<mvo> yw, I think while technically its correct that we have -X for practical reasons we should adept
<mvo> (or ask debian nicely to do that)
<csurbhi1> one query
<csurbhi1> i still have
<csurbhi1> when we take debian's vanilla package
<csurbhi1> and have no patch to add on top of it
<csurbhi1> we do not have the -0ubuntuX scheme
<csurbhi1> right?
<mvo> csurbhi1: yeah, if we just sync it, we keep the version number from debian
<csurbhi1> i mean if its not a merge request?
<csurbhi1> ok
<mvo> (as the source is the same)
<csurbhi1> would debian be doing that with Ubuntu's upstart?
<csurbhi1> owing to which the version numbers are the same?
<mvo> csurbhi1: I think it would be a good idea if debian merges from ubuntu to have -1debian1 for example
<mvo> csurbhi1: but I don#t think there is a policy for this yet
<mvo> (in debina)
<csurbhi1> just being a devils advocate here... but in the case the source is the same, Ubuntu can then have the same version number right :)
<csurbhi1> but i get the gist of it..
<csurbhi1> i will update the bug.. thanks for the enlightenment
<janimo> what is the differnece between ubuntu.natty and platform.natty seeds?
 * janimo wishes LP branches made use of the optional description field
<mvo> csurbhi1: your welcome :) (sorry for the delay, was on the phone)
<csurbhi1> mvo, np
<cdbs> mvo: hi, do you intend to restrict the ability to review an app in s-c only for those who have installed it?
<cdbs> (similar to the way iOS App Store and Android Market do)
<mvo> cdbs: hello! iirc that is what the spec says, so yeah :)
<bankix> Hi.
<didrocks> session restart, brb
<chrisccoulson> who's going to take care of gjs in the archive?
<chrisccoulson> libmozjs is currently breaks ABI with every single point release....
<chrisccoulson> s/breaks/breaking/
<chrisccoulson> we dropped it for a reason
<didrocks> chrisccoulson: bigon will
<didrocks> chrisccoulson: I checked with him at fosdem and as he maintains it in debian and ubuntu, he'll follow the ABI breakage
<didrocks> chrisccoulson: btw, the reason on the drop was just "unused by default", the ABI breakage should have been mentionned
<chrisccoulson> right
<chrisccoulson> but it's still unused isn't it?
<didrocks> chrisccoulson: yeah, but people developping on ubuntu like the telepathy guys needs it for their dev
<didrocks> I think it's not an isolated case
<cjwatson> janimo: platform.natty => seeds common to all products; ubuntu.natty => seeds for Ubuntu desktop and server editions
<janimo> cjwatson, thanks.
<dholbach> who of you has started working on a small project that you want to introduce and get people interested in? we are going to have a "project lightning talks" in the last session of UDW: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions - feel free to sign up
<blackmoon105> is possible to report a bug for "ubuntu-wine" ppa package? i can only report a bug for official wine version...
<nigelb> PPA bugs aren't yet available
<nigelb> you'll have to contact the author
<blackmoon105> nigelb: ok, thank you!
<nigelb> blackmoon105: :)
<dholbach> fabbione, happy birthday! :)
<fabbione> dholbach: thanks man :)
<blackmoon105> hi, how can i be a official mantainer (not ppa) of a ubuntu package? so i can keep it update with the latest version..
<dholbach> blackmoon105, get a new versioned sponsored into Ubuntu (https://wiki.ubuntu.com/SponsorshipProcess), after you've worked with a few sponsors, apply for upload rights (https://wiki.ubuntu.com/UbuntuDevelopers)
<blackmoon105> dholbach: thanks, i read it
<didrocks> @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> didrocks, great work!
<didrocks> dholbach: thanks, hope that help the queue a little :)
<dholbach> good job! :)
<Daviey> JamesPage, Is mvel on your radar for a merge?  It's really out of date... we haven't merged since at least karmic by the looks of it; and it's a major version increase.
<Daviey> JamesPage, I don't mind having a stab of it.
<jfer> hi, i was wondering if there were plans to add MariaDB to the ubuntu repository?
<Daviey> JamesPage,  hmm.. seems it was never sync'd - it was a ubuntu native package which is now in Debian
<cdbs> mvo: ping
<mvo> pong cdbs
<Daviey> jfer, The logical step is for it to enter Debian and be sync'd across.. Inclusion in Debian is being tracked @ http://bugs.debian.org/565308
<cdbs> mvo: hi, https://code.launchpad.net/~bilalakhtar/software-center/write-review-installed-only/+merge/49206 read the two comments, what do you say about this? should a bug be filed? on what? ayatana-design?
<mvo> cdbs: I have a look now, many thanks
<jfer> ok thanks Daviey
<jfer> so it won't make it into natty then?
<Daviey> jfer, hmm.. looking at the progress of that i would say it's possible but unlikely.
<jfer> ok it seems that the conflict with MySQL is the main reason for the delay
<JamesPage> Daviey: OK so we currently have two mvel packages - one in main (mvel) and one in universe (mvel2)
<JamesPage> Daviey: mvel2 build-deps on Maven (not in main); we could potentially converge the packages but not without major MIR work for Maven-> main
<james_w> pitti, yeah, let's delete the linaro config from your instance. We do indeed have our own instance.
<Daviey> JamesPage, *sigh* :)
<james_w> pitti, let me know if that isn't enough and I'll propose a patch to handle whatever is left.
<pitti> james_w: thanks; I commented out the linaro teams from natty.cfg now
<Daviey> JamesPage, Sounds like something to revist next cycle
<JamesPage> Daviey: whats the requirement for it at this point in time?  I'm starting to see a number of packages in Debian switch from Ant to Maven which are already in main so its going to get worse....
<pitti> james_w: there are still the separate linaro reports, of course (http://people.canonical.com/~platform/workitems/linaro-multimedia-wg/all.html etc.)
<james_w> pitti, thanks
<Daviey> JamesPage, i just noticed there versions were significantly different... it doesn't gain us anything i don't think having a newer thing... we need to maintain the version in Lucid regardless, so lets pin
<JamesPage> Daviey: OK - I'm going to spec Maven -> Main for UDS-O so next cycle then (well maybe :-)
<Daviey> JamesPage, I don't think users have complained that it's an old version, and with the major new version in universe already.. seems we are currently in a  good position
<Daviey> JamesPage, You've been looking for more excuses to get Maven promoted to main, haven't you? :)
<JamesPage> Daviey: TBH it just means that we are having to maintain a larger Ubuntu delta over debian than we should be for some areas of the Java library
<JamesPage> Daviey: and yes I have :-)
<Daviey> heh
<mvo> thanks cdbs, branch looks fine
<cdbs> mvo: Did you read the comment by Aaron?
<cdbs> That ain't a bad idea
<mvo> cdbs: true
<cdbs> mvo: okay, if you find fit you may merge this branch for now, in the meantime, I will file a bug and look for mpt feedback
<cdbs> bug about asking the user to review before uninstalling
<mvo> cdbs: it appears the spec has it, its just a bit hidden
<cdbs> mvo: it does?
<mvo> """"This process begins when you activate the âReviewâ¦â button on an âInstalled Softwareâ item screen."""
<mvo> https://wiki.ubuntu.com/SoftwareCenter/RatingsAndReviews
<cdbs> mvo: I know that. I mean that the thing that the user should be prompted to review an app when uninstalling it, isn't in the spec
<mvo> cdbs: aha, indeed
<cdbs> mvo: just filed bug #716435
<ubottu> Launchpad bug 716435 in software-center (Ubuntu) "Prompt the user to review an app when uninstalling it" [Undecided,New] https://launchpad.net/bugs/716435
<cdbs> mvo: so, that branch may be fit to go in now, I will work on this bug when the design spec is having that
<cdbs> mvo: okay, I g2g now, bye!
 * cdbs /aways
<janimo> pitti, would jockey be a suitable component to handle some aspects of bootloader file updates on ARM? These are blobs which are packaged in Ubuntu, but need to be installed elsewhere not on /, such as copied to a vfat partition
<janimo> pitti, there is a spec that deals with allowing users to update their bootlaoders easily and safely at least on the supported ARM images which keep their bootloaders on SD card's first partition
<joaopinto> hello
* Topic unset by kenvandine on #ubuntu-devel
* kenvandine 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: kenvandine
<Laney> there's a bot to do that ;-)
<kenvandine> whoops
<joaopinto> is it known that Natty's grub sets an unusable text mode with certain gfx cards/displays ?
<kenvandine> @pilot in
<soren> Is there a trick to get rid of the invisible window in the upper left corner that prevents me from clicking on things in unity? I thought that had been fixed, but I'm seeing it now.
<cjwatson> joaopinto: https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
<cjwatson> joaopinto: https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard
<soren> Uh... Weird. Turned out it was a crashed gvim. xkill took care of it.
<joaopinto> cjwatson, the mail is not very clear in what related to the menu, it mentions transition, my issue is with the menu presentation, not with the transition itself
<seb128> soren, usual workaround is to restart compiz or smspillaz said to hide and show the desktop can workaround it as well
<cjwatson> joaopinto: the whiteboard has one entry on it which may be your problem
<cjwatson> "Corrupted video in GRUB"
<seb128> soren, i.e ctrl-alt-d twice
<joaopinto> ok, checking
<joaopinto> oh, ThinkPad, it's me :P
<soren> seb128: Ah, cool.
<soren> seb128: Thanks.
<seb128> soren, yw, btw smspillaz is working on that bug and said it will probably be fixed by end of the day
<seb128> let's see
<soren> \o/
<artfwo> seb128, don't you have a link to the bug by chance?
<seb128> bug #709461
<ubottu> Launchpad bug 709461 in compiz (Ubuntu Natty) "semi-random invisible window with x geometry on top layer possible, all viewport only (one ws though)" [High,In progress] https://launchpad.net/bugs/709461
<artfwo> thanks!
<micahg> kenvandine: can you look at bug 713492, I believe there might be a symbols issue, so I wasn't comfortable sponsoring
<ubottu> Launchpad bug 713492 in ccscript (Ubuntu) "Newer Version Available" [Wishlist,Confirmed] https://launchpad.net/bugs/713492
<kenvandine> micahg, sure
<micahg> kenvandine: thanks
<blackmoon-105> i've run "  apt-cache show freepops | grep ^Source: | sort -u | cut -d: -f2- " but it don' result nothing..
<persia> blackmoon-105, That happens when the source name is the same as the binary name.
<persia> You might find `apt-cache showsrc ...` useful
<blackmoon-105> persia: thanks
<blackmoon-105> persia: blank output also with 'showsrc'
<persia> If you put it through the same pipes, that's expected.
<blackmoon-105> persia: ok, i've found that i don't have the "Source:" entry.. and so greo don't find it..
<blackmoon-105> *greo --> grep
<persia> Right.  showsrc shows the source for Package, and lists binaries.  show shows the binary for Package, and sometimes lists source.
<Riddell> cjwatson: I split kubuntu-mobile into a separate seed collection, can you remind me the right way to make changes to ubuntu-cdimage and its bzr archive?
<cjwatson> Riddell: bzr co bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/cdimage/  on your laptop, make changes there, commit - then let me know
<blackmoon-105> persia: ok, thank you
<cjwatson> blackmoon-105: you might also like to install dctrl-tools and learn to use grep-dctrl, if you're going to be doing lots of this
<blackmoon-105> cjwatson: done, i do it
<cjwatson> blackmoon-105: e.g.:  apt-cache showsrc freepops | grep-dctrl -nsSource:Package ''
<cjwatson> (maybe sort -u in there too)
<blackmoon-105> cjwatson: good, i've got the desired output
<blackmoon-105> bzr log -l 1 lp:ubuntu/maverick/sysvinit | grep ^tags: | cut -d: -f2-  give me an "Permission denied (publickey)" eror, it's because i'm not the owner of repo?
<nigelb> kirkland: ping?
<kirkland> nigelb: pong
<nigelb> kirkland: hey, want to talk about one of your projects at projects lightning talk for UDW?
<nigelb> kirkland: We're trying to give 5 minutes per project to say what it does, how it can be used, and how you could use help :)
<nigelb> kirkland: (I personally was thinking of bikeshed hearing about bikeshed and the kind of cool stuff it has)
<kirkland> nigelb: sure
<cjwatson> blackmoon-105: no, you should be able to 'bzr log' any public branch
<kirkland> nigelb: i can talk about any of them
<nigelb> kirkland: great! I'll put you down for a session :)
<kirkland> nigelb: it's just 5 minutes, right?
<cjwatson> blackmoon-105: follow the "one-time setup tasks" listed in https://help.launchpad.net/Code/QuickStart#Push%20a%20Bazaar%20branch%20to%20your%20project
<nigelb> kirkland: yup 5 minutes
<kirkland> nigelb: sure, you bet
<cjwatson> (that goes on to talk about running 'bzr push' - I know you don't need to do that)
<blackmoon-105> cjwatson: ok, now i check
<kirkland> nigelb: i can introduce a handful of the most useful ones
<nigelb> kirkland: awesome, that's great :)
<kirkland> nigelb: what's the date?
<kirkland> nigelb: and time?
<nigelb> kirkland: friday 4th march at 20:00
<kirkland> nigelb: hmm, okay
<kirkland> nigelb: that might be tough
<kirkland> nigelb: is that UTC?
<nigelb> kirkland: yup UTC
<kirkland> nigelb: okay, worst worst worst case, can I type up a script of what I would say, email it to you, and you paste it on my behalf, in case I can't make it?
<nigelb> kirkland: worst case, yes, I can do that for you :)
<kirkland> nigelb: thanks
<nigelb> kirkland: thank you for joining the party :D
<kirkland> nigelb: i'm going to be traveling that day, which is my only concern
<kirkland> nigelb: but i'm happy to help :-)
<nigelb> kirkland: :-)
<kklimonda> hmm.. how to check what is sending out a lot of data?
<kklimonda> who, u1
<joaopinto> cjwatson, about the "Corrupted videon in GRUB" on thinkpads, is there some something I can do to to help, or you have enough triage already ?
<ev> is there not an ICS or google calendar URL for the release schedule anymore?
<micahg> kenvandine: so the warning of the lack of a symbols file wasn't relevant to the ccscript update?
<kenvandine> micahg, i don't think so, but i am suggesting they add a symbols file in the future, currently no worse than before
<micahg> kenvandine: ah, ok
<Riddell> cjwatson: cdimage committed
<barry> jam: very interesting.  y'know the udd page on working with a patch system?  well, i am hacking on numpy and i did not need the final quilt push/quilt pop this time.  in fact, it caused some recoverable problems.
<jam> barry: so if you had *not* done the push/pop you would have been ok?
<barry> jam: in this case, yes
<barry> it was *definitely* needed the last time i hacked on a quilt3 package thoug, so really i have nfc ;)
<jam> so *my* understanding of V3 quilt, is that the changes are supposed to be in the working tree (pushed?)
<barry> jam: i think that's the effect of what i'm left with.  i'm about to push the branch so you can take a look
<cjwatson> push/pop should just try to apply the patch and then back it out again.  it would catch corrupt-patch kinds of problems.
<jam> versus pre v3 packaging, where the patches were supposed to only be in debian and not in the wt
<jam> barry: were was the actual failure? in the upload?
<cjwatson> one of the fundamental ideas of 3.0 (quilt) packaging is that when you do dpkg-source -x you should get the patches applied, rather than relying on debian/rules to do it for you
<cjwatson> what you think the working tree representation should be depends on whether you think the wt should be basically equivalent to dpkg-source -x
<cjwatson> my take is that it should be but apparently this isn't universal
<barry> cjwatson, jam: when i do the quilt push, i get patch hunk failures.  presumably because it is trying to re-apply the patch to an already patched source tree.  which makes sense, but doesn't explain why i had to do it before
<cjwatson> barry: so the patch really ought to be pushed but quilt just doesn't know it?  in that case, http://people.canonical.com/~cjwatson/dpkg-quilt-setup
<cjwatson> barry: and see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204
<jam> cjwatson: well, as I don't know anything about dpkg-source -x ... :)
<cjwatson> jam: the one and only canonical way to unpack a Debian-format source package
<jam> cjwatson: except all of the other things above it that may do something differently? as I've never run that command, but have run "apt-get source" many times
<cjwatson> jam: apt-get source calls dpkg-source -x .
<cjwatson> I don't know of any software in the archive that doesn't use dpkg-source -x to unpack source packages
<cjwatson> and all that apt-get source does in addition is to deal with acquiring the source package
<cjwatson> it doesn't do any extra tree mangling
<jam> cjwatson: good to know
<cjwatson> I suspect barry's problem is an instance of the general problem of .pc getting out of sync with the base of the patch stack; which is something udd could (theoretically ...) help with
<barry> cjwatson: what i think is happening is this: the source includes the fix because that's where i hacked.  then the 'quilt import' does the right thing, and all you need is to bzr add the new debian/patches file and commit.
<jam> barry: the other question, how do you *tell* quilt that the patch is already implied?
<jam> is there something you should be running other than "import"?
<cjwatson> jam: see above, dpkg-quilt-setup
<cjwatson> but that's not official or anything
<cjwatson> let me finish my disquisition on .pc and then it may be clear :-)
<cjwatson> the files under .pc/PATCH, for each PATCH in the series, are copies of the clean state of each file that's part of PATCH before PATCH was applied
<jam> cjwatson: so your script backs out all current patches, and then patches back from the beginning
<jam> I'm pretty sure barry just wants to add one at the end
<jam> with the current diff content
<cjwatson> let me finish
<cjwatson> please
<cjwatson> it will be easier :)
<jam> k
<cjwatson> when you do something like an upstream merge, that conceptually changes the base state under the patches in your queue
<barry> cjwatson: that's plausible.  if the package importer somehow messed up the .pc directory (which is under vcs), then it's possible the previous package i sworked on required that becuase it was out of sync, but numpy does not because it is in sync
<cjwatson> I'm mangling terms a bit but hopefully YKWIM
<cjwatson> .pc has to be kept in sync with the unpatched states of files or else quilt will get confused and all sorts of things will go disastrously wrong
<cjwatson> dpkg-quilt-setup is a brute-force "assuming that all the patches are valid, get everything back in sync with a big hammer"
<jam> cjwatson: there are 2 things at play, I think your problem is indeed a real one, but not what barry is hitting.
<cjwatson> however it's mostly useful when you're checking out a tree that doesn't have .pc in it (because checking in .pc tends to produce large numbers of confusing diffs when you commit)
<jam> barry's is "I just did some hacking, add the new changes to the quilt"
<cjwatson> jam: if he's getting a 'quilt push' failure, it must mean that his series and the quilt state under .pc are out of sync
<cjwatson> there's no other way for that to happen
<jam> cjwatson: he just did an import, would that put it out of state?
<jam> or is quilt supposed to see that the patch is already applied
<jam> and just ignore the push?
<cjwatson>        import [-p num] [-R] [-P patch] [-f] [-d {o|a|n}] patchfile ...
<cjwatson>            Import external patches.  The patches will be inserted following the current top patch, and must be pushed after import to apply them.
<jam> right, they are *already* applied
<jam> he just used "bzr diff -rlast_state | quilt import"
<cjwatson> oh yeesh
<jam> he could then do "bzr revert -r last_start; quilt push"
<cjwatson> redesign time :)
<barry> jam: exactly right
<cjwatson> I wouldn't do it that way
<cjwatson> I'm trying to think of how I would do it
<barry> cjwatson: here are the current instructions: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem
<cjwatson> actually, frankly, I just do it all in quilt to start with and it is much easier, but I'm assuming that you have sort of ideological reasons not to do that
<barry> cjwatson: hacking the source until you're happy and then diffing to an import is so tempting, convenient, and natural
<cjwatson> you could hack the source inside a 'quilt shell'
 * persia notes that the expected final state of the source package differs between Format: 1.0 packages using quilt, and Format: 3.0 (quilt) packages, which may affect the UDD documentation.
<cjwatson> a cleaner approach might be to revert *first* and then import
<cjwatson> then you will get a clean push
<cjwatson> since import is intended for importing an external patch that isn't applied to your tree yet
<cjwatson> if you follow that then you'll get minimal impedance mismatch
<cjwatson> (I actually use fold instead of import since I find that model slightly less confusing, but whatever)
<jam> cjwatson: what is fold?
<jam> barry is trying to document the way to do some of this
<jam> it would be good to update that part
<barry> persia: ack.  i would be ecstatic if we could start with figuring out the right way to do quilt3 ;)
<cjwatson> import creates a new patch and applies stuff in one go
<cjwatson> fold applies stuff to the patch that's on the top of the stack
<jam> cjwatson: so you would create a new patch on the stack, but empty
<jam> then fold the current changes into it?
<cjwatson> I personally find it less confusing to decompose those two operations, so I do 'quilt new name-of-patch.patch' and then 'quilt fold -p1 <external-patch'
<cjwatson> then 'quilt refresh', and now my tree is in sync with the patch applied
<cjwatson> and I can go fill in DEP-3 headers
<barry> cjwatson: right.  last time i used fold though, it gave me unresolvable conflicts
<cjwatson> that would be a "using it in the wrong context" problem :)
<barry> :)
<cjwatson> (I'm not at all arguing that this doesn't need some kind of wrapping up)
<cjwatson> but fold if used correctly doesn't produce conflicts - I use it all the time
<jam> cjwatson: I think some sort of "bzr export-to-quilt -rX..Y patch-name" is probably what we want
<cjwatson> I agree
<jam> but I have to actually understand quilt before I could write something like that
<barry> jam: +1
<jam> cjwatson: also, in my ideal udd scenario, the patches would all be in a loom that we can merge properly, and then we only export the loom to a quilt as a "and let debian see this too"
<cjwatson> sure, with the proviso that the headers in patch files are actually useful and need to be editable
<jam> so while I want tools to make it integrate nicely, I also don't want to spend a lot of time getting to where we want to be
<jam> cjwatson: also something that I need either to be documented or internalized. What is in there, and what belongs in there?
<cjwatson> http://dep.debian.net/deps/dep3/
<cjwatson> it can reasonably be considered as "description of this thread in the loom"
<persia> Some of that can probably be sensibly defaulted from the metainformation bzr already has.
<cjwatson> not all of it
<jam> persia: the problem is being a simple summary
<jam> we could probably populate one by guessing
<cjwatson> and TBH I think trying to do that would be a distraction
<jam> but ultimately it is like debian/changelog
<jam> people want to summarize what is 20-some odd commits into a simple statement
<jam> and mutate that in the future as clarifications arise
<cjwatson> right, exactly
<barry> note that you do have the commit message
<cjwatson> the commit message really isn't enough
<cjwatson> have a look at openssh
<jam> barry: the problem is that you have 20 commit messages
<jam> and none are a summary
<cjwatson> lots of those patches are long-lived
<cjwatson> and go through multiple commits on merges, emendations, etc.
<barry> yeah, i suppose so
<jam> a final merge-commit *could* be a summary, but I'm not sure how you want to rollup that over time.
<barry> export-to-quilt could take a -m
<cjwatson> you don't want it to be something you just type in at export time
<cjwatson> the summaries include things like justifications for why the patch is carried despite not being upstream
<persia> Manual editing of the DEP-3 header isn't that bad, and it's not worth fussing about that yet.
<jam> barry: the issue is "convert-loom-to-quilt" needs to track all the -m's you've supplied over time.
<cjwatson> this is genuinely long-lived data
<jam> persia: sure. but in a "we don't want to have debian/patches or .pc until we are finally done" determining where to put it is important
<barry> persia: you're right.  my only issue is that it's another step that you have to remember, rather than the tools helping you remember ;)
<jam> we don't want debian/patches because they are mostly redundant with the wt state
<cjwatson> frex, http://patch-tracker.debian.org/patch/series/view/openssh/1:5.6p1-2/gssapi.patch
<jam> except for stuff like dep3
<persia> jam, You'll often start with debian/patches though.
<jam> persia: ideally in a fully udd world (which is what this channel is about), we'd get away from them
<jam> but yes, at some point that needs to be imported
<jam> and at some point exported
<cjwatson> wait, this channel is #ubuntu-devel, not #udd-devel :-)
<jam> so the intermediate form needs to have a way to track it
<jam> cjwatson: ah, I'm in the wrong one :)
<jam> :)
<persia> "this channel"?  I'm not sure about that.  In a fully-UDD world, we'd want a different implementation of Format 3.0 (bzr), and some source-format conversion tools.
<cjwatson> this channel has to deal with interaction with Debian, and thus isn't going to get away from debian/patches/
<barry> from __future__ import udd_dev as ubuntu_dev
<jam> cjwatson: I just looked at the channel topic, is dapper still supported?
<cjwatson> yes
<cjwatson> it goes out of server support in June
<jam> I was curious about that, and thought it had happened earlier. I guess that was desktop support
<barry> well, the good news is that i think i have a decent workaround for bug 664276 if i can express it correctly ;)
<ubottu> Launchpad bug 664276 in python-numpy (Ubuntu Natty) "python-numpy doc related build failure" [High,In progress] https://launchpad.net/bugs/664276
<cjwatson> desktop support ended in June 2009, yes
<jam> barry:  now is that numb-pie or numpy like lumpy :)
<barry> jam: depends on who you ask.  yooboontoo or ewboontoo?  lynn-uhx or lie-nux?  tomato or ... :)
<jam> tomato
<jam> sure
<jam> I've always said numb-pie. I only just now saw it as lumpy
<mok0> jam, I've always said "nubm-pie" but I will now start saying "numpi" :-)
<barry> anyway, cjwatson, jam, persia thanks for the good discussion.  if you have insight into how you think this *should* work, please do post to the udd list.  i've mostly just documented what kindof-sortof-doesmostly-work
<barry> i've always said numb-pie too, but in a kind of homer simpson "mmm! floor-pie" voice
<jam> barry: with a little drool after it. sounds good
<barry> :)
<mok0> barry:  we should all start saying "numb-bee" in an Abu-kind of way ;-)
<barry> mok0: :)
<barry> cjwatson, persia: in dep3, should <Vendor> in Bug-<Vendor> be Launchpad or Ubuntu?
<cjwatson> Ubuntu
<barry> cjwatson: thanks
<cjwatson> well, bugs.launchpad.net/ubuntu is Ubuntu
<cjwatson> bugs.launchpad.net/<upstream> is probably just Bug:
<barry> cjwatson: nod
<persia> And as Launchpad develops greater support for more distributions, the answer gets more complex
<ari-tczew> Bug: https://launchpad.net/bugs/XXXXXX
<ari-tczew> shorter ;-)
<persia> That's not actually helpful in this context, as it doesn't embed the string to use for Vendor
<barry> ari-tczew: Bug-Ubuntu: though, right?
<ari-tczew> barry: if launchpad is not bug tracker for upstream, right
<cjwatson> ari-tczew: sure, I just meant what the canonical target for the redirection was
<cjwatson> rather than the value of the field
<jam> ari-tczew: http://pad.lv/XXXX even shorter
<ari-tczew> jam: quite unnatural
<persia> jam, Yes, but not as helpful, as it doesn't identify the source in a way easily understood by as many folk, meaning that it's trickier to integrate into other tools.
<jam> persia: I wasn't saying you should put it into official history, just saying it is a nice shorthand to get to any lp bug
<persia> Oh, sure.  I use http://deb.at/L#### myself, just because I find the variety of deb.at redirects helpful.
<cjwatson> Riddell: deployed
<barry> ari-tczew: right.  in this case, it's a purely ubuntu bug
<kenvandine> @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:
<chrisccoulson> does anyone know why all the armel builders are offline?
<ogra> chrisccoulson, lamont i suppose
<ogra> (he owns them)
<chrisccoulson> thanks
<lamont> chrisccoulson: the switch they're behind had some work done on it, and then I got back from lunch...
<chrisccoulson> lamont, cool, thanks
<mvo> cjwatson: btrfs alternate install works like a charm!
<mvo> (just fyi)
<cjwatson> mvo: yay
<bankix> Good morning.
<bankix> I need some help building my own kernel package for ubuntu.
<bankix> I need a patch within my kernel and would build a new package with usual package name.
<bankix> E.g. linux-image-2.6.32-28-ctbankix1
<achiang> bankix: #ubuntu-kernel might be better for your question
<bankix> Ah, good point, thanks.
#ubuntu-devel 2011-02-11
<killown> help me understand why flash was updated for 10.2 on official ubuntu repositories? it's very very bug, alot annoying bugs
<persia> killown, we only ship an installer, not flash directly.  That said, the answer is in the changelog: looks like a security update fixing all sorts of outstanding CVEs.
<killown> any browser is crashing easily with 10.2
<micahg> killown: it's been working fine for me
<blackmoon-105> i've create a new project on launchpad
<blackmoon-105> the source is already in the universe repo of ubuntu
<blackmoon-105> i've set the series in my project
<blackmoon-105> but now i don't know how set it
<blackmoon-105> no one?
<RAOF> Set what?
<blackmoon-105> RAOF: Code for this series
<blackmoon-105> a message say that i haven't yet told Launchpad where your source code is
<RAOF> Hm.  I'm not sure; I've never tried doing that.
<RAOF> So it's not *terribly* important if you don't, either :)
<persia> You might ask in #launchpad: they tend to be a bit better about advice on using LP for projects
<blackmoon-105> persia: ok, thank you
<broder> what are the practical implications of the beta 2 vs. rc swap? is it just that we'll be rolling a thing-that-looks-like-a-pre-release a week sooner?
<persia> broder, Also, because we'll be in beta2 soft-freeze from probably Tuesday before Final Freeze (hard), it reduces the time available for the last-minute fix that isn't OMG-kittens by a couple days.
<poolie> asac, hi?
<didrocks> good morning
<dholbach> good morning
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 09:00-10:30 UTC for a code update | 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
<pitti> Good morning
<poolie> hi pitti
<al-maisan> Hello, upgraded to the 2.6.38-3.30 kernel this morning and laptop (thinkpad t410) froze twice on resume from suspend (nothing in /var/log/syslog) .. is this a known issue?
<al-maisan> FWIW the 2.6.38-2.29 kernel does not exhibit this problem
<bryceh> al-maisan, probably you should be on #ubuntu-kernel...
<al-maisan> bryceh: thanks for the pointer
 * al-maisan relocates
<pitti> ara: so the plan is to roll the (supposedly) final 10.04.2 CDs today, right?
<pitti> cjwatson: ^
<pitti> ara: dpm and I are currently testing some more langpacks, then I'll move the tested ones to lucid-updates, and we'll do the final rebuild, so that they will be available in ~ 4 hours; does that sound ok?
<pitti> cjwatson: FTR, disabling lucid cron jobs now
<dpm> pitti, ack. Let me see if I can test the Spanish one as well, as discussed
<pitti> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<pitti> o_O
<pitti> is that just me?
<pitti> ah, LP maintenance
<didrocks> yeah, not only you pitti :)
<ara> pitti, we are still testing the latest laptops, but so far it goes well. I guess we will need to respin in case we find anything in the latest laptops, but even the ones that are not 100% done, we have already run some tests on them, so I would be surprise to find anything
<pitti> ara: yeah, I don't expect any breakages either
<pitti> ara: but in last meeting we said that we should have finals on Friday
<pitti> so I wanted to coordinate with you whether "in ~ 4 hours" is enough
<ara> pitti, sure thing
<poolie> pitti, didrocks, sorry
<poolie> this time for sure
<poolie> http://blog.launchpad.net/general/launchpad-read-only-09-00-utc-11th-february-2011
<asac> poolie: ?
<janimo> mvo, hi I have a question related to package availability notifications, maybe you know what the best choice is. For arm images we want to notify the user when a new bootloader package is available. Can this be done using currently available components withoiut having that package previously installed?
<janimo> mvo, as we do not currently install the bootloader packages in the image, they are only on a separate boot partition written at image creation
<mvo> janimo: hello, could you have a meta-package that points to the right package that you then upgrade? like linux-image -> linux-image-$version ?
<mvo> janimo: or a empty "bootloader" package that you can later (if needed) can fill with life
<janimo> mvo, we have about 8 binary packages, (2 sources * 4 arm falvours)
<janimo> mvo, do we need to have soemthing installed to be able to check ?
<janimo> I guess that is what we need to do, maybe have all these preinsatlled
<janimo> and be notified when they are new
<mvo> janimo: it seems like the best choice to make it a package (even if initially empty) as it will seamlessly integrate with all our tools
<janimo> I was told jockey could help with this situation but no further details
<janimo> mvo, I'll check how linux image does it if that is a solution
<mvo> janimo: right, I guess that would work, but I don't really see the benefits
<janimo> mvo,  I cannot judge either way. The use case is, when we have a new bootloader ready, niotify the user so they can install if they want to. So optional
<janimo> An otion is have all these packages preinstalle,d and when they update have a dpkg hok notify the user that it can flash it if they want
<mvo> janimo: what is the benefit for the user (just out of curiosity)
<mvo> janimo: but yeah, my feeling is it should just be a package
<janimo> mvo, the whole use case you mean? Sometime the bootloader has a bug which prevents some hw feature being enabled
<janimo> so sometimes they can be instructed to flash a new one if they really want that feature - usually nothing serious but nice to have
<janimo> I don;t know any examples as I wasn;t around in 10.10 but something like not setting up some voltage, and the kernel not being able to set it by itsel
<janimo> mvo, if it is a package, how does a post-install  hook notify the user (either in the notification area, or especially in headless at the next login)?
<mvo> janimo: not sure I understand, why would the user need to be notified post-upgrade? is there something he/she needs to do?
<janimo> mvo, yes, these flashings of bootloader would be optional. apt only installs the files on the filesystem, but in order for them to be used at boot they need to be specifically put by another tool into a boot partiotion which is usually not mounted
<janimo> so the files formthe package are only needed to have the blobs ready for the flashing tool
<janimo> and being a potentialy risky operation it was decided it should not happen automatically
<janimo> but the user would use a command line tool to do it
<mvo> janimo: aha, now I get the full picture
<janimo> so on login the user would see, new version of U-boot available, you may want to flash it to the boot partition using tool-xxx
<janimo> mvo, sorry for not explkaining it better in the first place
<janimo> mvo https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
<janimo> here's a rationale
<mvo> janimo: check https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging#Interactive%20upgrade%20hooks
<mvo> janimo: or https://wiki.ubuntu.com/InteractiveUpgradeHooks
<janimo> mvo, thank you for the links and the advice
<mvo> janimo: the UI is not that great, the longer term goal is to make this much more plugable and flexible, but that relies on some of the cool new upstart session support
<janimo> mvo, if it notifies and works in console mode it is fine for us too
<mvo> oh, console mode?
<janimo> mvo, we wil have headless images as well
<janimo> I was told the kernel install hooks at least print out some message on first login if some action is required
<janimo> but I had not seen that in action yet
<mvo> janimo: in this case its probably best to hook into update-motd
<janimo> mvo, I am looking at that now, it says it is superceded by pam-motd, I'll ask in the server team maybe they have such scenarios more often
<janimo> thanks for the pointers
<mvo> yw
<gerth> I experienced several problems with mawk 1.3.3 in Ubuntu 10.10
<gerth> I found a site with a new maintained version: http://invisible-island.net/mawk/
<gerth> This version solves all problems I had with mawk
<gerth> gawk and mawk now to the same
<hyperair> gerth: please report the bugs on bugs.launchpad.net/ubuntu/+source/mawk
<gerth> OK
<hyperair> thanks
<persia> janimo, Do be careful: changing the bootloader is the easiest way to brick a device: if the old bootloader is configurable, and you can load a new kernel, this is almost certainly safer.  This is all the more true for devices that do not have a separate preboot environment from bootloader.
<cjwatson> pitti: right, that's what I was expecting ... do you want me to take care of builds?
<pitti> cjwatson: if you want to, sure; but I need to copy the langpacks to -updates first and get them published
<pitti> LP is back up now, doing that now
<pitti> oh noes
<pitti> 2011-02-11 10:21:18 ERROR   Unhandled exception
<pitti>  -> http://launchpadlibrarian.net/64023385/3fXOMNPsLdTZdUGxZ1qA5uyCv1P.txt (FATAL:  Ident authentication failed for user "archivepublisher"
<pitti> FATAL:  Ident authentication failed for user "archivepublisher"
<pitti> looks like some problem with postgresql?
<pitti> StevenK, lifeless: ^ do you know who we can ask about this?
<pitti> (copy-package.py failure)
<StevenK> Awesome. That's fallout from the rollout.
<StevenK> lifeless, wgrant: Pls fix, I'm on holidays
<lifeless> pitti: see internal IRC
<lifeless> for less zomg things, contact any dev in #launchpad
<lifeless> pitti: see francis email about the reorg for full details
* mthaddon 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:
<gerth> bug report mawk: https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/716920
<ubottu> Ubuntu bug 716920 in mawk (Ubuntu) ""mawk -F '\0' '{print $1}'" doesn't give the expected result" [Undecided,New]
<persia> #ubuntu-bugs is likely a better place to coordinate bug reports
<pitti> cjwatson: cocoplum is happy again, and I copied the tested lucid langpack updates now
<cjwatson> Riddell: kubuntu-mobile: you need to propose a Launchpad change to cronscripts/publishing/cron.germinate that adds kubuntu-mobile to the 'for distro in' list
<cjwatson> since the task doesn't exist
<cjwatson> pitti: OK, so we should be good to start builds after the next publisher run?
<pitti> cjwatson: yes, from my side
<janimo> persia, I try to be as careful as I can given that the goal _is_ to change the bootloader :)
<pitti> cjwatson: but let's verify madison after that, just be sure (after the recent db trouble)
<persia> janimo, well, depends.  Make sure the user is already running a packaged bootloader beforehand.  If the user is running the vendor bootloader, they may prefer it that way.
<janimo> persia, the update is not automatic, so the user will run the update if they think it is wise
<persia> That seems safer.  I just worry: it's akin to a BIOS update, which many folk happily never do for the lifetime of their device.
<janimo> persia, sure, I hope they won't have to do it too often on our images as well.
<janimo> persia, honestly I think this spec is a bit silly and contrived, but I was not at the UDS so I may misjudge how useful it is overall
<persia> Why would they have to do it ever?  I can imagine wanting to do it, but I don't see when it would be a must, once the kernel is loaded.  It's not like there's data stores used (e.g. dmidecode)
<Riddell> cjwatson: ok, how do I do that, bug on soyuz?
<janimo> persia, there were bugs during maverick which only an x-loader update could cure
<janimo> the kernel not being up to the task
<janimo> low level twiddling probably
<persia> Sure, but that was for a pre-retail device.  Anyway, if it's a spec, worth implementing.  Just be careful.
<janimo> persia, there are going to be other pre retails devices further down I guess, so having the possibility is useful.
<persia> janimo, Absolutely.  I just worry about the post-retail case: I don't want you to brick my handheld just because it needs some special tweak in the bootloader :)
<janimo> persia, I hope we'll be wise enough not to put new updates via SRU unless absolutely useful. And this only targets SD card/OMAP, so it is a very soft kind of bricking
<janimo> nothing that someone who uses this cmdline tool cannot fix with a littel IRC help
<persia> janimo, Except if I use a blaze, which uses a hardwired (non-removable) eMMC, rather than SD.
<janimo> not actual firmware update like x86 BIOSes
<cjwatson> Riddell: bug on launchpad, and it's probably quickest if you attach a branch
<persia> Anyway -> -arm
<cjwatson> Riddell: I'm updating tasksel
<janimo> persia, right now I put beagle,igep and panda in the handled list. We'll see if others will be added, but it is explicit
<persia> Ah, that's being careful :)
<Riddell> cjwatson: a branch of what?  soyuz?
<cjwatson> Riddell: launchpad, it's all one piece
<cjwatson> Riddell: oh, if you don't already know how, I'll do it
<Riddell> cjwatson: I'd be interested to learn though
<cjwatson> pitti: so which packages should we verify?  language-pack-de is at 1:10.04+20110204
<pitti> correct, and language-pack-fi at 1:10.04+20110204.1 (manual update)
<pitti> cjwatson: so, all green from my side
<cjwatson> ok, I'll just do a manual sync to check that antimony's mirror will pull the right things
<cjwatson> pitti: building
<ScottK> barry: Nice job on the numpy doc fix.
<soren> Is it just me, or does mountall not handle SIGPIPE *at all*?
<cjwatson> yow
<cjwatson> Riddell: is it known that you can't do a Kubuntu install with 512MB of RAM at the moment
<cjwatson> ?
<cjwatson> well, at least not in debug mode ...
<cjwatson> maybe it'll work better if I use the debug-ubiquity boot parameter rather than starting a desktop first
<cjwatson> oh, sod it, I'll just bump the memory for now
<Riddell> cjwatson: I don't think I've tried
<cjwatson> I switched to -m 768, I just habitually use -m 512
<Riddell> cjwatson: does bug 716311 seem like it would be caused by bug 680328 ?  if so should I backport the three patches to packagekit?
<ubottu> Launchpad bug 716311 in flashplugin-nonfree (Ubuntu) "flash not installed" [Undecided,Incomplete] https://launchpad.net/bugs/716311
<ubottu> Launchpad bug 680328 in qapt (Ubuntu Natty) "Many postinst scripts fail using either PackageKit, or QApt" [High,Fix released] https://launchpad.net/bugs/680328
<cjwatson> Riddell: um - the fixes were ported *from* packagekit to qapt
<cjwatson> Riddell: oh, do you mean to older releases?
<cjwatson> Riddell: yes, I think we probably ought to backport those to packagekit, qapt, and possibly aptdaemon (though I think it's different there)
<Riddell> cjwatson: ok I'll take a look at that
<cjwatson> great, thanks
<soren> cjwatson: You've touched mountall before. I can't seem to find a bzr branch for it? Any hints?
<cjwatson> lp:ubuntu/mountall
<soren> Ah.
<soren> cjwatson: Ta.
<soren> cjwatson: Would you mind reviewing a mountall patch for me? It's not very big.
<soren> https://code.launchpad.net/~soren/ubuntu/natty/mountall/sigpipe-handler
<cjwatson> soren: a bit deep in yak-shaving at the moment - could you mark me as the reviewer on a MP?
<soren> cjwatson: Will do. I wasn
<soren> t sure who would be the reviewer by default.
<bdrung> tumbleweed: u-d-t build failure: http://launchpadlibrarian.net/64035083/buildlog_ubuntu-natty-i386.ubuntu-dev-tools_0.116~daily%2Bbzr1012~natty1_FAILEDTOBUILD.txt.gz
<soren> cjwatson: MP filed with you as the reviewer. Thanks. If you don't get to it today, I might bug someone else to review it.
<tumbleweed> bdrung: I can look at fixing that in the morning
<kirkland> @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: kirkland
<kirkland> hold on to your butts, ladies and gentlemen...today's patch pilot has arrived  :-)
 * pitti closes his seat belt
<pitti> go, Dustin, go!
<ogra> cjwatson, any idea why http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/ubuntu-netbook/ doesnt get updates anymore ? i see current/, latest/ and 20101119/ (?!?) having a fresh timestamp but no logs
<cjwatson> ogra: isn't that just for the i386 netbook image, which is no longer being built?
<ogra> oh, might be
<GunnarHj> cjwatson: Hi Colin, considering your comments at https://launchpad.net/bugs/666565, it would be great if you could spare a minute or two to act on the comment I posted on Feb 3.
<ubottu> Ubuntu bug 666565 in Ubuntu Translations ""utf8" charmap in locale name is wrong" [High,Triaged]
<cjwatson> GunnarHj: I've replied briefly
<cjwatson> RAOF: did I ask you for some debugging information on the GRUB problem with corrupted video on Thinkpads?  I'm sure I remember doing so, but I can't find the mail
<GunnarHj> cjwatson: Thanks! Then, how about just replacing .utf8 with .UTF-8 to start with, and introduce parsing of .../SUPPORTED later on, if the simplistic solution proves to not suffice?
<cjwatson> GunnarHj: it would likely be an improvement, at least
<kirkland> cjwatson: I'm on patch pilot duty, and I willing to sponsor SpamapS' ssh fix at https://code.launchpad.net/~clint-fewbar/ubuntu/natty/openssh/init.d-chroot-aware/+merge/48070
<kirkland> cjwatson: unless you'd prefer I left it to you...
<cjwatson> oh, actually I'd sort of like to read through that so that I know what's going on later
<cjwatson> can you leave it to me?  I promise to get it done today
<kirkland> cjwatson: fair enough, i'll bypass
<kirkland> cjwatson: sure thing, no worries
<janimo> hyperair, hi, is banshee 1.9.3 planned to be updated?
<GunnarHj> cjwatson: Ok, then I include .utf8 => .UTF-8 in a couple of MPs, so we get it confirmed that it's an improvement, to start with.
<dholbach> can somebody have a look at the u-d-a moderation queue?
<hyperair> janimo: yes.
<sebner> bryceh: is there currently some b0rken font rendering known bug? Using nvidia but only installed the normal xorg updates (so no dist-upgrade)
<cjwatson> dholbach: done
<dholbach> thanks cjwatson
<bryceh> sebner, there's been a few font rendering issues reported on natty.  However they've ended up all being unrelated problems, so you should probably report your issue separately.
<sebner> bryceh: well, I'm seeing this issue since yesterday. Have you got some links for me (or can tell me against which packages they were filed) so I can check before filing a new bug
<bryceh> sebner, just do ubuntu-bug xorg and we'll sort it out.  Include a photo of the corruption
<bryceh> if you can, file the bug after you've reproduced the corruption, and outline the steps you take to reproduce the bug
<sebner> bryceh: reproduce = start system ^^, well my backgroundimage looks a little bit broken (the black part) but if I make a screenshot of the b0rken font it looks normal on the screenshot :\
<alexbligh> I'm sure this is really obvious, but is there any way to skip the "make" stage of building a package (I'm typing "debuild -us -uc" and I know all I have changed is the install stuff)
<cjwatson> you can often do  fakeroot debian/rules binary
<james_w> alexbligh, try ./debian/rules binary
<james_w> ah fakeroot, yeah
<bryceh> sebner, yeah you need a photo
<alexbligh> cjwatson, james_w, thanks
<sebner> bryceh: will try, why does a screenshot on the broken backgroundimage/game works though?
<alexbligh> OK, one more. If I am overriding dh_auto_configure in debian/rules, do I need to pass ALL the parameters, or just the additional ones I need? Specifically, do I need to pass --prefix and --sysconfdir, and should they be set to /usr and /etc/foo or to `pwd`/debian/tmp/usr (etc.)
<cousteau> is there any channel about help relating packages on repositories?
<pitti> zul, kirkland: do you now who is working on eucalyptus in the server team these days?
<zul> that would be daviey
<cousteau> (particularly, I'm wondering why Flash was updated to 10.2)
<pitti> Daviey: we have a question wrt. xulrunner in main; eucalyptus build dep gwt build-dep swt-gtk build-dep xulrunner
<pitti> Daviey: do you think this chain could be broken anywhere?
<chrisccoulson> Daviey, we're trying to drop xulrunner out of main
<pitti> (if we could drop swt-gtk, so much the better -- it's only in main for this one reason)
<cjwatson> alexbligh: just the extra ones you need; and they should be set to the real destination locations, not the temporary ones in the build tree
<cjwatson> (with reasonably conventional build systems, anyway)
<smoser> anyone know about peristent net rules ? i'm wanting to add to the 'globally_administered_whitelist' in /lib/udev/rules.d/75-persistent-net-generator.rules
<smoser> i wanted to do so without editing the file
<smoser> is that possible in /etc/udev/rules.d ? or is that too late.
<pitti> smoser: locally, or should that go upstream?
<smoser> well, locally for now.
<smoser> its arguable if it should go upstream
<smoser> eucalyptus uses 'd0:0d' as a prefix (ie "dude")
<alexbligh> cjwatson, thanks. I am not using dh_auto_install or whatever anyway (as I am overriding it) so that makes sense. I am trying to make a dhcpd package that is, um, less baroque than the current one...
<pitti> smoser: I'm afraid you can't just specify a single rule in /etc; you'd need to copy the entire file to /etc and edit it
<pitti> smoser: as the checks and actions are all in just one file, there's nothing "in between"
<alexbligh> smoser, Eucalyptus should have paid their $3000 for a MAC range allocation I think..
<pitti> smoser: if that is an officially registered prefix, I see nothing wrong with committing it upstream
<smoser> alexbligh, that is not arguable, you are correct.
<smoser> pitti, they didn't happen to be assigned "dude".
<smoser> :)
<alexbligh> smoser, if you are doing what I think you are doing (where all interfaces are virtual), why don't you just disable ALL interface persistence. That's what we do
<alexbligh> we just remove the file
<smoser> ah.
<alexbligh> (i.e. the file to build it)
<smoser> that makes sense for my local hack
<smoser> you'r saying just rm /lib/udev/rules.d/75-persistent-net-generator.rules
<pitti> http://www.coffer.com/mac_find/?string=d00d
<pitti> nothing official :/
<alexbligh> smoser, yes. It causes a huge amount of problems and counterintuitive behaviour. I'd vote for removing it from UEC images
<pitti> smoser: so yeah, local hack for now, I'm afraid
<alexbligh> (or having some /etc/default type thing to disable it)
<pitti> smoser: or we patch it in the Ubuntu package
<smoser> pitti, i might open a bug for ubuntu local mod
<pitti> so, good night everyone, have a nice weekend!
<alexbligh> smoser, there is also (just so you know) a bug with Xen where the PV driver MAC address and the non-PV driver MAC address are the same (as it's the same interface). One is ignored by udev, one isn't, which causes all sorts of random renaming and failure to reboot.
<alexbligh> which is the other reason we remove the file...
<cjwatson> alexbligh: uh, isn't isc-dhcp in natty reasonably current already?
<Daviey> pitti, Hmm...  TBH... i'd need to do a trial build.
<alexbligh> cjwatson, we have local patches (see http://blog.alex.org.uk/2010/12/02/adding-sql-support-to-dhcpd-part-2/)
<Daviey> pitti, But as it stands euca is still FTBFS'ing in Natty.. which is making me cry.
<alexbligh> cjwatson, , and no, it's 4.1 not 4.2
<kirkland> pitti: yeah, like zul said, it's Daviey
<kirkland> slangasek: howdy
<kirkland> slangasek: we're running into some contention building/uploading qemu-kvm
<kirkland> slangasek: qemu-linaro and qemu-kvm are producing some of the same binary package names
<slangasek> kirkland: oh?
<kirkland> slangasek: https://launchpad.net/ubuntu/+source/qemu-linaro
<slangasek> kirkland: qemu-kvm is supposed to drop those packages
<slangasek> Serge took the action to clean that up on the qemu-kvm side - do you need me to knock them out?
<kirkland> slangasek: qemu-keymaps?
<kirkland> slangasek: qemu-system
<kirkland> slangasek: i can probably handle it;  i just want to make sure i get it right
<kirkland> hallyn: you around?
<slangasek> kirkland: hum? those packages were never part of qemu-kvm before
<kirkland> slangasek: okay, it looks like it's just [qemu-kvm-extras, qemu-kvm-extras-static]
<slangasek> kirkland: yes
<kirkland> slangasek: right, sorry about that noise
<slangasek> n/p :)
<kirkland> slangasek: okay, so i just need to drop those from our build
<kirkland> hallyn: do you have a branch with that already?
<slangasek> kirkland: it also means you should update the build to only build for the targets that get packaged in qemu-kvm itself... that will substantially reduce the build time
<slangasek> janimo: did you land the CFLAGS workaround for qemu-kvm on armel?
<janimo> slacker_nl, no, it was serge hallyn
<slangasek> janimo: ok, but it's done now - great :)
<janimo> yes, I just filed the bug
<janimo> slangasek, any news on the porting queue project?
<slangasek> janimo: I'll be doing some initial population of the queue today, with plans for our first jam session next Wednesday
<Keybuk> slangasek: I saw a video on YouTube yesterday and thought of you ... ;-)
<slangasek> Keybuk: uhoh? :)
<Keybuk> slangasek: http://www.youtube.com/watch?v=AVmq9dq6Nsg
<kirkland> slangasek: right, debian/control, and debian/rules
<slangasek> Keybuk: putabirdonit.com
<slangasek> :)
<slangasek> kirkland: yep; the target selection is a bit non-obvious, but I guess you may be familiar with how it goes :)
<kirkland> slangasek: shall i drop armel from the build entirely?
<Keybuk> slangasek: ;-)
<slangasek> kirkland: you should only be building those targets that are going to be packaged in the qemu-kvm binary... so x86*/powerpc?
<slangasek> kirkland: looks like qemu-i386, qemu-x86_64, and qemu-system-"" are the only bits that we build from here, so those are the only targets that should be selected
<slangasek> (and the 'user' build phase should be dropped entirely)
<kirkland> slangasek: k;  i'm hacking on it;  will pastebin a diff to settle upon before uploading
<slangasek> kirkland: pastebin? pff, push a branch! :)
<nigelb> heh
<kirkland> slangasek: i spent my morning working in the customer lounge of the VW service department;  bzr sucks over a slow link;  apt-get source + pastebin was my friend
<Keybuk> slangasek: the discovery of this show is nearly as awesome as when ev introduced me to Canadian Trailer Park Boys (the story of cody-somerville's life)
<hallyn> kirkland: oh, no, i haven't done a branch without qemu-kvm-extras yet
<kirkland> slangasek: alas, i'm back home now, on a good up/down link; so sure, a branch
<hallyn> is that just a matter of removing that from the control file?
<slangasek> kirkland: is that because bzr sucks over a slow link, or because you had a local apt source repo?
<kirkland> hallyn: okay, i'm trying to sort it out now
<alexbligh> cjwatson, hmm "fakeroot debian/rules binary" just produces the output "dh  binary" and does nothign else
<slangasek> Keybuk: <snort>
<hallyn> kirkland: cool, thanks
<kirkland> hallyn: it's a bit more of a mess in debian/rules
<hallyn> kirkland: fwiw, natty boots fine with -std vga in qemu :)
<kirkland> hallyn: the debian/control part is easy
<kirkland> slangasek: i had no local apt source
<slangasek> alexbligh: that means it's been run before; dh aggressively caches the results
<slangasek> kirkland: interesting
<slangasek> alexbligh: you would need to run 'debian/rules clean' first
<alexbligh> slangasek, I am attempting to avoid recompiling (i.e. doing the make). Won't debian/rules clean clean the make?
<hallyn> kirkland: and simply rm debian/qemu-kvm-extras* ? :)  feels reckless
<kirkland> hallyn: yeah, that too
<slangasek> alexbligh: yes, it will.  You could try running 'dh_prep', it's possible that this is smart enough to roll back the debhelper.log files under debian/ also
<kirkland> hallyn: it's the debian/rules stuff that looks complicated to me
<alexbligh> slangasek, no difference.
<slangasek> hallyn: my suggestion to kirkland was that if you're no longer shipping any of the dozen or so binaries emulating other architectures, you should also not waste buildd time building them :)
<hallyn> slangasek: yup
<slangasek> alexbligh: so, deleting the debian/*debhelper.log files will tell dh to start from the beginning
<slangasek> alexbligh: no guarantee that this won't also require rebuilding the upstream source - it depends how good the upstream target definitions are
<alexbligh> slangasek, I am using the default dh version 7 rules file. It's (essentially) my package.
<alexbligh> slangasek, so not dh_clean?
<slangasek> alexbligh: you could try it, I'm not sure what that will give you either
<kirkland> slangasek: i suppose i should drop sparc from here too
<alexbligh> slangasek, it gave me a huge rebuild :-(
<slangasek> kirkland: just to make sure there's no understanding - you're going to continue to build the x86 targets *on* all archs, right?
<slangasek> (this should greatly simplify the rules for all architectures)
<slangasek> the only special case will be x86 now, because of the binfmt handling
<slangasek> alexbligh: sorry to hear it.  If you're lucky, at least some of it is cached
<kirkland> slangasek: hmm, is that how you'd like to handle this?
<slangasek> kirkland: that's what was agreed at the rally :)  qemu-linaro is *not* building x86 emulators for any arch, with the reasoning that qemu-kvm is going to have the best x86 emulation generally - so please continue to build those for everyone
<kirkland> slangasek: okay, sorry;  i think hallyn was a party to that discussion and i was not
<slangasek> kirkland: I think you begged off :-)
<kirkland> hallyn: we should probably work together on this ;-)
<alexbligh> slangasek, nope, it essentially did a make clean. I think it removed build.stamp. There must surely be a simple way to rebuild only the package (not the binary) for an autoconf style package.
<slangasek> alexbligh: removing debian/*.debhelper.log is as close as I know to come, in the dh model
<alexbligh> slangasek, thanks - I'll test that in a bit. In the mean time, the obvious consequence of playing with dhcpd on a remote machine without kvm access has happened. I should really use a VM for this :-/
<hallyn> kirkland: wouldn't that just be the default?  (to keep building qemu-system-amd64 and qemu-system-i386 on all architectures) ?
<kirkland> slangasek: lp:~kirkland/ubuntu/natty/qemu-kvm/fix-build
<kirkland> hallyn: right
<kirkland> hallyn: lp:~kirkland/ubuntu/natty/qemu-kvm/fix-build
<kirkland> slangasek: hallyn: that's a first draft
<hallyn> (fetching)
<hallyn> (slowly - i'm getting 7mbs down, but something like 7kps from launchpad.net)
<hallyn> actually i guess that's just ppa.l.n - bzr is fetching 10x as fast
<slangasek> kirkland: FYI, there were un-uploaded changes committed to the UDD branch for qemu-kvm; those should get merged in also
<kirkland> slangasek: i'm pretty sure i did
<kirkland> slangasek: i saw your manpage change
<kirkland> slangasek: i had a cve/security fix
<kirkland> slangasek: plus an arm build fix from hallyn
<hallyn> kirkland: looks good so far
<slangasek> kirkland: ah - the changelog entry didn't make it into the upload
<kirkland> slangasek: ?
<kirkland> slangasek: see ubuntu13, ubuntu14, ubuntu15
<slangasek> kirkland: the package that was uploaded (0ubuntu14) doesn't show the manpage change
<slangasek> I haven't looked at your branch yet, downloading it now (having just figured out that the UDD branch no longer matches the archive)
<kirkland> slangasek: right, that one didn't make it into 0ubuntu14
<kirkland> slangasek: i'll move your changelog entry up to 0ubuntu15
<kirkland> slangasek: as it will be included in this upload
<jam> slangasek: there are only 14.5k jobs pending...
<kirkland> slangasek: now that I have decent networking and can work from the bzr branch :-)
<jam> downtime is shockingly painful
<slangasek> kirkland: ok; let me know when that's done, I'll need to do some minor surgery on the branch afterwards to make everything match up again
<slangasek> jam: not that - I mean there's a desync between what was uploaded and what was committed :)
<jam> plus a wheezy release
<jam> slangasek: so the foo-x.y.deb doesn't match the tag x.y?
<kirkland> slangasek: okay, i'm pushing to lp:ubuntu/qemu-kvm;  can you take it from here?
<slangasek> jam: the 0.13.0+noroms-0ubuntu12 deb matches the tag; then there were further commits to the branch, and further uploads to the archive
<slangasek> kirkland: i.e., you want me to upload?
<kirkland> slangasek: sure
<slangasek> ok
<kirkland> slangasek: pushed to lp:ubuntu/qemu-kvm
<slangasek> kirkland: NB I'm also in the midst of uploading 5 armel kernel source packages, so it'll be a bit before I can make any headway :)
<kirkland> slangasek: okay, well, i can upload to;  you just said you wanted to do some surgery
<slangasek> kirkland: the surgery can happen on the branch once the upload is in the archive
<slangasek> it's specifically branch surgery not package surgery
<kirkland> slangasek: i'm building now locally
<kirkland> slacker_nl: ah
<kirkland> slangasek: ah
<kirkland> slangasek: cool, i'll get this built/tested/uploaded then
<kirkland> slangasek: i have a bunch of other stuff to do, but this has my attention right now ;-)
<slangasek> k :)
<kees> stgraber: will you take care of uploading the natty italc updates? just wanted to make sure that got fully taken care of now that the others are public. thanks again for all the dediffs on that. :)
<kirkland> hallyn: is there a bug open for all this qemu-kvm build futzing?
<ohsix> hrm, can timidity be made to play well with pulse, it lords over the hw from a single instance
<ohsix> false alarm, java6 is ugly
<hallyn> kirkland: with linaro you mean?  no
<sbeattie> jdstrand: do you have any idea why byacc got demoted to universe?
<jdstrand> sbeattie: doesn't ring a bell otoh
<jdstrand> sbeattie: are there any bugs on it?
<jdstrand> no, doesn't seem so...
<sbeattie> jdstrand: not that I can see. It's a build dependency of krb5 at least, and I'd suspect of many others in main.
<jdstrand> sbeattie: the version that came in was an autosync from Debian...
<jdstrand> sbeattie: I can only say it happened on 2011-01-14
<sbeattie> jdstrand: right, which came in during maverick, but then (according to https://launchpad.net/ubuntu/+source/byacc) it got republished in natty/universe
<jdstrand> yeah, clearly that was a mistake
<jdstrand> sbeattie: I'll fix
<jdstrand> sbeattie: it is only krb5 and gob2 that have a build dep on it btw
<kirkland> slangasek: i just moved all of the qemu-system-arm* bugs over from qemu-kvm to qemu-linaro
<slangasek> kirkland: sounds reasonable, thanks
<kirkland> slangasek: some might need to grow a qemu-kvm task too (if the fix necessitates an SRU against qemu-kvm, in Lucid, say)
<kirkland> slangasek: i think we'll follow your lead on that
<jdstrand> sbeattie: actually, krb5 has a byacc | bison in the build depends
<jdstrand> sbeattie: and bison is in main
<jdstrand> sbeattie: so I don't think I will make the change
<sbeattie> jdstrand: hunh. odd. sbuild/maverick is failing to build krb5 because it can't install byacc.
<jdstrand> sbeattie: that might be a ust thing
<sbeattie> jdstrand: okay. I'll dig into it.
<kirkland> slangasek: hmm, i'm looking for a better way to do this ...
<hallyn> cjwatson: i'm chasing down a bug (not yet filed, guess i should) that lucid (and probably maverick) does not boot in qemu with '-vga std', while natty does.  A bleeding edge kernel doesn't help, so at this point I think I have to blame grub.  Was wondering whether you had any ideas.  It bombs just hangs after complaining about 'out of range pointer 0x80220000'
<kirkland> slangasek: after my test build, i realized that all of those binaries previously moved to qemu-extras just landed in qemu-kvm now
<kirkland> slangasek: i can:
<kirkland>         # Remove the binaries provided by qemu-linaro
<kirkland>         for i in alpha arm armeb cris m68k microblaze mips mipsel sh4 sh4eb sparc sparc32plus sparc64 system-arm system-cris system-m68k system-microblaze system-mips system-mips64 system-mips64el system-mipsel system-sh4 system-sh4eb system-sparc system-sparc64; do \
<kirkland>                 rm -f debian/qemu-kvm/usr/bin/qemu-$$i
<kirkland>         done
<kirkland> slangasek: easily enough;  but it's kind of a waste to bother building them
<kirkland> slangasek: i'm looking for a --configure option to just not build/install them
<kirkland> slangasek: hmm, maybe --target-list
<slangasek> kirkland, hallyn: huh, looks like maybe I misunderstood the state of play of the qemu-kvm packages on armel.  I assumed qemu-kvm was being built for all archs and would contain the qemu-*-x86* emulators, but it seems this package doesn't exist at all and we're not providing an x86 emulator for arm *anywhere*?  Should qemu-kvm provide this (as the branch w/ better x86 emulation), or should qemu-linaro provide this?
<slangasek> kirkland: right, --target-list is the key
<slangasek> kirkland: the Debian qemu source package makes use of --target-list, if you need an example
<slangasek> kirkland: no it doesn't, I'm lying
<slangasek> the qemu-maemo package had that example, only I've superseded that source and deleted it from the ppa, ho-hum :)
<slangasek> anyway, yes - use --target-list to only build the objects you care about
<kirkland> slangasek: okay, thanks
<slangasek> kirkland: I'm just about done with the branch surgery; I recommend holding off a few minutes before making any further changes to bzr, I'll push my cleanup and you can pull it back with bzr pull --overwrite
<hallyn> packages for natty are not auto-syncing now right?
<slangasek> kirkland: branch pushed; please do a fresh checkout or a bzr pull --overwrite to get back in sync
<geser> hallyn: no, we are after DIF, if you need something you need to "requestsync" it
<stgraber> kees: natty has been fixed "cleanly", as in, ubiquity re-generate the keys at install time. I uploaded this one on Monday.
<soren> slangasek: Do you think you could review this instead of cjwatson: https://code.launchpad.net/~soren/ubuntu/natty/mountall/sigpipe-handler/+merge/49401 ?
<slangasek> soren: sigpipe> far better to have cjwatson review it
<slangasek> he has deep understanding of sigpipe; I run screaming
<soren> slangasek: Alrighty.
<hallyn> geser: thx
<kees> stgraber: ah, okay.
<kees> stgraber: still might be a good idea to fix it in the natty italc-client, in case someone upgrades from maverick live DVDt to natty without first installing -security updates...
<kirkland> slangasek: okay, the manifest of qemu-kvm_0.13.0+noroms-0ubuntu15_amd64.deb is at: http://paste.ubuntu.com/566040/
<slangasek> kirkland: shouldn't the user targets be in here, in addition to the system targets?
<slangasek> kirkland: i.e., qemu-i386, qemu-x86_64
<kirkland> slangasek: yeah, i'm just trying to figure out how to state those in             --target-list="x86_64-softmmu i386-softmmu" \
<slangasek> kirkland: qemu-linaro does separate passes for system vs. user
<slangasek> one is --disable-system, the other is --disable-linux-user
<slangasek> not sure to what extent that's required
<hallyn> --enable-user?
<kirkland> hallyn: yeah;  just added that;  what about --enable-linux-user ?
<slangasek> kirkland: ah, it's i386-linux-user and x86_64-linux-user for the targets
<hallyn> kirkland: actually yes, i think you want
<hallyn> --enable-linux-user,
<slangasek> I guess --target-list may override --en/disable-linux-user
<hallyn> and the way i read configure, it seems to say that enable-user == ! enable-linux-user
<slangasek> or vice-versa
<kirkland> slangasek: hmm, okay, i'm testing now
<hallyn> weird
<kirkland> slangasek: it was VERY nice to get our build back down to ~2 minutes (from 45+ minutes before)
<slangasek> :-)
<slangasek> kirkland: now, can I switch this package to use dh :)
<kirkland> slangasek: dh7 you imply?
<slangasek> yah
<slangasek> I'm not really going to do it right now though
<kirkland> slangasek: would you like to?
<slangasek> eventualy
<kirkland> slangasek: you're *welcome* to do so
<kirkland> slangasek: don't do it yet, as I need to merge my changes in on top of yours
<kirkland> slangasek: ask i'm still tweaking the build correctly
<slangasek> yep
<kirkland> slangasek: but yeah, dh7 would be nice here
<slangasek> qemu-linaro is dh7.  It doesn't look all that much nicer ;)
<kirkland> slangasek: :-P
<killown> when ubuntu will upgrade to gtk3?
<kirkland> slangasek: perfect!
<kirkland> slangasek: i think we have a winner
<kirkland> hallyn: I have not added ppc64 to the target list yet;  let's do that when we get the patches from our friends
<hallyn> kirkland: i woudln't be surprised if we hear a bug report overnight from one of the two people who quietly are using it
<kirkland> hallyn: that would be kinda cool, actually :-)
<kirkland> hallyn: snuff 'em out!
<hallyn> yeah but they're not gonna be nice about it :)
<kirkland> hallyn: what are the ppc64 targets then?
<kirkland> ppc64-softmmu and ppc64-linux-user ?
<hallyn> looks like
<kirkland> hallyn: ack, got it
<kirkland> hallyn: slangasek: okay, built, tested, committed, uploaded
<kirkland> hallyn: slangasek: give 'er a test sometime later today or tomorrow
<hallyn> i'll update right now, see if it puts a stop to my current ongoing tests :)
<LinuxPhreak1> I don't know if this is the correct channel to ask this question in. But I'm working on program to help users transition from Windows to Ubuntu. I wanted to know if it is possible to build deb package inside of Windows
<slangasek> LinuxPhreak1: inside a VM, maybe; otherwise you need a chroot and I don't recall Windows having that feature
<slangasek> actually, even in a chroot you'd be tainted by cygwin
<LinuxPhreak1> what about chroot compiled with cygwin? Has chroot been compiled with cygwin
<slangasek> it's not about /compiling/ it, it's about having the underlying system facilities that /implement/ chroot
<broder> LinuxPhreak1: what do you mean by "transition from Windows to Ubuntu"? what's wrong with Wubi or Ubuntu Light?
<slangasek> so in theory you could have a cygwin environment with a Windows->Linux cross-compiler
<slangasek> but I don't see the point
<LinuxPhreak1> This program is not geared towards installing Ubuntu with Windows. It is simply going to copy users data such as pictures and videos. Place them into a .deb file. Then the user will be able to have the files in locations on Ubuntu such as Pictures directory.
<slangasek> a .deb is a package format for system software; it's not a reasonable format for transferring data between Windows and Ubuntu
<LinuxPhreak1> Okay so maybe something like archiving the files and generating a bash script to extract the files into certain locations
<broder> LinuxPhreak1: i think that ev is already working on that for ubiquity on natty
<LinuxPhreak1> Cool. I'll fetch the source and check it out. This program is not just geared for ubuntu but for several Linux OSes
<bryceh> rickspencer3, you about?  I sent you an essay on your intel freeze bug
<bryceh> rickspencer3, but basically, I think you might be seeing a freeze we already know about, but there's not enough info to say one way or the other.  if you want to gather the info I sent directions, but if you want to just assume it's covered by one of the other bugs and wait 'til they get resolved, that's cool too.
<rickspencer3> bryceh, I added a note to the bug
<rickspencer3> let me know if you need more info, happy to help, but closing it is fine too
<bryceh> ah great
<cjwatson> hallyn: I don't have an answer for you off the top of my head, but basically that message is equivalent to malloc arena corruption, or freeing a non-malloced pointer, or similar, and can be similarly hard to debug (no valgrind either).  if you can give me a rough recipe for reproducing it in a bug report, I may be able to work something out; even better if you can produce a cut-down version with grub-mkrescue or something ...
<cjwatson> ... like that
<cjwatson> hallyn: I'd probably start by executing menu commands one by one to see where it breaks
<hallyn> cjwatson: i figured i would try compiling natty's grub for lucid, but that failed
<cjwatson> no xorriso would be awkward
<slangasek> kirkland: any further thoughts about where we should be putting i386 emulation for non-kvm-supporting archs?
<cjwatson> I don't remember a specific fix that might correspond to that, but it could have been in the course of general code cleanup or anything
<kirkland> slangasek: on a call, will get back with you after
<slangasek> kirkland: okie
<hallyn> cjwatson: replacing grub2 with grub it boots fine.  at least now i know waht to file the bug against :)
<soren> cjwatson: Do you think there's any chance you'll get to reviewing that patch of mine today? If not, that's perfectly fine, then I just need to flick a switch somewhere.
<Laney> oijoijoijoijoijoijoijhhoihoih
<kirkland> slangasek: back now
<kirkland> slangasek: okay, i propose this: qemu-kvm builds the binaries for and on those that support KVM acceleration
<kirkland> slangasek: qemu-linaro builds everything else
<kirkland> slangasek: ie, qemu-kvm really is for "KVM", and qemu-linaro is more for "QEMU" (non-kvm)
<kirkland> slangasek: does that sound reasonable?
<kirkland> @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:
<slangasek> kirkland: is that an exclusive or inclusive and?
<slangasek> kirkland: i.e., does build for those that support KVM mean building qemu-i386 on armel, or not?
<kirkland> slangasek: i'm ambivalent on that;  though I think it a precious waste of armel cpu time to waste running qemu-i386 emulation :-)
<kirkland> slangasek: ie, is there sensible reason to do that, that I'm missing?
<slangasek> kirkland: well, no one seems to have minded that it wasn't building before now <grin>, but I have some evil designs for it that involve multiarch
<kirkland> slangasek: neat :-)
 * kirkland has long awaited this magical multiarch
<slangasek> and it's at least as useful as, y'know, qemu-sparc on armel
<slangasek> which we /are/ building
<slangasek> kirkland: so at the root, my question is - will using the kvm branch of qemu give any advantage in terms of x86 system emulation on non-kvm archs?
<slangasek> if not, I'm happy to build from qemu-linaro (it's already building, we're just throwing it away at the end)
<kirkland> slangasek: nope, none that i know of
<slangasek> if so, I'd like us to get those benefits and have it built from qemu-kvm
<kirkland> hopefully hallyn can keep me honest there ^
<kirkland> slangasek: currently, qemu-kvm only positively effects i386-on-i386, i386-on-amd64, and amd64-on-amd64
<hallyn> my understanding is the same
<slangasek> ok, so even amd64-on-i386 isn't helped, the differences are entirely in the code that leverages the proc for native execution?
<soren> Yeah. amd64-on-i386 could actually work (I've learned this recently), but kvm doesn't do it at the moment.
<slangasek> so thinking about it, the other issue is that qemu-kvm already has all the x86 bioses sorted already
<slangasek> if I build qemu-system-i386 from qemu-linaro and it wants a different version of seabios or vgabios, I'm in trouble
<alexbligh1> What does the file [packagename].templates do in the debian directory? It seems to be translation related. If it's not there, bad things happen. If it's there, I get (on dpkg -i) "Template parse error near `# These templates have been reviewed by the debian-l10n-english', in stanza #1 of /var/lib/dpkg/info/extility-dhcpd.templates"
<alexbligh1> I have copied the file from the Natty dhcpd package so I don't see why it causes a parse error (particularly on a comment)
<slangasek> alexbligh1: .templates are the source of the questions asked by a package via the debconf interface at install time
<hallyn> slangasek: yes, tracking the bioses is a bit of extra work...
<slangasek> hallyn: not just tracking them but making sure we don't have mutually exclusive requirements for bios versions due to upstream version skew
<kirkland> slangasek: hmm, yeah, the bios problem is a bitch
<alexbligh1> slangasek, ok, any idea why it chokes on a line begining with a #?
<slangasek> kirkland: I think the easiest way to avoid the bios problem is to use qemu-kvm to build all x86 emulation, even on non-kvm archs - do you think that's reasonable under the circumstances?
<slangasek> alexbligh1: I'm guessing there's some difference in the post-processing of the templates when copying into the binary package
<slangasek> alexbligh1: I'm having a look now at the dhcp3 source package
<alexbligh1> slangasek, it's actually the templates file from https://launchpad.net/ubuntu/natty/amd64/isc-dhcp-server/4.1.1-P1-15ubuntu2 I used
<persia> slangasek, So, some of the cross-arch build stuff we have floating around expects that a single package will handle all cross-arch needs.  Is the expectation that we'd have ${src}-extras-static and ${src}-x86-static and need to generally pull both to ensure full cross-arch support?
<slangasek> persia: -static is a special case; qemu-user-static does it all
<slangasek> alexbligh1: are you using 'dh_installdebconf' to install the templates into the package?  Are you building on natty?
<alexbligh1> I'm building on Lucid. I'm just using the stnadard dh7 rules file with a couple of overrides.
<persia> slangasek, Ah, so your suggestion is only that qemu-system-foo be generated separately.  by qemu-kvm for x86, and by qemu-linaro for ARM+powerpc?
<slangasek> alexbligh1: it's possible that the behavior of either debconf or dh_installdebconf has changed between lucid and natty.  I haven't run into this before though
<alexbligh1> slangasek, Does that not do dh_installdebconf?
<slangasek> persia: yep - they're already being generated separately, we just have a gap wrt i386-on-other
<slangasek> er, x86-on-other
<kirkland> slangasek: yes, that seems fine
<slangasek> kirkland: ok, I'll wire it up and push to bzr, thanks
<persia> Ah, OK.  And if it's just qemu-system, and not qemu-user, it won't affect any of the scripts I care about.  Sorry for the noise.
<alexbligh1> slangasek, the annoying thing is I don't actually need debconf but the .init file does weird things I don't understand that seem to rely on it
<slangasek> persia: oh, sorry - it would also affect qemu-user but not qemu-user-static; does that make a difference?  (non-static qemu-user is never used for binfmt-misc...)
<persia> Not to me.  My uses of qemu are either related to binfmt-misc, or (when I have time) about powerpc-on-powerpc with qemu-system, which I need to rearrange some services locally to test with qemu-linaro (in my queue)
<slangasek> persia: ok
<kirkland> slangasek: ack, thanks
<slangasek> alexbligh1: unwinding debconf integration from a package is somewhat non-trivial, I'm afraid I don't have time to help you with this at the moment; you could see if anyone around on #ubuntu-motu can lend a hand
<persia> This channel is also fine for such things: there's no difference in the on-topicness of questions in one place or the other.
<alexbligh1> slangasek, no problem. I will try and learn about debconf.
<alexbligh1> After all, it would be better if it worked, and dhcp with a DBI back end might just be useful to someone else
<slangasek> persia: not meaning to suggest it's off-topic, merely that #ubuntu-motu is usually a good place to find people able to pitch in; is that no longer the case (de jure or de facto)?
<persia> slangasek, de jure from about a year back: with the breakdown of developers into lots of different types, we seek to encourage teaching and mentoring in all development channels.
<slangasek> okie
<persia> the MOTU are still happy to help with stuff, as before, but other people are also supposed to be happy to help :)
<persia> alexbligh, To be clear: feel free to ask in -motu if you like, but odds are that most folk who understand debconf templates well are also here.
<alexbligh1> persia, thanks. I am sure I have missed something dumb. I think I shoudl look at it when i am less tired...
<alexbligh1> well, the issue is db_get extility-dhcpd/interfaces is returning "RET=10 extility-dhcpd/interfaces doesn't exist". Presumably the key should be defaulted somewhere, but I don't know where.
<soren> Keybuk: Oh, maybe you could review my mountall patch?
<soren> Keybuk: https://code.launchpad.net/~soren/ubuntu/natty/mountall/sigpipe-handler/+merge/49401
<slangasek> alexbligh1: "doesn't exist" means the question isn't registered with debconf; for that you need a working .templates
<Keybuk> soren: not without context, no
<Keybuk> soren: why can't you add MSG_NOSIGNAL to the culprit send/write call?
<soren> Keybuk: Because I'm not sure which of the many send/write calls in Plymouth's client code is at fault.
<Keybuk> well, that's where to start then ;-)
<Keybuk> given it's EASY to tell which syscall causes a signal
<soren> Keybuk: Well, I can't really.
<soren> Keybuk: it could be any one of them.
<Keybuk> and it's pretty easy to add the flag to all of the calls
<alexbligh1> slangasek, thanks
<soren> Keybuk: Plymouth has gone the way of the segfault. The next thing that tries to talk to it blows up.
<soren> Keybuk: One time around it could be one write() call, next time around it could be another.
<Keybuk> right, so add the flag to them ;-)
<Keybuk> it's the right fix
<soren> Keybuk: I'm not sure which effect that would have, really.
<Keybuk> we did it to D-Bus for example
<Keybuk> you get SIGPIPE when you issue a write()/send() etc. on a disconnected socket
<soren> Right.
<Keybuk> adding the MSG_NOSIGNAL flag means you get an error back instead via usual errno
<walters> i'd be nice if the kernel had a system call to the kernel to opt out of all the broken stuff from unix
<walters> like, all signals
<Keybuk> walters: it'd be *really* nice if that flag opted out of filesystem authors citing broken stuff from posix as justification for their crazy filesystem behaviour <g>
<walters> heh
<Keybuk> soren: also, really close plymouth?!
<walters> welcome your new sprinkle-userspace-with-fdatasync() overlords
<Keybuk> soren: why not just SIG_IGN?
<Keybuk> walters: oh, it got much worse
<Keybuk> did you not see the dpkg thread?
<soren> Keybuk: Because if I close it, we automatically attempt to reconnect.
<maco> link plz?
<walters> Keybuk: nope
<Keybuk> soren: won't the -EPIPE from write() cause that anyway
<walters> i should really be working but, i'll read the link =)
<soren> Keybuk: Good question.
<Keybuk> soren: if you ignore the signal, it behaves
<soren> Keybuk: Would that be an acceptable change to mountall, then?
<soren> Keybuk: Or where would you stick it?
<Keybuk> soren: since I get to play upstream, I think the acceptable change is to fix libplymouth
<Keybuk> so then everyone benefits
<Keybuk> and you don't hit this bug next week somewhere else
<Keybuk> maco, walters: I can't find the link
<Keybuk> but it got insane
<Keybuk> oh
<slangasek> Keybuk: you're proposing to change the caller's signal handling from within libplymouth?
<Keybuk> now I have
<Keybuk> slangasek: no, I'm proposing that libplymouth guards its write() calls to not result in a signal to the caller
<soren> Keybuk: Silly question, but what's the write() equivalent of MSG_NOSIGNAL?
<Keybuk> maco, walters: http://lists.debian.org/debian-dpkg/2010/11/msg00075.html
<slangasek> did it get insane before or after tytso and Olaf van der Spek started emulating one of joeyh's thread batterns?
<Keybuk> that has a quote of Ted's suggestion
<slangasek> Keybuk: guards> ok
<maco> oh so i was on the right thread. i found ted's suggestion here https://bugzilla.sourcefire.com/show_bug.cgi?id=83924
<maco> erm no
<maco> http://us.generation-nt.com/answer/bug-605009-serious-performance-regression-ext4-help-201204702.html?page=8
<maco> THERE
<maco> (two paste buffers...)
<maco> :( ted doesnt wrap at 80 char
<Keybuk> nor do I...
<walters> Keybuk: the only bug i see here is dpkg isn't threaded; it's like all the unix calls, to make them sane you have to wrap them in a thread worker library
#ubuntu-devel 2011-02-12
<walters> Keybuk: aiui the default i/o scheduler will, if inside the same process, go for maximum speed if you do that
<maco> Keybuk: do you line wrap at all to avoid scrolling forever to the right?
<Keybuk> maco: no, since "word wrap" was invented in the 80s, there isn't a need
<soren> Keybuk: Uh, yeah, silly question indeed. /ignore me
<maco> Keybuk: web browsers havent caught up apparently
<Keybuk> maco: you mean bugzilla hasn't
<maco> i was actually thinking it was the mailing list since ive seen the no-wrap-grrr thing on other lists
<slangasek> so if you needed to detect with gcc -E what libc your build system is building against, what's the best way to do that?  #include <stdlib.h>, look for __GLIBC__ et al.?
<Keybuk> slangasek: guards> in general the fix is replace write(a,b,c) with send(a,b,c, MSG_NOSIGNAL)
<slangasek> Keybuk: right; you seemed to be suggesting SIG_IGN earlier, which would certainly modify the caller's handling of other signals
<slangasek> well
<slangasek> its handling of that signal from other sources
<soren> Keybuk: That's what I'm doing right now. Seems to be pretty well contained, actually.
<Keybuk> no, in that case I just meant that I couldn't understand why, if soren was intent on hiding the bug rather than fixing it, his patch wasn't just signal(SIGPIPE, SIG_IGN)
<Keybuk> soren: yeah, I figured it might be ;)
 * slangasek looks for a nibble on his libc question
<soren> Keybuk: Becuase if I called plymouth_disconnected, the connection would be proplerly cleaned up, which meant that it would attemt the reconnect. I didn't realise the plymouth client lib would do that on its own.
<soren> Keybuk: Would there be any point in wrapping the MSG_NOSIGNAL in an #ifdef?
<Keybuk> you could certainly do
<Keybuk> #ifdef MSG_NOSIGNAL
<Keybuk> err
<Keybuk> send (a,b,c,
<Keybuk> #ifdef MSG_NOSIGNAL
<Keybuk> MSG_NOSIGNAL
<Keybuk> #else
<Keybuk> 0
<Keybuk> #endif
<Keybuk> );
<broder> eww
<Keybuk> I think we did that in D-Bus
<Keybuk> actually, I think we did
<Keybuk> #if HAVE_MSG_NOSIGNAL
<Keybuk>    MSG_NOSIGNAL
<Keybuk> ...
<Keybuk> and added a configure check
<Keybuk> in case it got defined as an enum
<soren> Indeed you did.
<soren> Oh.
<soren> I did the other thing as:
<soren> send(a,b,c,0
<soren> #ifdef MSG_NOSIGNAL
<soren>         |MSG_NOSIGNAL
<soren> #endif
<soren>        )
<soren> But meh.
<Keybuk> that works too ;-)
<Keybuk> points for stylishness
<soren> Keybuk: I learned from the master: http://cgit.freedesktop.org/dbus/dbus/commit/?id=c5d0998295a15fe649da854b68334c767aad1049
<Keybuk> lol
<soren> Keybuk: Hm... I think dbus is doing it wrong.
<soren> Keybuk: HAVE_DECL_MSG_NOSIGNAL is 1 if MSG_SIGNAL exists, 0 otherwise.
<soren> Keybuk: ...but the check is #fidef HAVE_DECL_MSG_NOSIGNAL.
<soren> Keybuk: So it's always defined.
<soren> Keybuk: Either that or the comment in config.h.in lies.
<soren> Keybuk: Nope, the comment is accurate.
<soren> Keybuk: Oh. That's fixed recently, apparantly.
<soren> Keybuk: Thanks for the pointers. It seems to work well.
<soren> Keybuk: I'll send it upstream Monday. I need to sleep now.
 * cjwatson is glad Keybuk reviewed this before he got round to it
<cjwatson> alexbligh1: it's entirely reasonable for a package to assume that its own debconf templates are there - it shouldn't need to do any defaulting
<gurkan_> hi mates
<gurkan_> need help about my /var/run/utmp file
<gurkan_> i have read the man page but it's not clear on 2 points
<gurkan_> i didn't understand the getutline and getutid fonctions
<gurkan_> if someone seems to know well this function and utmp file he could explain me
<psusi> what don't you understand about it?
<gurkan_> the how !
<gurkan_> i don't understand the how
<psusi> how what?
<gurkan_> how to implement in my code the getutline fonction for exploiting his return value if it is not empty how can i know about value contains
<gurkan_> i read that search forward from the curent position ... blabla but
<psusi> you don't implement the function in your code, it is part of the standard library... you just call it.  the man page shows example code
<gurkan_> no the man page not show the exemple of getutline exemple , after you implement setutent in the code what did i extract whit getutline function
<psusi> actually I guess the example is only of how to update the entries not read one
<psusi> you extract a utmp entry in a struct utmp
<gurkan_> yes this is the man page exemple , but the form which interest me is only the read in deep of all database
<psusi> huh?
<gurkan_> the man page show erase/append correct .
<psusi> yes
<gurkan_> as i said i try on to read
<psusi> yea... so you call getutent() and then getutline() repeatedly
<gurkan_> only to read with getutline
<psusi> err, actually it looks like you just use getutent.. getutline seems to be for searching for a specific command someone is running
<gurkan_> while ((u=getutent()) !=NULL) it's not enough
<psusi> not enough for what?
<psusi> that should set up a loop that will iterate over all of the utmp records
<gurkan_> struct utmp *utmline;
<gurkan_> struct utmp *ut ;
<psusi> use pastebin
<gurkan_> getutline() searches forward from the current file position in the utmp
<gurkan_>        file.   It scans entries whose ut_type is USER_PROCESS or LOGIN_PROCESS
<gurkan_>        and returns the first one whose ut_line field matches ut->ut_line.
<gurkan_> it's not clear for
<gurkan_> i need a sample exmeple of code
<gurkan_> sorry
<cjwatson> perhaps you could ask in a general C or Unix programming help channel
<psusi> the while loop you just pasted is a good start... now just do something with u in the body
<cjwatson> this is really not a programming help channel, unless you're specifically working on a piece of code in Ubuntu
<gurkan_>  ok watson
<gurkan_> sorry for my flood
<psusi> cjwatson, hey cj... are you familliar with partman-ext3?  and if so, think you could get it to mount a newly formatted ext4 partition in natty with the mount option that prevents the background auto zeroing of the inode table so the installation goes faster? ;)
<cjwatson> you already have a bug open about that don't you?
<cjwatson> I'll get to it, if so :)
<cjwatson> and yes, I'm familiar with partman-ext3
<cjwatson> I've queued up bug 556621 in my browser for later action
<ubottu> Launchpad bug 556621 in e2fsprogs (Ubuntu) "lazy_itable_init not on by default" [Wishlist,In progress] https://launchpad.net/bugs/556621
<cjwatson> not really enough brain to analyse it right now though
<Keybuk> cjwatson: I tend to think that bugs like that are worth fixing properly, so the next person doesn't have to do the same "fix" you did befoer
<cjwatson> Keybuk: oh I agree, I was just glad you got to think through it so I didn't have to :)
<Keybuk> cjwatson: :D
<Keybuk> and they say this place is a black hole...
<cjwatson> you're just sentient Hawking radiation
<psusi> cjwatson, yea, have a bug open
<psusi> Keybuk, hey, there you are... not seen you lately.. still not had a chance to review my patches for ureadahead?  also I tried something a little nuts the other day... rather than only read the parts of the files that are still in the cache, I disabled the calls to mincore() and just had it read the entire file always... and it sped things up
<psusi> managed to get down just under 15 seconds boot time with natty on the 1.5tb wd green drive
<ohsix> what sort of changes? (url to patch/tree?)
<psusi> must... get... to...10...
<Keybuk> psusi: I'm not reviewing patches to ureadahead
<Keybuk> if you want to play with it, be my guest
<Keybuk> if you can improve things, w00t
<psusi> ohsix, bzr branch code.launchpad.net/~psusi/ubuntu/natty/ureadahead/mine
<psusi> that plus using e2defrag to pack the files
<psusi> Keybuk, so I should poke pitti or cjwatson about it? ;)
<Keybuk> psusi: I don't think you need to poke either of them
<Keybuk> if you can make a new version and demonstrate it improves *for everybody*
<Keybuk> then you touched it last ;-)
<Keybuk> though for release tracking, you should probably demonstrate that to cjwatson
<psusi> lol... so I get to become maintainer?  heheh...
<Keybuk> since he's tech lead of foundations
<psusi> probably getting a little late in this dev cycle for it now, but be nice to get it in early next cycle for testing
<psusi> or maybe I make some more noise about getting people to test it from my ppa and report results...
<psusi> I've been learning python lately too... really nice language... only took me about 10 minutes the other day to figure out how to write about a dozen lines of code to run ureadhaead --dump, parse the output, sort files from directories, and spit out the inode priority list file for e2defrag to pack the dirs first, then files
<JanC> psusi: of course python is a nice language, it was named after Monty Python after all  ;)
<psusi> hehe
<Keybuk> psusi: probably the best plan would be to PPA test now, so then you can justify it for whatever natty+1 is called
<ion> obese
<Keybuk> oscillating ocelot?
<psusi> Opal Ostrich
 * JanC doesn't make proposals anymore, because my "superior proposals" for release names never get used  ;-(
<psusi> this is the postinst from ureadhaead: http://pastebin.com/3W4Atpxg
<psusi> that's not going to force a reprofile on upgrade is it?
<psusi> only on trigger, right?
<psusi> I can combine that into one line for configure | triggered) right? so both will reprofile?
<Keybuk> yes
<psusi> k.. I'll do that then call for testers
<ChogyDan> RAOF: hey there, just leaving a note that it looks like 625280 might break upgrades from lucid->maverick.  The lucid package now outversions the maverick package
<soren> If I want to patch Plymouth, do I have to push the changes to lp:ubuntu/plymouth first?
<soren> I found dealing with that bzr branch very confusing. Apparantly, all the patches are already applied, but there's no .pc directory, so I don't know how to quilt push/pop and such.
<lifeless> soren: bzr log ? :)
<soren> lifeless: Hmm.. Yes, I guess that does hold the answer my question :) I'm still puzzled how I can work with quilt patches in there, though.
<soren> Or perhaps I'm misunderstanding the error message I get when I try to quilt push -a.
<lifeless> does the package already use quilt ?
<soren> Every single patch fails to apply, apparantly.
<soren> lifeless: Yes.
<soren> ...and I somehow thought that was because they were already applied, but I also can't reverse apply them in reverse order, so this is even more confusing.
<soren> meh
<lifeless> gl
<tim> hi ... how do i create a source package? git-buildpackage only creates a binary package for me ..
<debfx> tim: git-buildpackage -S
<tim> debfx: thanks!
<tim> hm ... using dpkg-buildpackage, how can i force the creation of the orig tarball?
<ogra> the orig tarball is the original upstream source tarball
<ogra> dpkg-buildpackage does not create it, you have to do that
<tim> orga, ok ... but then, how can i include it for a launchpad upload?
<ogra> you take the original tarball you downloaded for the project and name it <sourcepackage name>_<upstream version>.orig.tar.gz in the dir above your package source tree
<mr_pouit> you can also force with -sa (see men dpkg-genchanges)
<mr_pouit> s/men/man/
<ogra> mr_pouit, that will create a native package
<soren> ogra: Uh... No, it won't?
<mr_pouit> ogra: well, I don't know, it's still possible that it's e.g. xxx-2ubuntu1, in which case dpkg-genchanges wouldn't include the orig
<soren> -sa means "always include orig tarball, even if the version number suggests that it's already in the repository".
<ogra> soren, ?? since when ? -sa means only "attach source"
<ogra> right
<soren> ogra: Since I started using dpkg-buildpackage.
<ogra> it doesnt *create* it
<soren> ogra: Oh, sure.
<soren> ogra: Oh, right,I see what you're saying.
<ogra> it only adds it to dsc and changes so it gets uploaded alongside
<soren> Ok, so adding your advice up, you're right..
<mr_pouit> but I read his second question as "how to include it in the .changes anyway?"
<soren> But individually, you're not :) It's not necessarily enough that the orig tarballs is there and is named correctly.
<ogra> well, if it already exists -sa is definitely needed for a first upload
<soren> The tarball has to be there, and to be sure it gets included, you have to pass -sa.
<ogra> <tim> hm ... using dpkg-buildpackage, how can i force the creation of the orig tarball?
<ogra> that doesnt suggest that it exists yet though
<soren> True indeed.
<ogra> :)
<soren> I'm just saying (or trying to say) that finding the tarball and naming it the rigth way doesn't necessarily mean it gets included in his upload.
<ogra> yeah
<ogra> thats the second step indeed
<ogra> there you need .sa
<ogra> *-sa
<tim> ok ... then how do i sign the *upload file manually?
<soren> The upload file doesn't get signed. The .dsc and .changes do.
<ogra> dpkg-buildpackage -S should offer that to you automatically
<ogra> err, right
<ogra> what soren said
<ogra> .upload is effectively only the stamp for a successfull upload
<tim> ok, answering all my questions: the -sa flag adds the orig.tar.gz file to the .changes
<tim> but it is passed from git-buildpackage to dpkg-buildpackage to dpkg-genchanges
<ogra> right
<tim> wonderful
 * ogra doesnt know git-buildpackage ... 
<ogra> i stay away from git as far as i can :)
<tim> it is very annoying that one program has flags, which are not documented in the man pages
<tim> -sa is neither documented in git-buildpackage nor in dpkg-buildpackage
<tim> the manpage of dpkg-buildpackage tells just tells, that it is passed to dpkg-genchanges
<ogra> it is point 7 in the dpkg-buildpackage manpage
<ogra> might not be 100% obvious on first sight though
<tim> ... now when searching for a specific option, in manpage 1 it won't search in manpage 2
<ogra> file a whishlist bug for nested searching in man then ;)
<penguin42> tim: I have some sympathy; I spent an hour before I got out of the office last night fighting this
<tim> quite annoying if you just build a new package every few months
<penguin42> yeh
<tim> well ... rant is over ... will need to go to work now ...
<tim> anyway ... thanks for the help!
<trudell> hi guys
<trudell> i and a lot of users thinks that is important a mplayer compiled with midi support
<trudell> so mplayer-plugin needs mplayer with midi support and timidity plugin to run midi files from web browser
<trudell> but is out in kubuntu compilation
<trudell> i compiled my own version of mplayer, but is incompatible with smplayer
<trudell> so, developers here thinks about mplayer compiled with midi support and timidity plugin for mplayer
<trudell> if not, how i can compile the same version used in ubuntu with midi support?
<shadeslayer> kees: around? can you have a look at bug 702026 ?
<ubottu> Launchpad bug 702026 in dcmtk (Ubuntu) "[MIR] dcmtk" [Undecided,In progress] https://launchpad.net/bugs/702026
<bdrung> kirkland: please unsubscribe ubuntu-sponsors once you uploaded the package
<killown> I've been having this problem with flash 10.2 on ubuntu, basically if I have a youtube video open it is still shown even when It's been closed or if I scroll off the page. However weirdly it only shows on the black parts of my screen, for example a black picture will show a perfect picture of the youtube player with the last video I watched, even if I close the video (and firefox), please ubuntu devels make a flash 10.1 package and purge this
<killown>  10.2 buls***
<persia> Or, for that matter, if there's some reason it can't/shouldn't be uploaded (e.g. you committed upstream, or the proposed "fix" isn't actually any sort of codefix, etc.)
<kklimonda> hey, would that be unthinkable to bundle some library with Transmission, and link to it statically for natty?
<hallyn> is anyone else having trouble in natty as of latest upgrade with update-grub hanging?
<hallyn> oooooh
<hallyn> f
<hallyn> It's cause /dev/nbd01 exists
<hallyn> never mind :)
<kklimonda> That's how Transmission developers did that in the past - bundling the version of libevent they required, as distributions didn't provide an updated version, but then we've managed to update it, and they have dropped the bundled version. But now we are in the same situation, as we may not be able to update libevent to the new version, and it's not installable in parallel with the old one.
<trudell> i and a lot of users thinks that is important a mplayer compiled with midi support
<trudell> so mplayer-plugin needs mplayer with midi support and timidity plugin to run midi files from web browser
<trudell> but is out in kubuntu compilation
<trudell> so, developers here thinks about mplayer compiled with midi support and timidity plugin for mplayer
<trudell> i compiled my own version of mplayer, but is incompatible with smplayer
<kklimonda> trudell: have you tried asking someone, for example siretart, for the reason why is midi support in mplayer disabled?
<cjwatson> also, it isn't manageable for everyone to report bugs (or change/enhancement requests or whatever) on IRC.  could you please use the bug tracking system instead?
<trudell> kklimonad: nope. Why reason, do you know?
<trudell> siretart: why reason midi support and timidity plugin for mplayer are disabled?
<bdrung> tumbleweed: around?
<trudell> why reason midi support and timidity plugin for mplayer are disabled? anyone knows?
<trudell> can developers change this custom?
<trudell> abiliting the midi support?
<kklimonda> trudell: just broadcasting the question, in the middle of the weekend, won't get you the answer any faster. You can try ubuntu-devel-discuss mailing list.
<trudell> kklimonda: have you the adress of ubuntu-devel-discuss?
<kklimonda> !list
<ubottu> This is not a file sharing channel (or network); be sure to read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â»
<kklimonda> hmm
<kklimonda> trudell: check https://lists.ubuntu.com/
<trudell> kklimonda: thx so much for your attention, i will come back in the middle of week to talk with siretart or another developer
<cjwatson> trudell: and like I say, the bug tracking system is more appropriate anyway
<trudell> do you know where i can do suggestions to kubuntu developers?
<cjwatson> file a bug
<cjwatson> better than trying to get a developer's attention when they may be working on something else; a bug report means that it will be queued, not forgotten
<trudell> bugtracking? have bug in mplayer's midi support?
<cjwatson> we use the bug tracking system for enhancement requests as well as for actual bugs
<cjwatson> "please enable MIDI support in mplayer" is a reasonable enhancement request (assuming you've already done due diligence in searching the web to see that it hasn't already come up)
<trudell> can developers get users suggestions through bur-report?
<trudell> *bug-report
<cjwatson> yes
<trudell> yeah, me and a lot of users
<trudell> and have not affect any function if enabled
<cjwatson> IRC is not appropriate for this
<trudell> sorry, i'm newbie
<cjwatson> most of the developers on this channel don't do anything related to mplayer
<cjwatson> the bug tracking system allows messages to be directed to developers who are interested in the topic in question
<cjwatson> rather than broadcast to everyone on the channel
<trudell> alright, thx
<bdrung> tumbleweed: u-d-t build failure fixed
<kees> shadeslayer: what can I help with on that bug?
<ImGangsta> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<ImGangsta> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<sebner> ImGangsta: ??
<ImGangsta> Im gangsta
<sebner> rofl
<iulian> o_O
<kirkland> bdrung: why?
<kirkland> bdrung: the bug should be closed at that point
<kirkland> bdrung: if there's more traffic on the bug after that, then ubuntu-sponsors should be aware
<bdrung> kirkland: not for SRUs
<bdrung> kirkland: the usual work flow is to unsubscribe ubuntu-sponsor and subscribe yourself
<shadeslayer> kees: https://bugs.launchpad.net/ubuntu/+source/dcmtk/+bug/702026/comments/1 << :)
<ubottu> Ubuntu bug 702026 in dcmtk (Ubuntu) "[MIR] dcmtk" [Undecided,In progress]
<ScottK> lamont: Any chance for postfix 2.8.0 this weekend?  We're getting close to feature freeze ...
<kees> shadeslayer: oh, hey, I missed me. (I was already subscribed via MIR so I didn't notice, and got distracted by the compilation failure discussion.) heh
<kees> shadeslayer: yeah, I'll look at it, thanks!
<shadeslayer> ;)
<shadeslayer> thanks! :)
<kklimonda> hmm, any idea if there is a way to download all maintainer scripts for all packages in Ubuntu?
<ari-tczew> kklimonda: apt-get source ubuntu-dev-tools devscripts ?
<kklimonda> ari-tczew: I was thinking about package maintainer scripts (postinst, prerm etc.)
<nhandler> kklimonda: There isn't an easy way to get all of the maintainer scripts (not quite sure why you would want to do that). You could probably hack something together (but it would probably involve downloading all the source packages and checking if they have maintainer scripts)
<kklimonda> I can probably limit it to downloading only .diff.gz/debian.tar.gz files
<kklimonda> to download*
<kklimonda> as for why - I'm interested what are main uses of those scripts, how many packages use them, how many of them are used by standalone desktop applications for something else then updating various databases
<geser> kklimonda: are you only interested in manual written ones? dh_* may create maintainer scripts but you don't see a trace in .diff.gz/debian.tar.gz
<geser> looks like you need a ubuntu mirror and extract all maintainer scripts from the .debs
<kklimonda> geser: yes, I only care about ones written by maintainers, not those automagically generated
<lamont> ScottK: I'll make time for 2.8.0 this weekend, though it might be monday before an upload
<ScottK> lamont: Cool.  I think a lot of people will want to give postcreen a shot.
<ohsix> whats needed in checkbox so pulseaudio's package can go with flat-volumes on? (the problems are down to broken drivers w/invalid information, lots have been fixed since 9.04)
<ImGangsta> Im gangsta
<ImGangsta> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<ImGangsta> !ops
<ImGangsta> !ops
<ImGangsta> hey bitch
<ImGangsta> im gangsta
<siretart> kklimonda: if trudell appears again: patches welcome! :-)
<Dr_Who> anyone creating seeds with germinate will want to know about bug #717879
<ubottu> Launchpad bug 717879 in germinate (Ubuntu) "germinate should not examine all components in PPAs" [Undecided,New] https://launchpad.net/bugs/717879
<penguin42> does anyone know if Natty's use of log files has purposely changed or is my empty /v/l/messages a bug ?
<ScottK> penguin42: There were some changes.  I don't think it's a bug, but I'm not sure.
<penguin42> I think everyone is in that boat :-)
<penguin42> the stanza for catch-all log files is commented out in /etc/rsyslogd.d/50-default.conf
<penguin42> ah
<penguin42> changelog comments say it's on purpose
<penguin42> 'Disable redundant and non-synchonous log files by default (this will only affect new installations), to reduce disk size overhead and unnecessary wakeups and IO'
<penguin42> hmm not a new installation, but still
<ion> I liked that change. I never liked the redundant log files that each received a slightly different set of lines.
<psusi> indeed
<penguin42> yeh probably not a bad idea - might take me a while to actually figure out where to look; I've been looking at /v/l/messages for about 15 years
<broder> penguin42: /var/log/syslog has always had more than /var/log/messages on debian/ubuntu
#ubuntu-devel 2011-02-13
<aroman> hey guys, I'm trying to remaster an Ubuntu ISO, and I'm getting this error running my remaster script: cryptsetup: WARNING: could not determine root device from /etc/fstab. i'm convinced that's what's causing me to drop to Busybox when I try and boot the remastered ISO Am I wrong?
<gaurav_pawaskar> Hi All, This is Gaurav, I am new to Ubuntu and want to do development towards Ubuntu. I am in search of mentor for my initial stage in Ubuntu. Any one available to Mentor me?
<persia> gaurav_pawaskar, If nobody offers, you might start by trying to fix some bugs or helping coordinate submitted patches.  Questions about the process asked generally here tend to be answered (although not always by the same person).
<gaurav_pawaskar> persia, yes actually I am not aware of coding process. any initial help will surely help me.
<persia> gaurav_pawaskar, There's lots of ways to do it.  The general overview seems to be something like: identify thing to fix, grab source for thing to fix, fix, build locally and test, upload (initially through a sponsor).
<persia> So the first thing to do is usually try to identify something that ought to be changed, where you understand the problem.
<gaurav_pawaskar> okey, I also want to know from where you get code. and also few debugging tips or tools if any available
<persia> The two most common ways to get the code are 1) `apt-get source ${PACKAGE}` and 2) `bzr branch lp:ubuntu/${PACKAGE}`
<persia> For debugging: it depends far too much on the specific problem.  You could spend a long time learning about strace and ptrace and gdb and similar, but you may do just as well to dive into something, and learn the tools as you need to use them.
<gaurav_pawaskar> ok..sure.. can I find some person from this team to assist him with development or a point of contact to me. so that i can ask him some frequent doubts.
<persia> Yes, some folk act as mentors: someone may still respond to your query above.
<persia> But until someone does, feel free to just ask questions here (or, if you end up working in some specific area of ubuntu, the appropriate channel).
<gaurav_pawaskar> yes sure..thnx alot.. persia..
<ohsix> agh, synaptic doesn't heed preferences.d? just got a pile of natty packages installed from some auto action
<kostmo> What is the name of the "Sound Preferences" app so I can play with the code?
<micahg> kostmo: xprop | grep CLASS <-- then click on the pref window
<kostmo> gnome-volume-control
<kostmo> awesome, thanks
<kostmo> I'm going to try to implement this brainstorm idea: http://brainstorm.ubuntu.com/idea/23754/
<kostmo> using this applet: http://code.google.com/p/gnome-pulse-applet/
<kostmo> turns out I needed to "apt-get source gnome-media"
<newage15> anyone tried Natty daily 20110210?
<hyperair> ohsix: it doesn't, unfortunately. i think there's a bug filed on that
<hyperair> same goes for aptitude
<hyperair> no wait, i thought synaptic read preferences.d, but not aptitue
<e01> is it possible to using the NVidia driver from the nvidia`s site in natty?
<e01> because when i just installed the nvidia-current, i see that the aptitude remove the xorg, when i was try to build it manually, the X just won`t start, i see that something wrong with the abi, but don`t know what exactly is
<ari-tczew> e01: compile it?
<persia> That's tricky, as the source isn't available.
<e01> :D
<e01> yes but, when you installing it, the installer show message something like "building the driver" :)
<persia> e01, The Application Binary Interface doesn't match: nVidia needs to recompile it.
<persia> Anyway, #ubuntu+1 is a better channel to ask that sort of question
<ari-tczew> e01: https://launchpad.net/~ubuntu-x-swat/+archive/x-updates there are some testing packages (unstable)
<e01> ari-tczew, will test thsi
<gaurav_pawaskar1> hi Guys. Can anyone help me finding my first bug to fix?
<vish> gaurav_pawaskar1: what do you mean "finding"?  you fixed a bug and are now looking for the bug # ?
<vish> err, nevermind
<gaurav_pawaskar1> I am looking for a bug then fix it.
<vish> i read that whole thing wrong.. :)
<gaurav_pawaskar1> I am new here and need some help initially :)
 * vish skipped over the "to" and read as  "first bug fix" 
<gaurav_pawaskar1> ok :)
<vish> gaurav_pawaskar1: you can start with Unity bitesize bugs or papercuts, both of which are easier
<gaurav_pawaskar1> vish: Do you have any link where can I see them?
<vish> gaurav_pawaskar1: https://wiki.ubuntu.com/PaperCut and https://bugs.launchpad.net/hundredpapercuts/+bugs?field.status%3Alist=TRIAGED |  Bitesize : http://goo.gl/i1WA1 and http://goo.gl/tiheb
<kirkland> when did Ubuntu switch the default to grub2?
<charlie-tca> 9.10 or 10.04?
<hallyn> good q - i had thought lucid, not karmic, but might be wrong
<hallyn> kirkland: as i assume i know what you're talking about with whom, the other relevant bug is https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/717445
<ubottu> Ubuntu bug 717445 in grub2 (Ubuntu) "grub2 in lucid doesn't work in qemu with '-vga std'" [Undecided,New]
<kirkland> hallyn: howdy
 * hallyn back in a minute - assuming reboot works
<kirkland> hallyn: yup, all 3 of us are online
<kirkland> hallyn: charlie-tca: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-June/000573.html
<kirkland> looks like karmic
<arand> https://help.ubuntu.com/community/Grub2 says 9.10 as well
<kirkland> hallyn: you back?
<hallyn> kirkland: briefly
<hallyn> kirkland: ad-hoc wireless support kicking my butt :)
<kirkland> hallyn: :-(
<hallyn> kirkland: the grub2 src has changed so much for natty, i'm not sure how to approach the vga std thing
<hallyn> was hoping cjwatson will have tricks to share next week
<hallyn> though i suppose i'll resort to printf debugging
<kirkland> hallyn: okay;  aliguori and i are debugging right now
<hallyn> did you have ideas?
<hallyn> oh, cool
<kirkland> hallyn: well, just wanted to get the reproduce case down to as simple as possible
<kirkland> hallyn: so i'm going to create a base lucid desktop image that reproduces the problem
<kirkland> hallyn: zip it up somewhere
<cjwatson> hallyn: as I said a couple of days ago, I would recommend starting by executing commands from the configuration file one by one and seeing where it breaks
<cjwatson> it's malloc arena corruption so the failure may be distant from the cause
<cjwatson> see if it reproduces with a grub-mkrescue image
<cjwatson> that's much smaller and much easier to work with
<cjwatson> you might need to take a grub-mkrescue image and execute commands manually from the normal desktop grub.cfg
<cjwatson> (grub-mkrescue from the appropriate release, of course)
<hallyn> kirkland: ^ will try tonight if you havven't
<kirkland> hallyn: cool
<kirkland> hallyn: also, qemu-kvm 0.14-rc1 is out
<kirkland> hallyn: came out Wednesday
<kirkland> hallyn: need to get that merged for Natty
<hallyn> kirkland: uscan will only recognize 0.14.0.  do you want me o manually merge the prerelease?
<kirkland> hallyn: yeah
<hallyn> ok
<kirkland> hallyn: that's what i usually do
<kirkland> hallyn: better to get the rc in, in case there's something
<hallyn> cool, will do
<kirkland> cjwatson: any chance you're still around?  aliguori is helping us with that grub2/qemu issue
<kirkland> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/717445 fwiw
<ubottu> Ubuntu bug 717445 in grub2 (Ubuntu Karmic) "grub2 in lucid doesn't work in qemu with '-vga std'" [Medium,New]
<kirkland> cjwatson: aliguori says, "Removing 'insmod gfxterm' and 'insmod vbe' let's the guest boot up."
<aliguori> yeah, i don't know why video mode probing is failing
<aliguori> i need to add some debug code to grub and start trying to see where things fail
<aliguori> cjwatson, any hints to ease debugging?  doesn't look like there's much logging in grub2 in this path unfortunately
<ohsix> hyperair: dang, aptitude only just got a patch for natty; maybe synaptic can be looked at too, i just did a reinstall and was trying to break my preferences apart but i guess i still have to wait :D
<hyperair> hmm
<hyperair> ohsix: you could have a cronjob that does cat /etc/apt/preferences.d/* > /etc/apt/preferences
<hyperair> ;-)
<ohsix> i'll just edit them in place, thankfully it's only a pin for firefox and aptitude so far; and i don't see having more than 8 or so ever
<ohsix> looking at synaptic bugs,  it looks like it uses its own preferences file to do pinning/forbids too
<ohsix> if they'd only put it in preferences.d and called it 99synaptic or something, it'd work all around D:
<ohsix> heh the bug linked from launchpad is from 2004
<ohsix> apparently before then it worked the other way, using global prefs; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276655
<cjwatson> kirkland,aliguori: debugging video init is a right pain, I usually use grub_env_set to leave myself messages for when I can inspect them
<cjwatson> kirkland,aliguori: but if you just find a way I can reproduce this with grub-mkrescue, I'll look at it tomorrow
<ari-tczew> cjwatson: did you see my message on lilo merge bug?
<cjwatson> ari-tczew: bugmail doesn't sound like a happy fun weekend activity
<lifeless> cjwatson: the curse of the working man
<jo-erlend> I thought perhaps someone here would know what to do with this. http://packages.ubuntu.com/ has links to older releases, but it doesn't look like it's possible to actually browse those releases.
<jo-erlend> in this case, I was wondering which version of libboost-dev was included in jaunty, but I couldn't find it. If anyone knows, or knows an easy way to find it, I'd appreciate it. But the packages-site should be fixed.
<jo-erlend> in other words: jaunty should've been removed, but it still has a link to browse the list of packages, and it's still in the distribution drop-down list for searches.
<cannonfodder> hey you guys...i just got high right now and my adhd got out of the way and now i feel like becoming an active developer lol. i just want to know whats a good way to learn about a program? how do you guys do it?
<cannonfodder> do you download source files of a program you want to work with?
<cannonfodder> and do they come with readme's?
<cannonfodder> or some form of documentation or information?
<cannonfodder> do the files come in a certain directory structure with a main index file i can open in my editor and dive right into?
<cjwatson> jo-erlend: find the source package name, then go to https://launchpad.net/ubuntu/+source/SOURCEPACKAGENAME/+publishinghistory
<cjwatson> cannonfodder: varies, the most important skill is adaptability
<dupondje> https://bugs.launchpad.net/ubuntu/+source/clutter-1.0/+bug/714280
<dupondje> this seems a crap bug :(
<ubottu> Ubuntu bug 714280 in clutter-1.0 (Ubuntu) "The error was 'BadLength (poly request too large or internal Xlib length erro'." [High,Confirmed]
<bcurtiswx> in gtk file, whats echo ?
<bcurtiswx> just echo?
<broder> bcurtiswx: huh? what do you mean by a "gtk file"?
<bcurtiswx> sorry, its a .c file
<bcurtiswx> so nvm
<bcurtiswx> printf
#ubuntu-devel 2012-02-06
<jtaylor> works for me too 11.10
<stgraber> it doesn't seem true for /proc/1/cmdline here though (not null terminated)
<tumbleweed> 1 is rather special...
<tumbleweed> on Debian, it's very null-terminated :P http://paste.ubuntu.com/830783/
<stgraber> ;)
<cargo23_> http://paste.ubuntu.com/830791/
<cargo23_> from man proc:   The command-line arguments appear in this file as a set of strings separated by null bytes ('\0')
<cargo23_> Is there a better forum for this question?
<cargo23_> I'm new to working with the procfs, for sure.
<cargo23_> It is supposed to contain nulls, not just end with them?
<tumbleweed> I assume that's the result of chrome modifying argv itself for cosmetic reasons, and not null-terminating, but that's a whild guess
<stgraber> cargo23_: http://paste.ubuntu.com/830815/ is an example of how to mess with cmdline taken from rdesktop's code, this specific example only overwrites the value passed after -p but you can certainly mess with the whole cmdline if you want
<stgraber> oh, ignore that printf, was there for debugging purpose ;)
<cjohnston> the lpupdate was
<pitti> Good morning
<slangasek> doko: well, this is why MIR bugs are supposed to be left open until an archive admin reconciles it against component-mismatches :)
<dholbach> good morning
<fishor> hallo devs! are there any way to have this patch included with precises xserver?  https://bugs.freedesktop.org/show_bug.cgi?id=41115
<ubottu> Freedesktop bug 41115 in Server/General "Please add option to avoid forcing of 96dpi" [Enhancement,New: ]
<RAOF> fishor: Maybe.  Can you please file a launchpad bug to track that?
<fishor> RAOF, there is one long standing bug report here: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/589485
<ubottu> Ubuntu bug 589485 in xorg-server (Ubuntu) "Ignores physical display size and calculates based on 96DPI" [Low,Confirmed]
<RAOF> Oh, yeah.  That's right.
<RAOF> Sorry.
<fishor> no problem. i can thest the patch with precise xorg, but i wont te be sure it will be added to the package
<fishor> i never had problems with my old lcd screen, but with new laptop it is really bad
<RAOF> What's actually looking at that DPI value, anyway?
<RAOF> (IIRC both GNOME and KDE ignore it, as does Firefox)
<fishor> RAOF, it is probably just part of the problem. i just started to digg in  issue. first i found is xorg and xdpyinfo show different sizes.
<RAOF> You can make GNOME use the right DPI in gnome-tweak-tool (fonts).
<RAOF> As you go up the stack, you'll continue to hit the same reasons that Xorg has - physical DPI isn't actually the number that you're after; you actually want a number based on physical DPI and the distance you are from the screen.
<fishor> how about other issue. for example libreoffice show page in 100% size double as small as it should be
<RAOF> If libreoffice wants to show at the correct size it should be getting the per-output numbers (which are, and have always been, correct and available through xrandr).
<RAOF> Because otherwise it'll break in not-too-uncommon circumstances anyway, like having two monitors.
 * RAOF -
 * RAOF â dinner
<fishor> yea... i have two monitores .. the external has physical dpi ~96, the internal is about 138dpi
<fishor> i should probably give this laptop to some dev who argumenting against it :) he should burn his eyes
<pitti> jibel: thanks for the apt verification in lucid! I'm not quite sure whether that tested the release-upgrader-apt "special" package or the general apt
<cjwatson> pitti: jenkins tests the release-upgrader-* packages, effectively
<pitti> cjwatson: thanks, what I thought; for apt itself we'd need to check apt-get dist-upgrade supposedly?
<pitti> cjwatson: I'm fine with moving r-u-apt to -updates now, unless you want to wait for the full 7 days
<cjwatson> yes, and makes sense
<pitti> jibel: nice to see that the post-upgrade conf tests all succeed nwo
<pitti> now
<dholbach> blueyed, Happy Birthday! :)
<pitti> Riddell, ScottK, debfx: okular was removed in Debian, "superseeded by kdegraphics/experimental"; should we follow suit?
<Riddell> umm no
<Riddell> tsdgeos: ^^ eh?
<tsdgeos> lol
<tsdgeos> kdegraphics/experimental?
 * pitti keeps gwenview as well, got repackaged in Debian
<tsdgeos> what's that?
<tsdgeos> we don't even have a proper kdegraphics package anymore
<Riddell> pitti: got a bug number or other reference?
<pitti> debian bug 515827
<ubottu> Debian bug 515827 in ftp.debian.org "RM: okular -- RoM; superseeded by kdegraphics/experimental" [Normal,Open] http://bugs.debian.org/515827
<pitti> I figure we just have a different packaging
<pitti> it's nothing urgent at all, it just came up in process-removals
<tsdgeos> 2009 ?
<Riddell> pitti: "Date: Tue, 17 Feb 2009 21:22:59 +0100"
<Riddell> it will have reappeared in process-removals because "okular" source package reappeared
<Riddell> blacklist it from process-removals
<pitti> I'll just ignore it then, together with the other KDEish packages
<pitti> seems it's all right then
<jibel> pitti, the conf test is still failing for desktop but hidden. Currently the upgrade testing system doesn't have the granularity to run a test with different settings depending on the profile.
<jibel> but I'll find a way to fix that
<pitti> jibel: oh? I looked at the lucid->precise desktop upgrade log, and they all succeeded
<jibel> pitti, they do but this prompt https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/18/artifact/lts-ubuntu-amd64/debconf.log shouldn't be there
<pitti> jibel: aah
<pitti> jibel: so it's not the lts-{user,system}.py stuff that's failing, but a debconf question
<jibel> pitti, right
<jibel> what is the expected behavior of the upgrader when a package is upgraded from lucid/main to precise/universe ? keep at the same version, upgrade, something else ?
<jibel> mvo, ^
<pitti> mvo: if you have universe enabled, upgrade
<pitti> if not, the package will behave as it disappeared entirely, so it shuold be kept
<pitti> but usually we should keep the transitional packages in main
<pitti> we often don't
<pitti> we need to seed them explicitly, otherwise they fall out
<pitti> I guess we'd need an upgrade test with not enabling universe in lucid, and then dist-upgrading
<tjaalton> TREllis: \o/ thanks for replying to the ESR thread :)
<tjaalton> now how do I force-enable enigmail..
<TREllis> tjaalton: no problem, not sure if there is an issue shipping it in universe
<TREllis> tjaalton: 12.04 thunderbird update knocked out your plugins?
<tjaalton> TREllis: yep, enigmail, lightning and mail redirect
<TREllis> tjaalton: same story for me :)
<tjaalton> TREllis: "disable compatibility check" addon
<TREllis> tjaalton: ah-ha!
<tjaalton> I saw that enigmail should work with 11 just fine
<Sweetshark> infinity: ping?
<Sweetshark> infinity: https://launchpadlibrarian.net/90605123/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.0~rc1-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz <- I need more discspace on PPA builders for LibreOffice, please.
<tjaalton> TREllis: meh, doesn't seem to work
<tjaalton> enigmail 1.3.5 that is
<TREllis> tjaalton: yeah fails for me too on lightning, I can probably grab the latest builds manually, but slightly annoying
<tjaalton> TREllis: trying enigmail nightly, something weird with that also
<tjaalton> doesn't find /usr/bin/gpg for starters
<tjaalton> and lightning fails too yes
<tjaalton> was nice using them for a week or two :)
<tjaalton> oh nice, I have tbird 10 packages on the hd
 * tjaalton downgrades
<pitti> slangasek: openssl098 was removed in Debian, and I guess for LTS we want the same; the only rdepends is ia32-libs-multiarch, I figure we can drop it there?
<cjwatson> pitti: hmm
<cjwatson> pitti: I thought it would be a good idea to keep it as it's a common thing found in linkage of third-party binaries
<cjwatson> seems like a likely audience for ia32-libs too ...
<pitti> it's in universe, so by the letter we aren't committed to security support
<pitti> but in practice I guess we'll have to anyway
<pitti> if programs are actually using it still
<cjwatson> I don't know that for sure, but given the sheer number of things we had to port to 1.0.0 in Debian/Ubuntu proper, I'd be surprised if there were none outside
<cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/openssl.html
<diwic> dholbach, hi!
<dholbach> hi diwic
<diwic> dholbach, the wiki page https://help.ubuntu.com/community/SoundTroubleshootingProcedure is completely crazy and you're more likely to destroy your sound stack than to fix it if you use the instructions.
<diwic> dholbach, yet someone seems to maintain it
<diwic> dholbach, what is the suggested course of action?
<dholbach> diwic, it might be worth talking to the folks in #ubuntu-doc
<dholbach> AFAIK they take care of help.u.c
<diwic> dholbach, hmm, I'll try asking the same question there
<jibel> pitti, I think dist-upgrader in Precise must be updated to the right version of libapt-inst and libapt-pkg in Lucid
<pitti> mvo: ^ ?
<cjwatson> jibel: hmm?
<jibel> when I run a do-release-upgrade in lucid I get
<jibel> ImportError: libapt-pkg.so.4.12: cannot open shared object file: No such file or directory
<cjwatson> uh, I don't
<cjwatson> isn't that what we just promoted to lucid-updates?
<cjwatson> unless you mean
<cjwatson> DistUpgrade/DistUpgrade.cfg.lucid:Packages=libapt-pkg4.11,libapt-inst1.3,release-upgrader-python-apt
<cjwatson> I don't know how much difference that makes since release-upgrader-python-apt should pull in the right versions by dependencies anyway
<cjwatson> hm, it does make a difference for the CD though, at least - I'll update that
<jibel> maybe that's just a matter of waiting. I'll retry in a bit.
<mvo> jibel: hello, it should pick out the latest version of the release-upgrader-backport packages, but I missed some context so I'm not sure if that is a reasonable answer
<mvo> jibel: I will read scrollback, on my way to lunch
<TREllis> tjaalton: hmmm yeah, after a fresh restart the plugins would start but issues all over the place with them... so leaving disabled for now
<tjaalton> TREllis: you can grab the old one here https://launchpad.net/ubuntu/+source/thunderbird/10.0+build1-0ubuntu1
<TREllis> tjaalton: ty
<TREllis> tjaalton: yep, that worked like a charm. I wish we could link the thunderbird builds to the xul plugins :)
<cjwatson> jibel: well, I've uploaded a new u-m now which will hopefully help
<infinity> Sweetshark: Not my area anymore, you want lamont.
<Sweetshark> lamont: https://launchpadlibrarian.net/90605123/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.0~rc1-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz <- I need more discspace on PPA builders for LibreOffice, please.
<gnuoy> Sweetshark, whats the ppa ?
<Sweetshark> gnuoy: https://launchpad.net/~libreoffice/+archive/ppa
<gnuoy> Sweetshark, how much additional space are you after?
<Sweetshark> gnuoy: dunno :( -- enough to build LO.
<ogra_> 3TB ?
<ogra_> :)
<Sweetshark> gnuoy: it is failing rather late, so it shouldnt be too much additional space.
<geser> wow, 26 GB aren't enough to build LO?
 * ogra_ hopes geser gets that he wasnt serious :)
<ogra_> you need 3TB RAM though :P
<geser> now I know why disk space steadily increases and cpus get faster: to keep be able to build LO
<gnuoy> Sweetshark, I've increased the limit from 10Gb to 15Gb
<geser> gnuoy: I doubt he meant the PPA space but the buildd disk space used by PPA builders
<ogra_> most likely (if lamont is involved)
<geser> but that would probably still be needed soon
<gnuoy> geser, ah, ok
<mvo> jibel: oh, its a new ABI - in this case this needs updating, but I saw that colin did it already (thanks for that)
<geser> gnuoy: from the build log: "Build needed 09:28:17, 25995940k disk space" and it died with "IO error: write error during copy : No space left on device"
<infinity> gnuoy: Yeah, this one requires the actual PPA Xen images being rebootstrapped.  It might actually be a Spads thing, not a lamont thing, but I've lost track of who does what since I left IS.
<infinity> (Well, it's possible one could fudge it by just expanding the image on a few machines)
<gnuoy> infinity, ok, let me find out
<lamont> increasing that disk space is going to be somewhat problematic, I suspect.  When the kernel smacked into it a while back, they taught their build to remove intermediate copies of things
<infinity> lamont: Do we actually still have PPAs with disks that small?  Seems unlikely.  I imagine the airlock could just have the limit bumped.
<lamont> 72GB drive yields about 26GB of usable space for the ppa builder
<infinity> And we still have some 72G ones?  Fair enough.
<lamont> many
<infinity> Shame.
<infinity> Oh, wait.  But the airlock didn't use set sizes, did it, it did percentages?
<infinity> So, one could manually throw LibO at a machine with more disk.
<infinity> Pain in the butt, but doable.
 * lamont notes that allspice, one of the newest in the fleet, has a 72GB drive
<cjwatson> mvo: have you had any further thoughts on https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034694.html ?  Would you like me to try to construct a non-ABI-breaking backport?  (Not sure I know how immediately, but ...)
<herton> pitti, hi, can you or other archive admin copy linux-meta 2.6.35.32.42 and linux-backports-modules-3.0.0 3.0.0-16.9 from ckt-ppa to -proposed? We detected 2 bugs which we would like to address in current SRU cycle.
<Sweetshark> gnuoy: thx, retriggering the builds
<mvo> cjwatson: sorry, on the phone right now
<jibel> cjohnston, u-m update fixed the problem. thanks
<cjwatson> jibel: excellent
<mvo> jibel: the ordering bug from last week?
<mvo> cjwatson: I will attack that right after the call
<pitti> herton: done
<herton> pitti, thanks
<cjwatson> mvo: great, thanks
<pitti> jibel: hm, I can't find a bug report for the qdbus <-> libqt4-dbus cyclic dependency; does that ring a bell for you (i. e. I'm too dense to search), or shall I report it?
<pitti> jibel: (lucid->precise universe upgrade failure)
<jibel> pitti, I didn't file a bug for this issue and haven't found one on LP
<pitti> jibel: thanks; doing now
<jibel> pitti, lucid -> precise main is interesting, the test passes but actually the system is not really upgraded
<jibel> pitti, most packages are removed or kept at the same version
<jibel> https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-main/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/13/artifact/lts-main-all-amd64/main.log
<pitti> jibel: eww -- that might be an apt regression?
<pitti> mvo: ^ did you ever see this?
<jdstrand_> cjwatson: is http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ still the most up to date version of the ubuntu policy manual?
<jdstrand> cjwatson: hello btw :)
<pitti> Riddell, debfx: are you ok with me doing an upload for bug 927637?
<ubottu> Launchpad bug 927637 in qt4-x11 (Ubuntu Precise) "upgrade failure: qdbus and libqt4-dbus cyclic dependency" [High,Triaged] https://launchpad.net/bugs/927637
<pitti> i. e. dropping libqt4-dbus' Depends: qdbus
<pitti> ... turning it into a recommends, I mean
<pitti> jibel: FYI, filed as bug 927637 (if you want to apply some extra magic tags)
<ubottu> Launchpad bug 927637 in qt4-x11 (Ubuntu Precise) "upgrade failure: qdbus and libqt4-dbus cyclic dependency" [High,Fix committed] https://launchpad.net/bugs/927637
<Riddell> pitti: hang on
<Riddell> pitti: I have another change, can you commit somewhere and I'll do the other bit?
<pitti> Riddell: sure; I pushed it into the packaging branch
<Riddell> pitti: ta, I'll get onto it in a bit
<pitti> Riddell: it's certainly not _that_ urgent, but would be good if we can get this in in the next days to get to the next failure :)
<pitti> Riddell: ok, cheers!
<pitti> Riddell: nice that the branch ownership is set so that core-devs can commit
<cjwatson> jdstrand: yes, it needs me to get round to merging from debian-policy really
<jdstrand> cjwatson: ok. I noticed that 5.6.21 was different which prompted me to check
<cjwatson> jibel: hm, are you sure?  It spends 40 minutes (between 20:14:33 and 20:54:44) apparently at least trying to upgrade a lot of stuff, although I agree that there's no hint of it in apt-term.log
<cjwatson> jibel: but I wonder if this is just a logging bug ...
<cjwatson> jibel: it's a shame we don't save dpkg.log
<tedg> I have something I want to express in my packaging that I'm not sure how to do: This module isn't required, but if it is installed I need it to be a version greater than X.
<tedg> Is there a way to do that?
<cjwatson> tedg: Breaks: packagename (<< X)
<jibel> cjwatson, main.log says packages are upgraded but apt-term only show removals. and after the upgrade the new kernel is not installed.
<jibel> cjwatson, I'll add dpkg.log
<tedg> cjwatson, Ah, okay.  I thought that meant "I break them" but that can also mean "I break if" ... cool, thanks!
<cjwatson> jibel: mm, the kernel might be a special case, I wonder about something simple listed in the toupgrade list
<cjwatson> tedg: well, that's the prose description in policy, but the formal semantics are "may not be unpacked while package (<< X) is configured"
<tedg> cjwatson, Thanks again, that makes it much more clear.
<mvo> pitti, jibel: yet another call, but I have a look now at the upgrade log
<barry> cjwatson: hi
<mvo> jibel, pitti: the apt resolver log for this is 245mb big, that is in itself pretty scary
<lifeless> bug 915253
<ubottu> Launchpad bug 915253 in Unity Greeter "Synchronise mute and volume between lightdm and respective user sessions" [Medium,Triaged] https://launchpad.net/bugs/915253
<mvo> cjwatson: I put a first stab of the backport work to lp:~mvo/apt/oneiric-dpkgpm-backport
<mvo> cjwatson: I will need to carefully go over that, but I think its good, it does not include your algorithm.cc fixes yet, but that should be straightforward
<cjwatson> I put the algorithm.cc fixes in oneiric-proposed already
<mvo> awsome, thanks a bunch
<slangasek> pitti: no, openssl098 is here specifically *for* ia32-libs-multiarch
<pitti> slangasek: ack; cjwatson already explained
<slangasek> ok :)
<pitti> slangasek: I was a little worried of it being a security burden, but seems we need to keep it
<pitti> *shrug* universe
<jibel> pitti, do you know why bug 882030 is in the list of pending SRUs? this is a security update.
<ubottu> Launchpad bug 882030 in python-httplib2 (Ubuntu Oneiric) "python-httplib2 < 0.7.0 doesn't validate server certificates" [High,Confirmed] https://launchpad.net/bugs/882030
<jdstrand> jibel: I can answer that-- it is a security update, but mdeslaur wanted wider testing
<jdstrand> we do that from time to time
<lifeless> pitti: around still ?
<pitti> lifeless: yes, for another 10 mins
<lifeless> pitti: cool. Is there a separate library for backtrace/core signature generation? If not, how would you feel about having one? I want to make a clean interface for generating signatures, for reuse/plugability.
<pitti> lifeless: it's in python-apport; does it need to be "more" separate?
<lifeless> pitti: with a medium term goal of being able to have a webservice that takes an oops dict | apport dict and returns a signature
<pitti> it doesn't do anything by itself, so it should be quite harmless to install
<lifeless> pitti: yeah, it needs to be abstract - I don't want to be changing python-apport to change the logic for signature generation in launchpad, or SSO, or <...>
<pitti> and it has the full API
<lifeless> I'll have a refresher look at the python-apport code
<mdeslaur> jibel, jdstrand, pitti: sorry, I'll update the bug to make it clear it's not an SRU
<jibel> jdstrand, mdeslaur , ta
<SpamapS> Wow.. RPM still doesn't have Requires: x | y
<lifeless> SpamapS: and you are surprised ? :P
<lifeless> ev: hey there
<ev> lifeless: hiya!
<lifeless> ev: we should have another touch-base I think; I landed your patch, but I'm sure there is more :)
<ev> absolutely
<ev> when works for you?
<lifeless> is your google calendar reasonably accurate? I will poke at it..
<ev> lifeless: reasonably so
<SpamapS> lifeless: I keep a CentOS box around just to keep an eye on what the other people are doing..
<SpamapS> lifeless: I just finished packaging up byobu 5.7 for it as an exercise in curiosity. Can't say Requires: screen | tmux .. have to have a virtual provides on both of them.
<SpamapS> amazing
<kirkland> SpamapS: curious, I thought byobu was in the CentOS repos?
<kirkland> SpamapS: just not a new enough version?
<lifeless> SpamapS: different mindset for solving the problems
<lifeless> tedg: lennart?
<SpamapS> kirkland: yeah, its 4.something
<SpamapS> kirkland: and it wasn't in my yum automatically with CentOS 6.2
<SpamapS> kirkland: its in Fedora for sure, but doesn't seem to have found its way into EPEL 6
<SpamapS> kirkland: I'll submit the 5.7 packaging updates I did to Fedora if I find some time next weekend. :)
<SpamapS> kirkland: btw, Ctrl-A A doesn't send Ctrl-A in tmux mode in this one for some reason (works fine on the Ubuntu version)
 * micahg wonders where doko is
<Sweetshark> micahg: lost on the way back from FOSDEM?
<kirkland> SpamapS: ah, interesting;  okay, cool, thanks for the update
<micahg> Sweetshark: could be
<kirkland> SpamapS: btw, I stumbled on your juju byobu-classroom multi branch
<kirkland> SpamapS: I didn't look closely at it, but what's the goal?
<tedg> lifeless, Heh, no GSettings is my issue right now.  But that's a good one too.
<SpamapS> kirkland: infinite scalability for a single ajaxterm session :)
<kirkland> SpamapS: oh?  yeah, I found ajaxterm kinda sucky, in reality :-(
<kirkland> SpamapS: is it working well?
<SpamapS> kirkland: its just heavy on CPU because it has a high polling interval.. can't get around that on the web
<SpamapS> kirkland: I had it working in PoC .. very simple really
<kirkland> SpamapS: neat
<SpamapS> kirkland: just ssh's to the "main" node instead of locally
<kirkland> SpamapS: I used a cc2_8xlarge for my dev week session last week :-)
<kirkland> SpamapS: 32x cpus :-)
<SpamapS> kirkland: yeah thats the simple choice. I want to see if we can do a big class on 8 m1.smalls
<kirkland> SpamapS: neat
<SpamapS> kirkland: have to setup haproxy to do session persistence too.. but thats fairly easy
<m4n1sh> mvo: there?
<kirkland> SpamapS: neat, really glad to see you thinking about this
<micahg> mvo: are you open to using dh_autoreconf in synaptic?
<mvo> micahg: absolutely
<mvo> micahg: let me quickly check if that isn't in trunk already
<mvo> micahg: (lp:synaptic)
<micahg> ok, because it FTBFS in precise
<mvo> micahg: aha, ok. I will upload a new version to debian that we can sync than
<micahg> mvo: ok, do you need a patch or do you have it already or not need it?
<mvo> micahg: in trunk its using dh-autoreconf already, I did that last weekend
<micahg> cool, thanks
<mvo> micahg: thank you for raising it, slipped my attention :/
<bdmurray> pitti: What do you think about having the retracer not remove dependencies.txt?
<mvo> micahg: I uploaded to experimental now that should hopefully fix the issue (once its there and be be synced)
<micahg> mvo: be be synced?  did you want me to do that?
<mvo> micahg: well, I can do it too, no problem
<micahg> ok, thanks, was just wondering if I need to do anything here :)
<mvo> micahg: :) all good, I made a note to sync it when I get up tomorrow morning
<micahg> mvo: thank you :)
<tyhicks> seb128: Hi - did the automake distdir.test fail on the buildds without eCryptfs?
<tyhicks> seb128: or does it only fail inside of eCryptfs mounts?
<seb128> tyhicks: hi
<seb128> tyhicks: the buildd fail on another test later on, I hit that one when trying to debug the issue locally
<seb128> tyhicks: the same test works fine on the buildd on in a directory out of ecryptfs there
<tyhicks> seb128: Ok, that's all I needed to know
<tyhicks> seb128: I'm trying to get it triaged
<tyhicks> seb128: thanks!
<seb128> tyhicks: thank you for looking to the issue!
<tyhicks> np
<micahg> stgraber: should ltsp-client migrate to using fonts-nanum instead of ttf-unfonts-core?
<stgraber> micahg: probably
<micahg> want a bug?
<micahg> or an upload :)
<stgraber> micahg: nope, added to my todo, I'm doing PPA builds of the new LTSP anyway, so will just include the change in there
<micahg> thanks
<SpamapS> slangasek: So, I was thinking I'd add a 'nowait' class to /etc/network/interfaces which is used to subtract interfaces from the ones waited on. Thoughts?
<SpamapS> stgraber: ^^ you too
<SpamapS> slangasek: there seem to be a number of users who are willing to RTFM and figure out how to do what used to be easy, which is, have interfaces brought up at boot time that are not waited for.
<slangasek> SpamapS: how is that different from the existing 'hotplug' class except in name?
<SpamapS> oh there is already one like that?
<slangasek> yes
<slangasek> as for "what used to be easy" - it was only ever easy because of bugs, AFAICS
<SpamapS> hotplug isn't mentioned in /etc/init/network-interface.conf or /etc/init/networking.conf ...
<slangasek> SpamapS: yes, but it's mentioned at the top of interfaces(5) as an example, and it's a class that Debian has historically implemented - if we need to reintroduce it, we should use the same name
<SpamapS> slangasek: seems like a good idea.. though its kind of hard to resolve, logically, the difference between 'auto' and 'hotplug' in my head.
<slangasek> yes :)
<slangasek> y'know, I'd really like it if /etc/init/networking's ifup -a were going away this cycle
<infinity> You could always alias nowait to hotplug, just to the lulz. :P
<infinity> s/to the/for the/
<SpamapS> slangasek: we all would :)
<slangasek> infinity: how can you alias ifupdown "allow" classes?
<SpamapS> slangasek: at this point, what network interface appears w/o a net-device-added event ?
<infinity> slangasek: I meant in the code.  As in, make them mean the same thing.
<slangasek> infinity: yuck :P
<infinity> slangasek: ;)
<slangasek> SpamapS: well, if stgraber caught all the bugs, /etc/init/networking.conf is at best a redundant no-op now, and at worst tries to bring up interfaces before they're ready :)
<slangasek> stgraber: ^^ have you tried pulling /etc/init/networking.conf off your test systems to confirm that it's no longer needed?
<stgraber> slangasek: well, there are interfaces that will never be brought up by events
<slangasek> still?
<stgraber> tunnel interfaces, bridges with no physical interface in them, loopback device in containers, ...
<slangasek> ah
 * slangasek shakes his fist
<stgraber> anything that's not linked to a physical device won't be brought up by the udev magic
<slangasek> yep
<infinity> I'll note that I have several such interfaces on my machine. :P
<slangasek> which means, unfortunately, that /etc/init/networking.conf continues to risk bringing devices up out of order
<infinity> Please no break.
<SpamapS> slangasek: perhaps we should instrument this... if we have ifup -a log every interface that it thinks should be up, and have net-device-added events recorded.. we could have development-minded folks feed that data back to us and we'd get a picture of what is still missing net-device-added events
<stgraber> well, I hope I've added enough "please wait for a minute" code in the pre-up scripts to prevent much of the damage that ifup -a would cause but yeah, it's still a risk
<infinity> SpamapS: Some devices just plain can't ever have those events.
<SpamapS> Couldn't we, in theory, fire net-device-added events for soft-controlled interfaces?
<slangasek> why would we do that?
<slangasek> that's unnecessary indirection
<infinity> SpamapS: Chicken and egg, surely, since you want that event to bring up an if...
<SpamapS> Probably
<slangasek> synthesizing an event for your configured soft interfaces just so you can bring up those interfaces
<infinity> We could extend interfaces(5) to allow defining triggering events.
<infinity> (ie: bring up tun0 if eth0 up)
<SpamapS> so perhaps what would be better would be an enhancement to ifup to only bring up software interfaces .. ifup -a --soft-only
<slangasek> I would like it if networking.conf were explicitly *only* used for known soft interfaces... but that again would require another class
<slangasek> and would then require admins to migrate to its use
<slangasek> so this just dropped several notches on my priority list
<SpamapS> slangasek: unless ifupdown could detect whether or not an interface is hardware or software... much like mountall decides whether or not a filesystem is local or remote
<slangasek> it can't and shouldn't
<slangasek> making ifupdown introspect bridge devices to decide whether they have physical interfaces or not would just be wrong
 * SpamapS ponders
 * infinity curses at rhythmbox-ubuntuone's uninstallability.
<micahg> hmm, that should've have been allowed in the archive yet without gir1.2-ubuntuont-3.0, I wonder who let that in :P
<micahg> s/should've/shouldn've/
<micahg> gah, can't type today
<micahg> in any event, dobey should fix ^^
<infinity> micahg: I think it's just a typo/thinko?
<infinity> micahg: The gir package was renamed to ubuntuoneui to match the library.
<micahg> yeah
<micahg> looks like it
<apregier> I have a question about dpkg.  I am looking for a way to share a list of executable files between rules/postinst/prerm.
<dobey> doh
<dobey> micahg, infinity: is there a bug # filed?
<infinity> dobey: I just noticed it right now while doing livefs builds, so no.
 * SpamapS wonders if he has somehow failed his Plus1 maintenance duties by not noticing this earlier
<infinity> SpamapS: Yes. :P
<dobey> infinity: ok
<infinity> SpamapS: It's been broken for days, I assume.
<SpamapS> I was searching for the list of tasks this morning.. and got distracted. :p
<micahg> nah, was just uploaded
<infinity> SpamapS: (At least, based on when these uploads were made)
<SpamapS> Yeah since Friday
<SpamapS> oh, changelog says Friday
<infinity> Build logs say Friday too.
<dobey> pitti approved it today
<micahg> accepted 3 hours ago :)
<infinity> The libubuntuone change, that is.
<micahg> oh, yeah, that was last week :)
<infinity> I guess it's rhtyhmbox-ubuntuone that's broken, though,.
<infinity> So, okay.  3 hours.
<infinity> Grr.
<dobey> yes; anyway, i'm fixing it right now
<infinity> I missed my window for a hassle-free live build. ;)
<dobey> just wanted to make sure if there was a bug # i need to put in changelog
<SpamapS> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<SpamapS> Listed indeed.. :-P
 * micahg wanted to discuss the icedtea-web one with doko
<SpamapS> hm
<SpamapS> its working fine for me
<SpamapS> I can install icedtea-6-plugin .. it removes icedtea-plugin as I'd expect it to
<micahg> SpamapS: it shouldn't do that as icedtea-plugin is a transitional package and it makes upgrades more complicated
<rbasak> Can a package be in main in some architectures but universe in others?
<micahg> rbasak: why would you want to do such a thing?
<SpamapS> micahg: so perhaps it should just not have the Conflicts ?
<micahg> SpamapS: should be a breaks/replaces for moved files instead of conflicts/replaces, but I wanted to check with doko if he did that on purpose for some reason
<infinity> rbasak: Yes, but we don't because it gets confusing fast.
<SpamapS> micahg: yeah, Conflicts+Replaces seems like an odd combo
<rbasak> I think that u-boot-linaro-omap4-panda-splusb should be available on x86. But that would involve build-depending on gcc-4.5-arm-linux-gnueabihf, which is in universe.
<slangasek> rbasak: any package whose source is in main must have its build dependencies in main, for all archs.
<slangasek> why do you need this available on x86?
<infinity> rbasak: It builds out of u-boot-linaro sources.  You're asking for the impossible.
<rbasak> I should be able to usb boot a pandaboard from an x86 machine
<infinity> rbasak: But we have a long-standing history of people wanting different-arch bootloaders, and the answer is always "download it and unpack it".
<infinity> (Except in the case of palo, and you don't want to know what was done there)
<infinity> (It was very, very, very wrong)
<slangasek> infinity: wronger than what was done with aboot? :)
<soren> stgraber, kees, cjwatson, sabdfl, stgraber, mdz: Friendly reminder: TB meeting in 50 minutes.
<rbasak> This involves the u-boot (arm) blob being on an x86 machine. Currently I'd have to apt-get install it on a panda and copy it over, which seems to go against the whole concept of packaging it.
<rbasak> thanks infinity
<dobey> infinity, micahg: fix uploaded. sorry about that.
<rbasak> I guess that's my answer
<stgraber> soren: thanks
<infinity> slangasek: It builds it in the clean target if arch=hppa, then includes the binary in the source package, and the build then makes an arch:all deb.
<soren> cjwatson: I did see your apologies, but they didn't sound very definitive, hence the reminder anyway.
<infinity> slangasek: Can it get worse?
<micahg> dobey: thanks for the quick action
<slangasek> infinity: ah - yes, that's worse than aboot. ;)
<slangasek> rbasak: and why do you want only the uboot blob on the x86 machine?  Don't you want an entire bootable system on the x86 machine?
<slangasek> and at that point, I think it's clear that "installing the package on the x86 host" is the wrong model
<rbasak> slangasek: I just want to set off a netboot.
<slangasek> hmm
<rbasak> I'd like to package this because then setting up a machine that can bootstrap pandas would be very easy
<rbasak> (as easy as cobbler makes this for traditional machines)
<slangasek> I don't think that's something we want to support
<SpamapS> slangasek: PXE booting lots of ARM servers from x86 servers? That seems like exactly what we want to support.... or am I over simplifying the task?
<slangasek> build-depending on a cross-compiler in order to build binary packages of one arch containing binaries of another arch - fail
<slangasek> SpamapS: sure we want to support that.  We don't want to support what rbasak is proposing with the build-dependencies
 * SpamapS read "bootstrap" as PXE boot, and now realizes his error.
<slangasek> there are three options here you could reasonably use
<slangasek> - grab the arm package and manually unpack it
<infinity> rbasak: It's not really rocket science to grab the latest _armhf.deb from a mirror and unpack and extract the binary you need, is it?
<infinity> rbasak: This is what, for instance, debian-cd does to grab bootloaders to jam onto CDs.
<rbasak> infinity: no, but it is really ugly to automate it
<micahg> ports has mirrors?
<infinity> micahg: It has one. :P
<rbasak> infinity: it does not work when you consider configuration management
<slangasek> - make the uboot package binary blob bits arch: all so that they can be installed anywhere (except that this again requires the cross-compiler build-dep since arch: all packages are always built on i386 -ohwell)
<infinity> micahg: (In that ports != ftpmaster)
<slangasek> - use multiarch to cross-install the package
<SpamapS> I don't think that would be too ugly to automate. We can have armhf as a foreign arch in apt and use apt-get download directly, can't we?
<infinity> slangasek: Or it requires fixing the longstanding wishlist to have arch:all affinity have source package granularity.
<slangasek> infinity: or that, yes
<infinity> slangasek: (In LP)
<infinity> It's not actually hard to do.  It's just another set of round tuits someone needs to find.
<micahg> infinity beat me to it :)
<slangasek> added debian/patches/CVS/Entries
<slangasek> hate
<micahg> that's at least 2 reasons to cry
<slangasek> barry: hum, just had a weird experience doing a 'bzr pull' on a Debian UDD branch...
<slangasek> Unapplying quilt patches to prevent spurious conflicts
<dobey> infinity, micahg: i also just proposed https://code.launchpad.net/~dobey/ubuntu/precise/banshee/drop-u1ms/+merge/91713 which drops the extension from the banshee builds, so it won't FTBFS in the future.
<barry> slangasek: what package?
<slangasek> barry: nfs-utils debian testing branch... I expect it's generally reproducible with any bzr pull that pulls new revisions however, based on the behavior seen here
<slangasek> and unapplying seems like it should only be done on a merge, not a pull?
<barry> slangasek: agreed
<barry> slangasek: so you branched, and then later pulled, and the latter tried to unapply the patches?
<barry> slangasek: definitely file a bug on the udd project
<slangasek> yep, that's what happened
<barry> verified that if nothing needs to be pulled, the patches are not unapplied
<slangasek> barry: bug #927878
<ubottu> Launchpad bug 927878 in Ubuntu Distributed Development "bzr merge quilt handling unapplies patches unnecessarily on 'bzr pull'" [Undecided,New] https://launchpad.net/bugs/927878
<barry> ack
<micahg> dobey: thanks, I'd let the cli-team take a look at that (laney, hyperair)
<sabdfl> soren, ack, thanks
<pitti> bdmurray: fine for me; I just thought they wouldn't be that useful
<pitti> bdmurray: I'll merge your branch
<pitti> infinity: why does it break live-build? I didn't upload u-meta with the seed change yet
<infinity> pitti: Because rhythmbox-ubuntuone had a dep on a nonexistant package.
<infinity> pitti: All fixed now.
<pitti> fair enough, but what pulls in rb-u1?
<pitti> AFAIK I merely seeded it?
<infinity> No idea.  Didn't check.
<pitti> ok, thanks
<pitti> sorry, didn't spot the missing dep during binNEW
<infinity> (Sorry, in meetings, a bit terse)
 * pitti too
<bdmurray> pitti: thanks
<soren> pitti: tb meeting
<micahg> Bug #927917  looks bad
<ubottu> Launchpad bug 927917 in Ubuntu "Changing a partition type from ext3 to ext4 with Formatting unchecked in Ubuntu 12.1 installer formatted the partitions and erased everything" [Undecided,New] https://launchpad.net/bugs/927917
<bkerensa> slangasek: Did you by any chance take care of the multiarch patches that blkperl messed up on? He asked me to transition the packages he did because apparently they were not transitioned properly  #651008 #651009 #651010 on BTS
<bkerensa> I dont wanna re-do them if you or someone else already did
<slangasek> bkerensa: all the libraries that were on our list at the localjam have been followed through on by now :)
<bkerensa> slangasek: Ok thanks :D
<bdmurray> slangasek: bug 911436 will appear in a lot of packages correct?
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<slangasek> bdmurray: it can happen during the upgrade of any package; or are you asking if it affects other packages besides apt?
<bdmurray> bug 927317 has a similar stacktrace but is about cups and lpstat
<ubottu> Error: Launchpad bug 927317 could not be found
<slangasek> right - it can affect anything that uses libp11-kit0... which is anything that uses gnutls, basically
<slangasek> so yes, rather a lot of packages may be affected
#ubuntu-devel 2012-02-07
<bdmurray> okay, I was / am considering a bug pattern
<bdmurray> slangasek: I noticed there is no update-manager apport hook in Lucid and thought the best way to get it in there would be an SRU of update-manager.  However, I'm confused about how far behind the lucid bzr branch for update-manager is.
<bdmurray> ah, its me
<slangasek> mmk
<psusi> wait... when a package is synced from debian, it's just the source right, the binaries are still rebuilt for ubuntu right?
<micahg> psusi: correct
<YokoZar> slangasek: What do you think of apt automatically transitioning users of amd64 packages to i386 packages on dist-upgrade if 1) the i386 is higher version, and 2) the currently used architecture is not available in any pool ?
<YokoZar> I'm thinking of issues where we, say, delete zsnes:amd64 from the archive and the amd64 lucid user needs to be migrated to zsnes:i386.
 * micahg debates taking an axe to zsnes
<slangasek> YokoZar: I reserve judgement; we'd have to have a good long think about whether this is always the right thing to do
<slangasek> YokoZar: btw, are you planning to complete the work item from https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default that you accepted at UDS? (announce intentions to move to 64-bit by default)
<infinity> YokoZar: That would fail pretty spectacularly if Packages-amd64.gz got corrupted in transit or something, leaving you with "no amd64 packages in the pool".
<YokoZar> slangasek: infinity: Yeah I suspect we'll run into questions about manually installed debs and what if we can't figure out the "available pool" properly and so on
<YokoZar> slangasek: ~ work items, thank you for reminding me.  I was trying to check on the work items I might have missed and for some reason I wasn't coming up in the work item tracker
<infinity> YokoZar: I think the saner (for some value of "sane") option for now is to take it case-by-case and provide cross-arch transitional packages.
<slangasek> YokoZar: tracker> ah, that'll be my fault for not getting the blueprint shoved along to "approved" state
<slangasek> infinity: but you can't have a transitional package depending of a foreign package of a *specific* architecture presently, so each one of those would require a package name change
<slangasek> which isn't pleasant
<YokoZar> infinity: but we can't have specific arch dependencies, so the transitional package would have to be a different name than the existing package....
<infinity> YokoZar: Not that I find the cross-arch deps particularly elegant, but they're much more fool-proof.  And the corner cases surrounding how dpkg and apt determine "availability" are many.
<YokoZar> The uglier solution is just a big manual hard-coded list in update-manager :/
<infinity> YokoZar: Well, the transitional package would be the old name, and it would depend on zsnes-i386, I guess?
<YokoZar> (which doesn't work for dist-upgrade, which is why I suggested modifying the apt resolver)
<YokoZar> infinity: right, and then we'd have to rename zsnes to zsnes-i386 :/
<infinity> Yup.
<infinity> I did note that it fails the elegance test.
<infinity> But it's at least easy to spot-check for correctness.
<YokoZar> infinity: you can look at the new wine1.4 package for a similar setup
<infinity> The proposed apt change is immediately incorrect in several corner cases, without looking for weirder ones.
<micahg> YokoZar: alternatively, you can fix the amd64 build so that it builds the arch specific parts if there are any
<YokoZar> micahg: but there aren't any, zsnes is a good example because it's an i386 only package that we had a fake ia32-libs solution for in the past
<infinity> (Out of curiosity, why would this be done to zsnes?  Does the 64-bit build not work?)
<infinity> Oh, there isn't a 64-bit build, I see.  That seems odd, given that it's an emulator. :P
<YokoZar> infinity: zsnes does not and will not build on amd64 ever, I think it's full of assembly code or some such.
<infinity> Fair enough.
<micahg> YokoZar: you can do what we did with flash, if you can get it to compile again :)
<infinity> Still sounds like it should just be dealt with the same way flash is.
<infinity> The same way we did flash in oneiric, that is.
<infinity> Before we had a 64-bit one.
<ScottK> Burn it with fire/
<ScottK> ?
<ScottK> Oh, that's not what you meant.
<micahg> zsnes:amd64 depends zsnes-i386 (i386 only) which depends on zsnes:i386
<infinity> micahg: Makes the packaging a bit more complex, since zsnes.install differs on the two arches.
<infinity> micahg: I don't see the point in the last dependency.  Just put the binaries in zsnes-i386 and have it replace zsnes (<< pre-split-version).
<YokoZar> micahg: yeah that would work, I suppose, but then we're left carrying two dummy packages for an indeterminate amount of time.  Especially because there's no way for zsnes:i386 to declare that it replaces and obsoletes zsnes:amd64 (and indeed apt will try to keep them in sync at the same version and complain about any change that removes empty zsnes:amd64)
<micahg> infinity: that works too, but I hate the idea of having a zsnes-i386 package in perpetuity
<YokoZar> infinity's solution is a bit better but leaves us with dumb names forever
<infinity> micahg: Who cares?  Package names are often weird.
<micahg> it's a diff from Debian
<infinity> So, convince the Debian maintainer to do the same thing.
<infinity> But it's not actually a large diff.
<YokoZar> OR, we could implement specific arch relationships in control fields...
<micahg> well, now that Debian will soon have a multiarch capable dpkg, that might be possible :)
<YokoZar> By the way I didn't really appreciate how far ahead we were with multiarch than Debian until now.  I had been waiting for multiarch for a long time to make a proper wine64 package, and it finally got accepted today :)
<infinity> There's a certain advantage in not having individual package maintainers, yes.
<infinity> Downside: Lots of universe bugs go ignored.  Upside: When we want to move on something, we MOVE.
<ScottK> infinity: Lots of Main bugs go ignored too.
<justgord> Any ubuntu dev working groups focussed on tablets and/or wayland  ?
<nidsub> hola, i hope there someone out there who could help me :)
<nidsub> im sorry ,but im really new to irc
<nidsub> should i just post my problem here?
<nidsub> im trying to build linux kernel
<nidsub> here is the error i get,please  point out what did i do wrong
<nidsub> -VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ make ARCH=arm
<nidsub> mkdir: cannot create directory `include/generated': Permission denied
<nidsub> make[2]: *** [silentoldconfig] Error 1
<nidsub> make[1]: *** [silentoldconfig] Error 2
<nidsub> make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'.  Stop.
<nidsub> nidhal@nidhal-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm
<nidsub> scripts/kconfig/conf --silentoldconfig Kconfig
<nidsub>   CHK     include/linux/version.h
<nidsub>   UPD     include/linux/version.h
<nidsub>   CHK     include/generated/utsrelease.h
<nidsub>   UPD     include/generated/utsrelease.h
<nidsub>   Generating include/generated/mach-types.h
<nidsub>   CC      kernel/bounds.s
<nidsub> cc1: error: unrecognized command line option â-mlittle-endianâ
<nidsub> cc1: error: unrecognized command line option â-mno-thumb-interworkâ
<nidsub> kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
<nidsub> kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch
<nidsub> make[1]: *** [kernel/bounds.s] Error 1
<nidsub> make: *** [prepare0] Error 2
<nidsub> please :(
<micahg> nidsub: first error is you didn't use a pastebin for that
<micahg> as for the rest, is this on an arm system or are you cross compiling
<nidsub> thank you :),yerp im trying to cross compile
<nidsub> is on arm qemu
<nidsub> here the detail on the step i took ..from this webpage
<nidsub> http://wiki.xilinx.com/zynq-linux
<micahg> well, this isn't a general support channel, #ubuntu-arm might be better suited
<micahg> #ubuntu would be for general support, but I don't see this working out too well in there
<nidsub> Thanks you so much for the tips
<goddard> I'm trying to use debuilder but it doesn't seem to be creating my deb file although i get no errors
<pitti> Good morning
<Sweetshark> Morning everyone!
<Sweetshark> http://twitter.com/#!/gregkh/status/166644258831478784 <- yay, gregkh -- of kernel fame -- contributing to LibreOffice ...
<pitti> Daviey: mariadb> as it is 100% binary compatible, I think there is some good grounds for a FFE on this one
<pitti> Daviey: my bigger concern there would be how much commercial backing mariadb has, i. e. whether there are stakeholders which we can believe are still active in 5 years
<Daviey> pitti: need to discuss this in a bit. :)
<seb128> - /usr/lib/debug/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.0
<seb128> + /usr/lib/debug/.build-id/5e/d483e11d8dbaff9929c94ad6b9b05a174c7685.debug
<pitti> I noticed the new /usr/lib/debug/.build-id/ gibberish recently, too
<seb128> is that something which changed in our toolchain (it's libsoup2.4-dbg new version)
<pitti> I have no idea what changed there
<seb128> hum, k
<seb128> well I will assume it's not a bug on my side then ;-)
<debfx> seb128: it's a new debhelper 9 behavior
<seb128> debfx, ok, thanks
<seb128>   * dh_strip: In v9, pass --compress-debug-sections to objcopy.
<seb128> I guess
<seb128> that source is v9
<pitti> so this stuff is actually valid?
<seb128> debian bug 631985
<ubottu> Debian bug 631985 in debhelper "dh_strip: add a possibility to compress debug sections" [Wishlist,Fixed] http://bugs.debian.org/631985
<pitti> it seems a ridiculously bad design to put this in a hidden  directory
<seb128> with useless names...
<pitti> cking: FYI, I'm currently working on https://launchpad.net/fatrace
<pitti> cking: as powertop seems to do a rather bad job at catching disk events (and even reports them wrongly, too)
<pitti> cking: once it's ready and in the archive, I'll update https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues accordingly
<cking> pitti, wow, this is excellent!
<pitti> cking: fanotify is quite nice for this :)
<pitti> cking: if you are interested in trying, it's in lp:fatrace; make && sudo ./fatrace
<cking> yep, this is an excellent tool to track down these offending wakeups!
<pitti> it has --time and --output options, and I'm going to add some filtering, too
<pitti> cking: well, it's not process wakeups (that's powertop), just disk events
<pitti> "f"ile "a"ccess trace
<pitti> cking: if you want it to do something more (new option, etc.), please let me know
<cking> pitti, does the -o option interfere with the results - i.e. it could write the output to disk and hence change the stats
<pitti> cking: no, it ignores its own events
<cking> sweet
<pitti> cking: without -o, gnome-terminal touches a tempfile in /tmp/ with every output, and thus generates a feedback loop
<pitti> -o avoids this, but I'm trying to add something more clever
<cking> yep, I saw that and wonder what was happening
<pitti> well /tmp tmpfs definitively helps
<pitti> but we don't have that by default
<pitti> cking: --ignore-pid could work
<pitti> --ignore-path /tmp/ sounds a bit pointless
<pitti> (but might make sense for other contexts)
<pitti> by default it watches all "real" mounts
<pitti> it could grow an option to only watch the mount of current cwd
<cking> perhaps adding a timestamp to the output so we can figure out if events occur periodically may help
<seb128> pitti, bug #928212 hate gzip hate
<ubottu> Launchpad bug 928212 in gtk+2.0 (Ubuntu) "Cannot install ia32-libs due to libgtk2.0-0_2.24.10-0ubuntu1_i386.deb conflicts with libgtk2.0-0_2.24.10-0ubuntu1_amd64.deb" [Undecided,New] https://launchpad.net/bugs/928212
<pitti> argh
<pitti> cking: ah, good idea
<cking> pitti, it does generate quite a bit of data on a busy machine - perhaps producing a summary sorted on the worse behaving process could be handy too
<pitti> cking: it's not supposed to be the preferred frontend
<pitti> cking: I have another WI to write a script that calls powertop, fatrace, and generate a report out of it
<pitti> with worst offenders, sorted, etc.
<cking> pitti, ah, I understand - good idea!
<pitti> cking: I really don't want to do all this in plain C :)
<cking> pitti, if we are going to use tools like powertop perhaps we need to ensure they work correctly - anecdotal evidence seems to tell me that some of the data may not be trustworthy
<pitti> cking: yes, like the file accesses
<pitti> wakeups seem to be quite reliable, though?
<cking> and battery power consumption too
<cking> wakeups work well as it does cater for a wide range - I looked at a specific case of wakeups and wrote eventstat to do the more focused monitoring for my testing
<pitti> cking: pushed --current-mount option; might be useful for some finer-grained debugging
<pitti> cking: I'll add timestamps and an --ignore-pid option still to avoid this gnome-terminal loop, but I think the rest of the filtering/reporting should happen with higher level tools
 * cking nods - yep, makes sense
<MacSlow> seb128, hey there... I think you'll be happier with https://code.launchpad.net/~macslow/notify-osd/fix.810325-2/+merge/91807 regarding the avg. color-tinting of the notification-bubbles
<seb128> MacSlow, hey, let me have a look
<MacSlow> seb128, it checks at runtime for the schema and key... if they are missing, it just falls back to the old behaviour/color
<seb128> MacSlow, that sounds good
<seb128> MacSlow, hum, launchpad gives and empty diff?
<MacSlow> seb128, I'd be happy if you could review it
<MacSlow> seb128, yeah... hold on a minute... I accidentally pushed to trunk instead of the correct branch *cough*
<MacSlow> seb128, fixed/reverted it in trunk already... but needs some time to pick that up
<seb128> MacSlow, ok
<lamont> Processing triggers for libc-bin ...
<lamont> ldconfig deferred processing now taking place
<lamont> sh: 1: /usr/bin/gdbus: not found
<lamont> neat
<pitti> cking: ok, timestamps available now; -t is now -s
<cking> pitti, \o/
<jacekmigacz> how to prevent lightdm respawning Xorg session?
<jacekmigacz> i'd like X once killed, stay killed
<jacekmigacz> other words I'd like to kill,remove seat.
<jacekmigacz> lightdm has SeatRemoved signal but no Remove seat method
<pitti> cking: it's quite unbelievable how much disk activity chatter even my bash prompt uses..
<cking> bashing the oxide off the platter..
<pitti> well, my fault mostly, of course; it calls git, sed, and whatnot
<cking> this is where we find most of the disk events are due to our tools
<pitti> cking: I added an --ignore-pid option now, so gnome-terminal can be silenced
<pitti> cking: from my POV this should be good enough for a first release; do you still see something major missing?
<pitti> oh, I should document theh flags in the manpage
<cking> pitti, lemme have one more look
<cking> pitti, perhaps it should check it needs to be run with suitable root privilege rather than just failing with "fanotify_init: Operation not permitted"
<pitti> I'm not actually sure which capability that is
<pitti> CAP_SYS_ADMIN?
<pitti> cking: doing that properly is a bit nontrivial, so I didn't so far
<pitti> cking: uid==0 is not quite sufficient, I think
<pitti> apparmor might restrict it, and other systems might allow it even to non-root processes
<cking> ah, true
<cking> pitti, its surprising how much unity-panel-service is doing really
<pitti> cking: I'll rename 'M' to 'W' and 'A' to 'R'; that's a bit clearer IMHO
<cking> pitti, heh, I can't valgrind the fanotify_* calls
<pitti> valgrind?
<cking> yeah, I run valgrind on all apps to see if they are leaky
<pitti> I don't use any dynamic memory allocation
<pitti> in small C programs I try not to, both to guard against leaks and also because it's more efficient
<pitti> (not copying stuff around, etc.)
<pitti> well, there's one strdup() for the --output argument
<pitti> that could be freed, but it's only a single allocation
<cking> ..just me being anal ;-)
<pitti> but I like my global variables to be valid all the time
<pitti> cking: right, appreciated :)
<pitti> cking: so, valgrind doesn't know about fanotify?
<cking> so, as for features and functionality it looks most excellent
<cking> pitti, well, valgrind on my precise box didn't like the fanotify_init()
<cking> goodness knows how that's implemented
<pitti> cking: manpage updated as well now
<jamespage> micahg, OK if I merge maven-repo-helper? a couple of bug fixes only...
<cking> pitti, looks all good to me
<pitti> Cannot initialize fanotify: Operation not permitted
<pitti> You need to run this program as root.
<pitti> cking: ^ slightly more friendly now
<cking> pitti, yay
<pitti> cking: ok, thanks; off to a 0.1, and packaging :)
<pitti> cking: https://launchpad.net/fatrace -> gotta love how LP says that I released the 0.1 tarball 15 hours ago :)
<cking> pitti, LP now a time machine too?
<smoser> superm1, around ? i've some questions about dkms.
<dholbach> if a new binary package gets added, do the existing packages get published after the new upload or do they all wait until the binary new package is processed?
<pitti> dholbach: they all wait
<dholbach> (I'm asking because of fcitx)
<dholbach> ah ok
<smoser> superm1, never mind. i think i got it sorted.
<pitti> otherwise we'd end up with broken dependencies very often
<dholbach> yeah, I guess
<dholbach> stupid question, but I just wanted to be sure ;-)
<pitti> cking: uploaded; now I need to bribe an archive admin to process it :)
<dholbach> pitti, have you bribed yourself before? ;-)
<pitti> I can't review my own stuff :)
 * dholbach can totally see pitti go back and forth between "ok, how about I have some beer later after reviewing this stuff?", "yeah, beer would make the pain go away", "yeah, why not", "ok, deal" himself
<pitti> dholbach: nice "sponsorship Friday" idea
 * dholbach hugs pitti
 * dholbach just dealt with a bunch of sync requests - we were up to 80+ earlier :)
 * pitti hugs dholbach
<dholbach> that's also why I asked about the fcitx one :)
 * Sweetshark should lurk more, to be able to make grow the casual hugs into grouphugs ....
<dholbach> seb128, Laney: to move forward with the glom story, I just uploaded a new goocanvasmm-2.0 package to https://launchpad.net/~dholbach/+archive/ppa - if you could take a look and just sponsor if it's good enough for you, I'd appreciate it :)
<Laney> are these parallel installable?
<seb128> dholbach, thanks!
<Laney> also NICE
<seb128> dholbach, will you do gdamm5 as well? ;-)
<dholbach> seb128, on it
<seb128> dholbach, you rock, you make me want to spend some time on the sponsoring queue ;-)
<dholbach> seb128, uploading it right now
<dholbach> there's something funny with a devhelp file
<seb128> dholbach, I will not wait friday though, I'm concerned that too many people hitting on it together will lead to duplication ;-)
<dholbach> but I think it's more important we get glom up and running and fix the other stuff later
<Laney> has the sover changed? shver is still the same
<dholbach> seb128, if you want to do a bit of sponsoring before - do it :)
<dholbach> Laney, hm? it seems like no goocanvasmm-2.0 is available right now at all?
<seb128> dholbach, right
<Laney> well, indeed, but I think it probably wants to be 1.90
<Laney> anyway I will have a proper look later
<Laney> glom depends on this version now?
<dholbach> yes
<Laney> grand
<dholbach> it's all in the openismus ppa
<dholbach> I just had to make a few very very small changes
<Laney> this neatly steps around jsogo
<Laney> would anyone be interested in maintaining?
<dholbach> seb128, and I are in discussions with the openismus people
<dholbach> they maintain it in their ppa already
<dholbach> and some time further down the line, it'd be nice if they could maintain the whole stack in ubuntu
 * Laney will sponsor to Debian if they want it (and would consider DM at some point)
<kelemengabor> mvo: hi, do you have time a slightly offtopic question? How does one submit a translation for upstream apt?
<kelemengabor> I tried the BTS, without much success: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655238
<ubottu> Debian bug 655238 in apt "[INTL:hu] Updated Hungarian translation for apt" [Wishlist,Open]
<mvo> kelemengabor: sure, always! the debian bts is the right place, if noone has merged it  yet I can do that
<mvo> kelemengabor: fwiw, its in debians bzr already
<mvo> kelemengabor: just not released or taged in the bug
<slangasek> pitti: fatrace> very nice :)
<mvo> kelemengabor: sorry for that, there should be anohter upload to stable I guess
<pitti> slangasek: I have a half-written blog post about it, will finish after our meeting
<pitti> slangasek: thanks :)
<slangasek> pitti: as far as a tool to collect the information and report it, I think 1 minute is a little too short... for me the goal is to have the disk to wake up no more than once per 10 minutes when idle
<pitti> slangasek: it's indeed quite surprising what enormous disk chatter we have during a normal session
<pitti> slangasek: 10 mins sounds fine
<slangasek> well, it doesn't surprise me :/
<slangasek> because we know we have a longstanding bug about parking cycles destroying disks
<kelemengabor> mvo: oh, that's nice. I should read bzr logs more :). Thanks!
<mvo> kelemengabor: well, someone should have simply told you :) so no worries
<pitti> directhex: hey! do you know thhe status of the banshee gtk3 port?
<directhex> pitti, i saw it demonstrated at fosdem this weekend. i'm not sure what release blockers there are, if any
<tkamppeter> pitti, hi
<tkamppeter> pitti, I will push CUPS 1.5.2 in some minutes, can you upload it then? Forgot to update the debian/patches/series file and so the new patches are not applied.
<pitti> directhex: ah, thanks; nice to hear that there's good progress
<micahg> jamespage: sure, wasn't sure if we needed it
<tjaalton> slomo: more quiet here, so http://paste.ubuntu.com/832840/
<tkamppeter> pitti, I have pushed up CUPS 1.5.2-2 now, can you upload it to Debian and Ubuntu? Thanks.
<pitti> tkamppeter: ok, thanks
<bdmurray> pitti: with regards to bug 856975 that traceback shows up in almost all ubiquity syslog files
<ubottu> Launchpad bug 856975 in language-selector (Ubuntu) "fontconfig-voodoo crashed with DBusException in __new__(): org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory" [Low,Confirmed] https://launchpad.net/bugs/856975
<pitti> it seems dbus is not running in that environment
<pitti> I think we need to fix that
<slangasek> pitti: seems more likely to me that this would be some sort of /run transition issue... not sure how we would've gotten that far with dbus not being started
<pitti> anyway, I'll have a closer look in the live session (and ubiquity-only)
<pitti> put on my todo list
<bdmurray> thanks
<cr3> hi folks, if I have a project mostly in Python with some C++, is it reasonable to have setup.py call make? or, should I use a Makefile instead that calls setup.py?
<slangasek> cr3: no autoconf?
<pitti> tkamppeter: uploaded
<slangasek> cr3: I'm not sure one way is better than the other, anyway; both will have rough spots
<cr3> slangasek: no autoconf, there's very little C++ and it's actually Qt code so the process is qmake + make in a small subdirectory
 * slangasek nods
<tkamppeter> pitti, thanks.
<jamespage> micahg, ta
<micahg> do I have to worry about an upgrade from a non-release version of a package in oneiric to precise?  I'm looking at ca-certificates and the only possible thing left is the conflicts on the pre-release ca-certificates-java
<SpamapS> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS
<slangasek> micahg: I wouldn't keep transitional code from release-1-Îµ, no
<micahg> slangasek: well, the rest of the code said drop after oneiric, that's part of why I'm asking
<slangasek> not if there's a question of being in sync or something - if it's cheap to keep then meh, but in general users shouldn't expect things to work if they don't at least upgrade to the release first
<micahg> the other part is, do we assume upgrade to release packages before upgrading to the next release
<slangasek> *I* certainly assume that :)
<micahg> ok, yeah, it's the only diff
<micahg> mvo: BTW, synaptic still FTBFS in Ubuntu
<mvo> micahg: meh, thanks! let me look
<micahg> mvo: it seems weird, the patch applied in Debian, but not Ubunut
<micahg> *Ubuntu
<mvo> micahg: I also wonder why I did not get the ftbfs mail :/
<mvo> micahg: at least I can reproduce it here, I work on it now
<doko> micahg, did you already care about all gnat related packages?
<SpamapS> smoser: just reviewed your patch for bug 915215
<ubottu> Launchpad bug 915215 in sysvinit (Ubuntu) "rc.local should support a runparts of rc.local.d" [Low,In progress] https://launchpad.net/bugs/915215
<TiMiDo> man this sucks,
<slangasek> SpamapS, smoser: eew?  this is rc.local, it's *supposed* to be edited by the admin
<slangasek> packages should *never* be adding anything to it
<SpamapS> slangasek: welcome to the world of automation
<slangasek> why would you use *that* interface for automating anything?
<SpamapS> slangasek: if not rc.local.d , something with a .d makes sense so users can comfortably put things there without worrying about conflicting w/ system level startup scripts.
<SpamapS> slangasek: people use rc.local all the time in automation because it is reliable and simple to implement.
<slangasek> SpamapS: so why not just *clobber* /etc/rc.local?
<slangasek> it's rc.local
<slangasek> why worry about its default contents at all?
<slangasek> also, why is using /etc/init.d + /etc/rcN.d, or /etc/init, a practical concern?  dpkg won't overwrite any local files in these directories on package install without prompting, so even if someone does mistakenly install a package that overlaps something local, it shouldn't blow up?
<jtaylor> doko: do you have an opinion on getting numpy 1.6 into precise before the feature freeze?
<jtaylor> it is backward compatible with 1.5, and only 18 packages that need rebuild
<jtaylor> debian is going to transition very soon too but probably after feature freeze
<doko> jtaylor, no. do you want to prepare packages?
<jtaylor> doko: I'm currently just looking for helpers and getting an overview, if people approve I'll prepare packages
<slangasek> hallyn: bug #928432 says spice should only be enabled on 64-bit builds; can you confirm?
<ubottu> Launchpad bug 928432 in Linaro QEMU "spice backend fails to build on i386 with -Werror" [Undecided,New] https://launchpad.net/bugs/928432
<doko> jtaylor, I don't see a reason not to do that. so if you have packages for numpy, scipy, and maybe others, let me know
<jtaylor> doko: great, I'll let you know on the progress
<smoser> SpamapS, thank you. i dont mind it being upstart.
<smoser> i actually went looking for you one day to read the suggested upstart script htat i put int he bug
<micahg> doko: well, I think I've got the ada related failures fixed/sync'd, gnat is still and issue on armhf, but I was going to look at the diffs with Debian at some point
<SpamapS> slangasek: clobbering rc.local makes sense if you have one thing influencing rc.local, but not if you have multiple things that you want to start late in the boot...
<smoser> i backed away as it was just more intrusive.
<smoser> i agree with SpamapS .
<SpamapS> slangasek: and its still simpler than using /etc/init.d + update-rc.d or upstart (though upstart *does* help a lot)
<slangasek> SpamapS: rc.local is not defined as "late in boot", it's defined as "last thing run via sysvinit" which is no longer the same thing ;)
<hallyn> slangasek:  hm,  http://spice-space.org/faq.html
<hallyn>  says only server isnt supported on 32bit, client is
<smoser> slangasek, well, rc.local is back to being "relatively" late in boot
<smoser> wel...
<hallyn> slangasek: d'oh, so yeah
<smoser> err.. anyway i think that is a separate issue entirely.
<SpamapS> but the 'start on stopped rc RUNLEVEL=[2345]' is still a lot more obscure than 'echo /usr/local/sbin/dbdaemon' > /etc/rc.local.d/dbdaemon && chmod +x /etc/rc.local.d/dbdaemon
<micahg> doko: also, wanted to ask you about the icedtea-plugin situation, it seems that there should be a breaks/replaces instead of a conflict/replaces there, just wanted to know if you did that on purpose or not
<SpamapS> slangasek: most people define it as late in boot.. evidence that we have not documented its new place in the boot very effectively. :-/
<smoser> well, if its not "late in boot", then really, thats a bug.
<smoser> we re-defined it
<smoser> (yes, i realize we did, but currenlty its *so* much better than it was in 10.04)
<doko> micahg, there are no diffs, just a bootstrap is needed
<micahg> doko: ah, Debian has a patch in 4.4 that lets it bootstrap from 4.6 which is built now
<smoser> so anyway, i only proposed it and didn't upload it because i wanted to give people like slangasek the opportunity to say "yuck, no way"
<smoser> i only decided to try it because i came across a need/desicre to run something late in boot without screwing up someone's changs to rc.local.
<doko> micahg, neither 4.4 nor 4.6 are built on armhf
<micahg>       gnat | 4.6ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc
<micahg> ah, it's empty :)
<micahg> doko: ok, I don't know how to bootstrap that offhand
<broder> SpamapS, smoser: i always thought people liked rc.local because it was cross-distro. that wouldn't be the case with rc.local.d, no? it'd be ubuntu-specific? or are other distros picking it up too?
<smoser> broder, no. unless by coincidence
<SpamapS> broder: I'm sure thats one reason people use it, because it is ubiquitous, elminating the need for chkconfig users to learn update-rc.d
<smoser> SpamapS, wel... commented on post there.
<slangasek> smoser: udev redefined it; we just made that redefinition manifest :)
<slangasek> hallyn: I don't know which end of spice is the client or server ;)  Does that mean we need to not be building qemu-spice on 32-bit archs?
<slangasek> SpamapS, smoser: so fundamentally, I think that having an rc.local /framework/ is something that's not the sysvinit package's job to solve
<slangasek> rc.local is "the admin can edit it"
<smoser> admins dont edit things any more
<slangasek> and that editing could very well include dropping in a copy of some template that looks at /etc/rc.local.d
<slangasek> the admin can edit it in as automated a fashion as they wish, but either way, it's not the package's problem :)
<smoser> if rc.local.d is not the packages problem, then really, rc.local is not either. they are the same problem.
<smoser> one is just older.
<slangasek> yes, rc.local is an interface from the package
<smoser> i really think that it adds a large usefulness at the cost of 2 forks in the boot
<slangasek> any interfaces beyond that, such as a hypothetical rc.local.d, are not the problem of sysvinit
<smoser> with, extremely low mantainence issues.
<hallyn> slangasek: yeah i confused myself at first too :)  but yes qemu is the server, spicec or spicy is the client, so qemu-kvm-spice should not be built for 32-bit
<smoser> slangasek, so is that a definitive "NO" ?
<smoser> i'm willing to accept that it is.
<slangasek> smoser: nothing is ever settled and I don't have the last word; but my opinion is firm :)
<slangasek> this is something that's easy to design and implement without ever touching the sysvinit package
<slangasek> because *by definition* the package won't mess with whatever changes you make to rc.local - including tweaking it to use rc.local.d
<smoser> right. and thats fine.
<smoser> so its easy to add
<smoser> but its not easy to determine if modifying rc.local is going to stomp on someone else's already modified rc.local
<smoser> so you have to assume that youc an't do that if you're trying to be a good tenant.
<slangasek> mkdir /etc/rc.local.d; mv /etc/rc.local /etc/rc.local.d/reallylocal; echo > /etc/rc.local <<EOF.. :)
<slangasek> and besides, I thought admins didn't edit files anymore, so why would there be anything in /etc/rc.local to preserve ;)
<mbiebl> slangasek: /etc/rc.local.d, really? Isn't that what /etc/init.d is for...
<hallyn> slangasek: i'm not sure offhand what the best place is to tell the pkg not to build for 32-bit...
<slangasek> mbiebl: not my idea :-)
<mbiebl> (I probably miss the context, so feel free to ignore me)
<hallyn> (and i frankly find it disturbing...)
<slangasek> hallyn: debian/control + debian/rules - build-dependencies, architecture fields, and the target can all be annotated by architecture
<smoser> "I just want to run something late in boot". we've all come across that. mbiebl . wanting to deal with upstart or sysv init scripts and symlinks and run levels is something entierly different.
<mbiebl> from a package pov or sysadmin?
<mbiebl> and no, I don't think it's a good idea, fwiw
<SpamapS> slangasek: admins don't modify files.. but they do work collaboratively on automation .. and having to first agree on the framework for rc.local.d is a barrier to system usage. If we called it '/etc/lateboot.d' and just made it a convenience dir, would that make more sense?
<slangasek> mbiebl: /etc/rc.local.d obviously wouldn't belong in a package
<slangasek> since it extends /etc/rc.local, which is not for packages
<slangasek> SpamapS: again, how late is late
<slangasek> I think this is underspecified at the moment
<smoser> slangasek, i dont think that arguing "rc.local is unknown" is really relevant.
<slangasek> hmm?
<slangasek> if you want to define something that extends rc.local with rc.local.d, then obviously you'll get the same semantics
<smoser> you stated that the time frame in which rc.local runs is unknown, which is true. but implying that something that runs right after that is therefore less valuable is i think not relevant.
<slangasek> but I don't think rc.local is actually defined with a guarantee that it happens "at the end of boot", and if it is defined that way, the definition itself is broken thanks to event-based systems
<slangasek> smoser: I'm saying that we shouldn't create something called "/etc/lateboot.d" without first definining what we actually mean by "late boot" and ensuring we can deliver
<hallyn> slangasek: ok thanks, i'll try and get a fix for qemu-linaro
<smoser> slangasek, then we should use rc.local.d because that invents nothing new.
<smoser> it re-uses a broken definition with the same definition
<smoser> :)
<slangasek> smoser: if you wish :)  I'm not opposed to /etc/lateboot.d, I just think it has a prereq
<slangasek> hallyn: I'm already elbow-deep in the package - I can take care of it if you want
<SpamapS> Or fix rc.local to be truly "after runlevel 2 is fully started" by trying to define an event which is emitted after all things started by the transition to runlevel 2 have either changed goals back to stop or emitted 'started'
<SpamapS> But really, I think thats orthogonal to the desire to make it easier to have non-conflicting rc.local modifications by putting in a .d directory.
<smoser> SpamapS, i agree with that (bug so is the transition to upstart ;)
<SpamapS> Though I have to agree that the *right* way is to have an upstart job that is start on stopped rc RUNLEVEL=[2345] .. user education on that may be harder than "look at shiny new /etc/rc.local.d"
<mbiebl> SpamapS: the rc.local concept is broken (especially with an event based init), so I don't get why you want to extend a broken concept.
<mbiebl> but I better just shut up now...
 * micahg is syncing ca-certificates and crossing his fingers
<mbiebl> SpamapS: that is rc.boot all over again...
<hallyn> slangasek: oh, missed that - that'd be terrific, and i'll look at how you did it and learn :)  thanks
<SpamapS> mbiebl: its crap. I agree. But its not going away. rc.local *is not* going away, ever.. busy admins without time to learn the intricate event interactions will always want to run something "late".
<slangasek> SpamapS, mbiebl: we could certainly do away with /etc/init.d/rc.local in favor of an /etc/init/rc.local that's 'start on stopped rc [...]', in any case
<slangasek> but that's not actually a material difference from what we currently do
<mbiebl> SpamapS: that's the crux, what exactly is "late"? imho that just makes it easier for admins to shoot themselves in the foot
<slangasek> mbiebl, SpamapS: right; as more jobs move to upstart, rc.local is likely to be running *before* most services have started
<SpamapS> slangasek: indeed, thats basically a wait() call later. ;)
<SpamapS> slangasek: so how do we simplify their life. Could we have a job which lists all of the expected events a system will receive and have that be the sync point..
<SpamapS> actually.. hm
<SpamapS> this is where the 'network-services' job comes in handy
<SpamapS> if we make all things follow that, instead of runlevel 2, then we can say when it transitions to 'started', all normal network services are ready.
<SpamapS> something to think about for 12.10 (assuming the systemd flying monkies don't carry us away)
<slangasek> SpamapS: so jobs would be 'start on starting network-services', and rc.local would be 'start on started network-services'?
<SpamapS> slangasek: and stopped rc RUNLEVEL=[2345]
 * slangasek nods
<quadrispro> eh-ehy! hi all!
<soren> Is there anything about the (PPA) buildd's that might prevent me from readlink()ing /proc/<PID>/exe ?
<soren> infinity: You'd probably know? ^
<hallyn> SpamapS: perhaps i could get you to pick a good start on for libvirt?  bc i've not followed this whole conversation
<SpamapS> start on (runlevel [2345] and stopped networking RESULT=ok)
<SpamapS> hallyn: thats a bit explicit given 11.10+'s guarantee that all of /etc/network/interfaces will be up
<SpamapS> hallyn: until we have the network-services job in place, runlevel [2345] is good
<hallyn> SpamapS: so to be clear, you're saying make it jsut "start on runlevel [2345]" ?
<SpamapS> hallyn: yes if all it requires is all network interfaces and filesystems to be up and mounted.
<hallyn> SpamapS: thanks, put that in my "to do on next push" list
<infinity> soren: Nope, should work fine.
<bdmurray> um, how do you start an ssh server?
<StevenK> sudo start ssh ?
<infinity> (after installing it)
<bdmurray> right and I'm still seeing 'Unknown job: ssh'
<bdmurray> on a precise live cd
<infinity> bdmurray: It's not on the livecd.
<infinity> bdmurray: apt-get install ssh
<infinity> (or openssh-server, which ssh depends on)
<bdmurray> yes when I said right I meant I've installed openssh-server
<bdmurray> and I see ssh in /etc/init.d/
<infinity> So start it from init.d
<soren> infinity: Ok, cool. Thanks.
<infinity> Though installing it should have started it.
<infinity> Unless you had/have no interfaces up.
<bdmurray> how could I have installed it then?
<infinity> Fair point. :P
<StevenK> Via a USB key and dpkg -i :-P
<bdmurray> with /etc/init.d/ssh start I see use service and then 'start: Unknown job: ssh' again
<broder> "service ssh start"
<broder> oh, on lucid you still needed to do "initctl reload-configuration"
<broder> whenever something changed /etc/init
<bdmurray> this is just a precise live cd
<broder> yes, you've installed the server, but because /etc/init/ssh.conf wasn't there at bootup, upstart doesn't know about it
<broder> so run "initctl reload-configuration" to pick up the changes
<infinity> ... really?
<broder> that was definitely the case with upstart for some number of releases
<infinity> Oh, wait, does upstart rely on inotify to scan for new services?
<RAOF> I'm *pretty* sure upstart watches /etc/init with inotify.
<bdmurray> broder: okay that worked thanks
<infinity> If so, overlayfs's lack of inotify support would break that.
<broder> infinity: hahaha. yes, yes it does
<bdmurray> great
<bdmurray> does anybody know of a bug about that being reported yet?
<infinity> apw: Say, have we ever escalated the important of inotify in overlayfs? :P
<infinity> bdmurray: I think Andy has a bug, no idea what sort of movement it has.
<infinity> apw: s/important/importance/
<bdmurray> bug 882147 right?
<ubottu> Launchpad bug 882147 in linux (Ubuntu Precise) "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/882147
<infinity> bdmurray: Should do.
<slangasek> hallyn: pushed my qemu-linaro changes to the UDD branch, if you want to have a gander
<hallyn> slangasek: fetching
<hallyn> slangasek: so will simply not building a new i386 package DTRT?  ( I was expecting to have to create an empty package to invalidate the last one)
<hallyn> (or does it just not matter bc we're still in alpha)
<slangasek> hallyn: oh, I would never do a transitional package for a case where the package was never meant to exist on an arch and can't be used
<slangasek> so this DTRT in the sense that once it's published, I'll yank the i386 binary out of the archive with my AA hat on
<hallyn> slangasek: cool :)  thanks
#ubuntu-devel 2012-02-08
<SpamapS> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<mdeslaur> good morning pitti
<pitti> jibel: is this a temporary glitch, or config error? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-server/lastFailedBuild/ARCH=amd64,LTS=lts,PROFILE=server,label=upgrade-test/artifact/lts-server-amd64/bootstrap.log
<dholbach> highvoltage, happy birthday! :)
<highvoltage> thanks dholbach_ :)
<dholbach_> :)
<jibel> pitti, it was a temporary error. qemu failed to setup correctly for some reason. I restarted the test and it's ok. results will be published in less than an hour
<pitti> jibel: *phew*, thanks
<Sweetshark> lamont, infinity: https://launchpadlibrarian.net/92227283/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.0~rc1-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz <- did you guys also raise the fs-size for amd64? i386 now builds just fine, but amd64 still fails ...
<jamespage> BenC: OK with you if I pickup a merge of nodejs from Debian?  need to transition to new version of libv8
<azza> is anyone online
<seb128> azza, likely yes but most people don't reply to questions which are not asked yet ;-)
<azza> where do i find the download link for ubuntu source code
<azza> or the link to where i can download the files
<seb128> azza, http://www.ubuntu.com/download/ubuntu/download
<seb128> azza, you can get any source on http://launchpad.net/ubuntu as well
<azza> thank you
<seb128> you're welcome
<azza> where can i find the original source code files (that is, official, unedited code)
<seb128> azza, source of what?
<azza> source code files for ubuntu. the code that is used in the version currently released
<seb128> azza, usually it's the orig.tar.gz,bzr2,xz from source packages
<YokoZar> azza: right, it's all available, but it consists of many different components
<azza> i know that
<azza> but where can i find the original files? what's the url to the page containing the original code files?
<YokoZar> For which part?
<azza> the whole OS
<tjaalton> damn.. @pilot in
<tjaalton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton
<lamont> Sweetshark: 1) build URLs rather than buildlog URLs are more useful.  2) it's luck-of-the-draw on what builder you get, with most of them being the standard "too small for you" size...
<lamont> Sweetshark: and fixing the build to not be so fat is going to be (I suspect) a faster path to happiness
<Tm_T> tjaalton: aww
<Tm_T> pulled the short straw?
<tjaalton> Tm_T: just starting late, that's all
<Sweetshark> lamont: so you want me to remove superflous stuff like "running the test suite" from the build?
<justgord> is there a short command to list all installed PPAs ?
<lamont> Sweetshark: that would be one way to do it, I don't know the packgae well enough to recommend specific ways to reduce the disk footprint.  In the case of the kernel, they originally kept all the intermediate stuff around for the entire build (building multiple kernels), and switched to removing the intermediate objects after each kernel was linked
<justgord> to answer my own newbie question - ls /etc/apt/sources.list.d  # lists installed PPAs
<Sweetshark> lamont: well, we just added testing to the build because it is the Right Thing(tm) to do. And I sure will not adapt the package for artificial limitations of the tooling. Tools are a service to the product and not the other way around.
<diwic> is it just me, or did the theming in 12.04 just become very broken?
<seb128> diwic, it's a gtk change how theming work, Cimi has to catch up and update our themes game
<seb128> which is happening to every tarball recently
<seb128> the issue from yesterday should be fixed in a theme update today
<seb128> Cimi just got that done
<diwic> seb128, okay, thanks, no use reporting bugs for that then
<seb128> diwic, there are some bugs on light-themes (ubuntu) already, but yeah, wait for today updates before reporting
<mvo> micahg: synaptic finally build !
<ppisati> i just dist-upgraded, and it seems audio is dead in flash
<ppisati> am i the only one experiencing it?
<lamont> so... wtf would debuild -S decide that we should have 'Architecture: any all'?
<soren> Don't builds on the buildd's run as root?
<soren> (PPA buildd's if it matters)
<soren> If they are running as root, why on Earth would /proc/<pid of some process I started in the build> not be owned by root? It's owned by uid 2001.
<rbasak> Is this fakeroot related?
<soren> rbasak: Shoulnd't be. buildd's don't use fakeroot, AFAIK.
<soren> Gosh.
<soren> They do.
<soren> Ah, that may be debhelper's doing.
<soren> ..but..
<soren> rbasak: Hm. I always assumed this all ran as root.
<soren> Darn it, have to run.
<hallyn> zul: could you please syncpackage -d unstable numactl
<zul> hallyn: yep will do
<zul> hallyn: done
<hallyn> zul: thanks
<micahg> mvo: great, thanks!
<barry> jtaylor: let's coordinate later today or tomorrow on numpy
<doko> stgraber, do you cover cjwatson for the release meeting?
<stgraber> doko: apparently we both replied at the same time, but as I said I'm always attending the meeting anyway and I'm used to writing these team reports, so I'm happy to cover for cjwatson
<doko> ok
<mwhudson> does python2.7-dbg no longer include detached debugging symbols for the non debug python?
<mwhudson> ah it does
<smoser> slangasek, can i get someone on foundations to look at bug 898373
<ubottu> Launchpad bug 898373 in cloud-init (Ubuntu) "fsck.ext3: Device or resource busy while trying to open /dev/xvda2" [High,Confirmed] https://launchpad.net/bugs/898373
<slangasek> smoser: I think you're really going to need someone to look at it from the kernel side
<slangasek> because there's nothing else in the foundations stack that would be holding that device open
<smoser> why? its something user space that has got it open.
<slangasek> how do you know?
<smoser> why would the kernel have it open? it hasnt even been yet told to mount it
<smoser> (yes, i realize thats a good argument for why user space didn't open it too)
<slangasek> smoser: I don't know why the kernel would have it open, but I know there's nothing in the core userspace stack that should have it open :)
<smoser> smb, ^
<smoser> aroudn ?
<smoser> can you think of anything?
<tjaalton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> slangasek: do you have any idea where this warning comes from when i apt-get install packages on precise: Sorry, your system lacks support for the snapshot feature
<tjaalton> jdstrand: hey, what's the status of bug 903752?
<ubottu> Launchpad bug 903752 in tevent (Ubuntu) "[MIR] sssd" [Undecided,Confirmed] https://launchpad.net/bugs/903752
<slangasek> barry: when you apt-get install?  Nope - interesting
<slangasek> barry: maybe check what's installed hooks in /etc/apt/apt.conf.d/ ?
<barry> slangasek: doesn't seem to affect anything, so i've been ignoring it, but it's slightly annoying and da googlz is no help
<barry> ah good idea, will look
<jdstrand> tjaalton: review of ssd is not completed yet. hope to finish soon
<tjaalton> jdstrand: ok, thanks
<psusi> barry: do you have apt-btrfs-snapshot installed?
<barry> psusi: apparently so, that must be it
 * jussi hugs Laney
<Laney> \o/
<bjf> barry, we are seeing some breakage in LP scripts that we have. bug_task.date_created is returning 'unicode' objects when it should be returning 'datetime' objects
<bjf> barry, does this seem like a recent python library change or a LP api change ? (looking for a wild ass guess)
<barry> bjf: probably an lp api change
<bjf> barry, ack, will trot over an inquire there
<barry> bjf: cool
<bjf> barry, by the way, this breakage is only on Precise
<barry> bjf: all signs point to lpapi :)
<EtienneG> guys, I am a bit confused.  I want to request a sync from Debian testing.  I use requestsync, it creates an FFe bug on LP. So far so good.  Now, someone points out that FF is not past so need for an FFe.   But DebianImportFreeze is passed.  Do I need an FFe bug or not?    *confused*
<Sarvatt> EtienneG: feature freeze is feb 16th, debian import freeze just means packages arent automatically pulled from debian and need a sync request/merge  to get updated
<EtienneG> Sarvatt, that makes ton of sense.  So, to do a sync request, should I use syncrequest?
<EtienneG> (sorry to be so daft, I am a little slow)
<Sarvatt> requestsync, just dont pass -e that you passed to it
<EtienneG> Sarvatt, ah ha!  then, *that* is what I did wrong
<EtienneG> Sarvatt, thanks mucho
<TheMuso> diwic: I'm onto the alsa conf.d bits, I used the wrong path. :S
<highvoltage> devious secure boot details revealed in Windows 8 announcement: http://www.youtube.com/watch?v=1rHceul_3U8&feature=related
<bdmurray> barry: I'm inclined to think that bug 898851 might be fixed in aptdaemon
<ubottu> Launchpad bug 898851 in aptdaemon (Ubuntu) "update-manager crashed with TypeError in function(): Must be number, not tuple" [High,Incomplete] https://launchpad.net/bugs/898851
<bdmurray> but without knowing which version of update-manager those people had installed when the crash happened its hard to tell
 * Sweetshark -> eod
<Ampelbein> bdmurray: Doesn't the Dependencies attachment contain the needed version? update-manager-core 1:0.154.6
<adam_g> stgraber: ping
<bdmurray> Ampelbein: that attachment gets (or was getting) removed by the apport-retrace - there is a change that stops that
<bdmurray> and when I said which version of update-manager I meant aptdaemon
<bdmurray> but the dependencies.txt thing is still true
<stgraber> adam_g: pong
<Ampelbein> bdmurray: ok, didn't know it was removed when apport sets dupes.
<bdmurray> well it should stop soon
<adam_g> stgraber: some issue in openstack and i just noticed differing return iproute return codes between versions: http://paste.ubuntu.com/834491/  which ive tracked tohttp://git.jauu.net/?p=iproute2.git;a=commitdiff;h=7397944de6c11519a5951fc1bcff20225e71c4bd  figured id ask you, if that is a known thing and an issue anywhere else
<stgraber> adam_g: I don't believe I saw something else break because of it though I'm guessing some other things probably didn't like the change in behaviour ...
<adam_g> hmm, actually that git repositroy is not the upstream, but in any case...
<adam_g> stgraber: first place ive noticed any breakage, and a quick check going back as far as maverick shows 254
<stgraber> adam_g: do you know if the issue was reported in the Debian BTS?
<stgraber> adam_g: the only change I made to this package is adding a Multi-Arch field, so I'd rather avoid diverging more for a package that seems pretty well maintained in Debian
<barry> bdmurray: i think so too actually, but as you say it's hard to tell, so that's why i marked it incomplete
<adam_g> stgraber: nope. i wasn't suggesting we patch, just curious if you knew anything about it
<stgraber> adam_g: nope, first time I hear about it. Thanks for mentioning it though, might end up useful when trying to track down some bugs ;)
<arges> slangasek, hello
<arges> slangasek, i just backported a patch for lp #688550 to lucid. what format would you prefer for the SRU of that bug? should i create a bzr branch? provide the debdiff? or something else?
<ubottu> Launchpad bug 688550 in portmap (Ubuntu Oneiric) "portmap/statd can not be restarted" [Undecided,Triaged] https://launchpad.net/bugs/688550
<tomreyn> pitti + others: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/873424/comments/10 says this fixed package was built on Jan 13, but it doesn't seem to be available in oneiric-proposed, yet? Did it FTB?
<ubottu> Ubuntu bug 873424 in update-manager (Ubuntu Oneiric) "ask me later fails" [Medium,Fix committed]
<slangasek> arges: IMHO, debdiffs are the most practical to work with for SRU
<arges> slangasek, ok cool. will provide that then
<bdmurray> tomreyn: looking
<bdmurray> tomreyn: its there but the patch happens to be incomplete
<bdmurray> speaking of that if I want to upload a new version to proposed when one is already there what do I do?
<stgraber> doko: ping
<stgraber> doko: Depends: libc6 (>= 2.15), libdbus-1-3 (>= 1.0.2), libexpat1 (>= 1.95.8), libnih1 (>= 1.0.0)
<stgraber> doko: that's in nih-dbus-tool
<stgraber> doko: obviously doesn't work with libc6 being 2.15~pre6-0ubuntu10 :)
<stgraber> doko: and it's breaking my upstart upload as a result (which build-depends on nih-dbus-tool)
<doko> stgraber, I uploaded libnih for a rebuild. is this one already installed?
<stgraber> doko: yes, that's the one that's not installable
<doko> shit
<stgraber> doko: the new binaries from the libnih rebuild have libc6 (>= 2.15) instead of (>= 2.15~)
<doko> cursing the use of private symbols in libnih
<doko> yeah, will have to ask for a manual eglibc build
<stgraber> doko: I'll be looking for another libnih upload before doing a mass give back of upstart (though it managed to build on at least i386 where the new nih wasn't published yet ;))
<doko> stgraber, yeah, will work for armel and armhf. you need to edit the libc b-d
<doko> s/-d/d/
<doko> s/b-d/d/
<doko> stgraber, please use a b-d on (>= 2.15). I'm preparing packages
<doko> stgraber, ohh, lucky day! this dependency only is in nih-dbus-tool, not libnih1, so it builds normally
<stgraber> doko: yep, it's just blocking upstart as upstart b-d on nih-dbus-tool :)
<stgraber> doko: anyway, I'm monitoring LP now, as soon as it's published I'll give back the upstart FTBFS and everything should be good
<doko> who cares about upstart ;-P
<stgraber> (well, except for upstart's test failing on some architectures but that's not new, my change doesn't touch the code ...)
<stgraber> yeah, nobody uses that ;)
<tomreyn> bdmurray: thanks for reporting back. and i'm afraid i have no idea what to do then...
<bdmurray> tomreyn: what do you mean? or what problem are you having?
<tomreyn> bdmurray: i'm saying i have no idea how to upload a new version to proposed when one is already there. and my problem would be that check-new-release-gtk currently in oneiric-proposed still fails (we discussed this here an hour ago).
<bdmurray> tomreyn: oh, I'm working on a new version of update-manager for oneiric proposed.
<tomreyn> cool, thanks.
#ubuntu-devel 2012-02-09
<slangasek> barry: I see bug #911124 is assigned to you; did you sync sphinx from Debian (pulling python-support back into main ;)?
<ubottu> Launchpad bug 911124 in sphinx (Ubuntu) "Please sync python-sphinx 1.1.2 from Debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/911124
<barry> slangasek: i'm on it already :)
<slangasek> ok :-)
<pitti> Good morning
<pitti> tomreyn: no, it's in: update-manager | 1:0.152.25.6 | oneiric-proposed | source, all
<pitti> barry, SpamapS: still here?
<ajmitch> morning pitti
<mbiebl> pitti: morning!
<pitti> hey mbiebl
<pitti> mbiebl: another early riser :)
<mbiebl> you've been up since an hour ago :-)
<mbiebl> pitti: just had a look a the pygobject bug
<mbiebl> looks like the upload wasn't bug-fix only
<mbiebl> http://git.gnome.org/browse/pygobject/commit/?id=ee62df4d2fc0cc63c2f29d3ad9b47b875dbd5f89
<mbiebl> this requires glib 2.31
<pitti> oh, how's that?
<mbiebl> I'm wondering how it built...
<pitti> GValue isn't exactly new?
<mbiebl> pitti: the _schar functions were added after .30
<pitti> /build/buildd-pygobject_3.1.0-1-i386-WbEc0E/pygobject-3.1.0/gi/pygi-property.c:124:13: warning: implicit declaration of function 'g_value_get_schar' [-Wimplicit-function-declaration]
<mbiebl> right, that's the one
<pitti> mbiebl: indeed; I'll revert that bit then, it doesn't work for chars yet anyway
<pitti> mbiebl: thanks for spotting
<mbiebl> np
<mbiebl> looks like python on the kbsd buildds is borked
<mbiebl> at least the test-suite runs into a timeout
<mbiebl> the same for pygtk which I uploaded yesterday
<pitti> I want to backport some more fixes from trunk anyway
<pitti> yeah, saw :/
<pitti> mbiebl: still curious how that linked..
<mbiebl> I first thought you had built in on precise
<mbiebl> when I realised that the other buildds had built it, too
<mbiebl> hm, it's a loadable module
<pitti> mbiebl: so, sorry for that blunder; will fix right away
<mbiebl> nah, np
<mbiebl> pitti:  #659184 is the corresponding bug report
<pitti> ah, thanks; I just had a look, seems it's not in the PTS yet
<pitti> mbiebl: uploaded
<mbiebl> pitti: thanks
<hyperair> jpds: ping.
<hyperair> jpds: would you be interested in getting ubumirror into debian?
<pitti> jibel: I believe the current alternate/server failure galore is due to a missing linux-meta upload for -15; I can't prove it, though, there are no useful logs
<pitti> apw, smb`: ^ I can haz -meta for -15?
<pitti> I'd upload it myself, but that would disrupt your git
<jibel> pitti, good morning. right kernel version change.
<jibel> pitti, colin uploaded d-i 20101020ubuntu107
<pitti> yes, and the seeds are fine, too; just linux-meta missing
<pitti> jibel: seems oneiric-universe is again due to bug 917153
<ubottu> Launchpad bug 917153 in libreoffice (Ubuntu Precise) "failed to upgrade from oneiric to precise: /usr/lib/libreoffice/program/unopkg.bin: error while loading shared libraries: libicule.so.48: cannot open shared object file: No such file or directory" [High,Triaged] https://launchpad.net/bugs/917153
 * smb looks slightly sleepy
<smb> wassa?
 * pitti hands smb a cup of steaming coffee
<smb> pitti, Thanks, got one in front of me... now I just need to drink it :)
<jibel> pitti, re kernel version, i386 passed, isn't it just a matter of respining amd64 to pull latest packages ?
<pitti> smb: do you think it's responsible to do a changelog-only package upload at this hour? :-)
<pitti> jibel: no, it didn't? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=i386,LTS=non-lts,PROFILE=universe,label=upgrade-test/
<jibel> pitti, I meant alternate/server install failure
<pitti> jibel: oh, sorry, wrong failure
<smb> pitti, Certainly not. Not sure _when_ I did the last upload of a kernel package
<pitti> jibel: hm, curious how it passed -- it shouldn't
<smb> Eh I man I can try again :)
<jibel> pitti, packages are not the same version on both arch
<smb> If I finally am able to read correctly
<pitti> jibel: I figure if we respin now, i386 will fail as well
<pitti> jibel: I think I'll wait on smb's -meta upload, and respin when that published
<jibel> pitti, k
<pitti> jibel: ah, seems lucid->precise got a little further after the qtdbus fix; at least we now have two errors in one log, yay for slight parallelization :)
<jibel> :)
<pitti> jibel: are you interested in tracking the bugs (just filed 929381, for example), or don't you care?
<smb> pitti, Now lets see how much worth that coffee was... Think I uploaded some meta
<pitti> smb: AFAIK it's just bumping the version in changelog, no other changes
<smb> pitti, It is. And there was something already in git with that
<pitti> smb: but as it's in git, us mere mortals can't easily do that
<smb> Probably just held back until the compile
<diwic> dholbach, ping
<pitti> smb: ah, uploaded in ogasawara's name :) thanks
<dholbach> diwic, pong
<smb> pitti, Yeah, did all the real work anyway :)
<diwic> dholbach, two things: First, I vaguely remember me signing up for "writing a launchpad script that summarises ppa owners"
<jibel> pitti, I am interested if they are found with automated tests.
<pitti> jibel: yes, both are
<pitti> (that's where I got them from)
<diwic> dholbach, the idea was to contact ppa owners to see if they wanted to step up and maintain the official thing
<pitti> jibel: they seem to be at least partially fallout from the kvm envirionment
<pitti> jibel: bug 929381, bug 929382
<ubottu> Launchpad bug 929381 in cgroup-lite (Ubuntu Precise) "init script fails to start" [High,New] https://launchpad.net/bugs/929381
<ubottu> Launchpad bug 929382 in lxc (Ubuntu Precise) "package fails to install: SIOCSIFNETMASK: Cannot assign requested address" [High,New] https://launchpad.net/bugs/929382
<pitti> cgroup-lite installs fine on my real workstation, tryign in kvm now
<diwic> dholbach, but I'm overwhelmed with audio bugs, and it feels more efficient if I do the audio bugs and someone familiar with launchpad hacking would do that script
<diwic> dholbach, and I can't even find the blueprint. Do you remember which one it was?
<diwic> dholbach_, did you get all of that?
<dholbach> diwic, pong
<diwic> dholbach, repeating in PM
<dholbach> no, I'm sorry
<dholbach> ok great
<pitti> jibel: hm, is /proc/cgroups nonempty in the environment of the upgrader?
<pitti> jibel: oh, I figure it's running under a lucid kernel; I'll try reproducing that
<jibel> pitti, looking
<pitti> jibel: hold on for now, I'll debug this locally first
<jibel> pitti, k
<smb> pitti, Just from my random playing around with things. Usually when you looked at lxc you were told in the past that you need to mount cgroups somewhere. So I would not find it completely unexpected that some prople will have it in the fstab already.
<pitti> smb: ah, so perhaps lxc failed because cgroup-lite failed
<smb> pitti, Might be. I remember having seen something (if I could remember the symptoms) coming from automount when in precise cgroups gets mounted before and you still have it in fstabs
<smb> Not sure that was detected in the installer...
<smb> I mean the problem
<smb> Think the upgrade went ok, but on reboot there was something wrong until I cleaned up fstab
<pitti> right, I can reproduce on a lucid live system
<alkisg> Hi, are there plans to switch thunderbird to the rapid release cycle too, so that we have thunderbird 10, 11 etc  in Lucid? Or that was only for firefox?
<pitti> I think it's the plan
<alkisg> Thank you :)
<pitti> micahg or chrisccoulson will know better
<pitti> jibel: hm, I cannot reproduce bug 929382 in a lucid live system
<ubottu> Launchpad bug 929382 in lxc (Ubuntu Precise) "package fails to install: SIOCSIFNETMASK: Cannot assign requested address" [High,New] https://launchpad.net/bugs/929382
<apw> smb, did you do the meta upload?  else will do it shortly
<pitti> apw: yes, it's in
<smb> apw, done
<apw> cool
<pitti> https://launchpad.net/ubuntu/+source/linux-meta/3.2.0.15.15
<cjwatson> pitti: d-i failed to build on amd64 which didn't help.  I've just uploaded a fix.  I haven't looked at the logs but I doubt linux-meta had much to do with it.
<pitti> cjwatson: ah, ok; but it should have independently failed due to the API mismatch, I guess?
<cjwatson> that's exactly what the failure was
<pitti> cjwatson: thanks
<cjwatson> arguably the CD build should have failed but it would still have been a failure :)
<cjwatson> not sure why that didn't happen, no time to look now
<pitti> cjwatson: np
<eitch> join #evince
<jacekmigacz> how to remove seat once created by lightdm?
<pitti> infinity: it seems https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu7/+build/3197190 is stuck (didn't change in over an hour)
<pitti> could that be killed, and we'll try it again?
<pitti> cjwatson, jibel: d-i and linux-meta are published, rebuilding alternate/server
<infinity> pitti: Stuck how?  Are you sure you're not just being impatient? :)
<pitti> infinity: "stuck" in the sense of https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu7/+build/3197190 not changing for two hours
<infinity> pitti: It historically takes about 4.5 hours on a machine of that class.  I wouldn't complain until it passes that.
<pitti> the build should take 1:15 in total
<pitti> (the last build did, anyway)
<pitti> infinity: but 2 hours to compile a single .c file?
<infinity> pitti: The last build was probably on a faster machine...
<pitti> infinity: well, if that's "normal", I can certainly just wait further
<infinity> I'm willing to believe it's broken, but there are also some things that, yes, will take hours on a single file.
<infinity> So, until it passes 5ish...
<infinity> https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu2/+build/2571092 <-- 4.5h
<pitti> ack
<pitti> infinity: thanks!
<infinity> pitti: The good news is that Very Soon Now, all those old machines are going away.
<mpt> mvo, hi, did you ever see <https://lists.ubuntu.com/archives/ubuntu-devel/2012-January/034714.html>?
<nava> Hi all
<nava>  I make a design for let users to choose want to have full screen with luncher or without it. where should i send it ?
<pitti> stgraber: I would appreciate if you could take a look at bug 929382 and see whether my proposal would be acceptable
<ubottu> Launchpad bug 929382 in lxc (Ubuntu Precise) "package fails to install: SIOCSIFNETMASK: Cannot assign requested address" [High,New] https://launchpad.net/bugs/929382
<pitti> hallyn: ^ you, too, as the last uploader
<pitti> if it is, I'd like to do an upload
<mvo> mpt: hello! no I didn't, but I'm also not involved with apt-mirror
<mpt> oh, ok
<pitti> infinity: ah, done now \o/
<lamont> sh: 1: /usr/bin/gdbus: not found
<seb128> lamont, install glib?
<lamont> seb128: I'm more curious as to why the natural order of things didn't install it for me...
<lamont> current precise, mythbuntu box
<seb128> lamont, what do you run to get that error?
<lamont> apt-get update
<lamont> Hit http://us.archive.ubuntu.com precise-updates/universe Translation-en
<lamont> sh: 1: /usr/bin/gdbus: not found
<lamont> Reading package lists... Done
<lamont> to place it in context
<lamont> which appears to be apt.conf.d/20packagekit just blindly doing its thing
<lamont> I shall file the packagekit bug
<seb128> yeah
<seb128> what an idea to use that ;-)
<lamont> yeah, hopefully it's a more valid bug that my last one. :(
<lamont> E: Internal Error, No file name for libc6
<lamont> uh... wut?
<lamont> (apt is mad about libc6 deps, apt-get -f install fails as above)
<melodie> hi
<melodie> I am actually editing a page of the wiki containing infos for build requests for Openbox 3.5.0. I will now add imlib2 devel which is an optional lib.
<melodie> could someone tell me what is the right name for this package at Ubuntu ?
<melodie> http://openbox.org/wiki/Help:Installing
<melodie> imlib2 devel when used as a build request allows getting icons in the openbox menus (since 3.5.0) such as here:
<melodie> http://i.minus.com/ipNlKuTlCJr25.png
<melodie> this is why I am adding it to this page now.
<melodie> cking, ? AaronMT ? do you know about imlib2 devel package name please ?
<AaronMT> Please dont ping random people.
<melodie> you just arrived. sorry (oops)
<melodie> :)
<melodie> are you angry ?
<pitti> melodie: libimlib2-dev
<melodie> I thought it was important to let some members of the devel team I will edit this page
<pitti> "apt-cache search imlib dev"
<melodie> thanks pitti
<pitti> -dev is the standard name for development packages in Debian/Ubuntu
<melodie> pitti, this is not my distro. I did same at fedora devel chan. just giving info about this edit while looking for the right package name. thanks
<pitti> mvo: do you know what's wrong with https://jenkins.qa.ubuntu.com/view/Precise/job/precise-softwarecenter-amd64/ and what it's supposed to test?
<pitti> melodie: you can use the same for Debain
<pitti> Debian
<mvo> pitti: its the software-center testsuite
<pitti> melodie: (and Mint, etc.)
<melodie> I was just wondering about it : thanks !
<pitti> mvo: ah, like running "make check" in a checked out tree?
<pitti> mvo: is it supposed to fail, or is that due to running in the autotest environment?
<mvo> pitti: its the environment I think
<pitti> mvo: well, "supposed to fail" is certainly bogus, I  meant "fail locally as well"
<melodie> done : http://openbox.org/wiki/Help:Installing#Dependencies_in_Ubuntu_and_Debian
<jibel> pitti, it does a make check
<melodie> have a nice day, bye now !
<jibel> pitti, and probably failing because a test requires and external resources blocked by a fw
<pitti> https://jenkins.qa.ubuntu.com/view/Precise/job/precise-softwarecenter-amd64/45/console is a bit of a messy read
<pitti> Unable to find the server at recommender.ubuntu.com
<pitti> yeah, seems like it
<pitti> DatabaseOpeningError: Couldn\'t stat \'/var/lib/apt-xapian-index/inde
<pitti> x
<pitti> that seems solvable, though
<mvo> pitti: yeah
<seb128> hum
<seb128> https://bugs.launchpad.net/bugs/929384
<ubottu> Ubuntu bug 929384 in nux (Ubuntu) "unity_support_test crashed with SIGSEGV" [High,Confirmed]
<seb128> the libc update broken nvidia drivers
<seb128> "Happens here too, when running the nvidia-current driver from precise.
<seb128> It also makes gnome-shell crash on startup.
<seb128> this is caused by the eglibc update (2.13-24ubuntu4 -> 2.15~pre6-0ubuntu10). I reverted it, it's fine now."
<tseliot> seb128: I haven't updated the nvidia driver for a while now so eglibc is more likely to be the culprit
<hallyn> pitti: that (bug 929382) sounds fine
<ubottu> Launchpad bug 929382 in lxc (Ubuntu Precise) "package fails to install: SIOCSIFNETMASK: Cannot assign requested address" [High,Triaged] https://launchpad.net/bugs/929382
<hallyn> pitti: i think it's what i meant to do
<seb128> tseliot, right, I just wonder if the nvidia drivers are doing something weird that lead to issues with the new libc
<seb128> or if that's a bug with libc itself
<seb128> cjwatson, slangasek, pitti, skaet: ^ nvidia drivers broken by the libc update today
<seb128> that let quite some users without a working computer
<seb128> not sure what to do about it but I think it should be raised
<seb128> that's on precise
<tseliot> seb128: maybe we should revert the upload and then I can discuss this issue with Nvidia
<seb128> tseliot, not easy as fabian wrote
<seb128> "(but reverting this libc6 is not easy as more packages are rebuild for it, leading to failing GLIBC_2.15 version checks everywhere)"
<pitti> seb128: that was already with the 2.15~pre version, I take it?
<pitti> because 2.15 final is still building
<seb128> pitti, yes
<rbasak> Is there a way to run sbuild but with an extra local repository added to resolve build dependencies from?
<seb128> rickspencer3, is there any official way to raise precise brekages?
<rickspencer3> seb128, I'm not sure what you mean
<seb128> rickspencer3, the libc update from today break nvidia binary drivers and let precise user without a working machine
<seb128> rickspencer3, I mentioned it on the channel but nobody seems to be around
<seb128> rickspencer3, is there any official way to flag that we have an issue and should deal with it?
<rickspencer3> seb128, can you raise it with the +1 maintenance team?
<seb128> rickspencer3, should that be broadcasted in some way so users don't upgrade?
<rickspencer3> oh
<seb128> rickspencer3, where,who,how?
<rickspencer3> is barry barry warsaw?
<jelmer> rickspencer3: the one and only
<rickspencer3> seb128, also, can you tell skaet, she can use the twitter/identica account to broadcast a "do not upgrade" message
<seb128> rickspencer3, I did a 25 minutes ago, waiting for her to be around or reply
<Laney> can you get it blocked on the mirrors?
<seb128> Laney, I would like to know ;-)
<Laney> heh
<seb128> but seems none of the rt people are around atm
<Laney> #-release informs me that skaet might be in mumble
<Laney> go gatecrash :P
<skaet> seb128, rickspencer3 - on a call on 10.04.4,  reading backscroll.   Will get on it.
<seb128> skaet, thanks
<cjwatson> I'm not sure what we can do about libc - as noted, reverting it would cause widespread chaos
<cjwatson> do we know precisely why nvidia breaks?
<cjwatson> (getting it blocked on the mirrors would be very bad too IMO)
<seb128> cjwatson, no, just limited to what is in the bug
<seb128> I don't have an nvidia card myself
<seb128> but olli and some other people on IRC ran into the bug
<cjwatson> there doesn't seem to be a useful stacktrace in the bug
<seb128> no :-(
<stgraber> yeah, we already rebuilt libnih on the new libc and then uploaded a new upstart, so reverting it would likely break most if not all existing systems.
<seb128> I'm not sure we have debug symbols for nvidia binary drivers
<cjwatson> I suspect it needs somebody with an affected system who's competent to debug it interactively, at least as far as diagnosing e.g. an affected libc symbol or something
<seb128> tseliot, ^
<seb128> tseliot, do you have any precise nvidia box, any chance you could look at it?
<smoser> hey. i'm in need of some help. bug 929523.
<ubottu> Launchpad bug 929523 in bacula (Ubuntu) "bacula-director does not start, dummy libbaccats " [Undecided,New] https://launchpad.net/bugs/929523
<cjwatson> if we're lucky we just need to rebuild something
<ahasenack> I have an nvidia desktop box that wasn't updated yet, running precise 32bits
<pitti> mvo: the point release process says "Ping mvo to update meta-release file on http://changelogs.ubuntu.com/"
<tseliot> seb128: yes, I do and I'll have a look at it
<pitti> mvo: this is "release - 6 days", which would be tomorrow
<barry> pitti: hey, can we chat sometime today about +1?
<tseliot> seb128: unfortunately my 1st machine with nvidia died (I don't know what hardware issue that is but I can't even access the BIOS). Fortunately I also have a laptop that I can use but it will probably take a while...
<mvo> pitti: ok, I guess ideally this should be done on the day of the release instead, its just chaning the number from 10.04.x to x+1
<smoser> sorry.. back with a bit more information on that bug now. (in the last comment).
<smoser> i'm running into dh_shlibdeps complaining but it seems that bacula is doing what it intends to do.
<pitti> mvo: ah, thanks
<pitti> mvo: I'll update the wiki page
<pgraner> cjwatson, I have an un updated nvidia box, if you want me to break it
<mvo> pitti: thanks!
<pitti> barry: In a meeting, and need to run out in ~ 20 mins, but yes, let's have a quick chat in a sec
<barry> pitti: cool. i'm over in #ubuntu+1-maint
<tjaalton> could an archive admin give gst-plugins-bad a push, it's in NEW due to libs&dev being split
<pitti> tjaalton: done
<tjaalton> pitti: thanks! now on to gstreamer-vaapi..
<rbasak> Is there a way to run sbuild but with an extra local repository added to resolve build dependencies from?
<cyphermox> rbasak: when I've had to do that I resorted to editing sources.list in the source schroot and doing the build, then reverting the change once done.
<cyphermox> rbasak: I have no idea how it would be done otherwise -- anyway, sbuild doesn't seem to have a switch to do it.
<rbasak> Thanks cyphermox - maybe I'll patch sbuild to add a switch one day, but I'll use your hack in the meantime
<rbasak> cyphermox: did you use an http repo somewhere, or a local file one? And if a local file one, did you add that to the source chroot or something?
<cyphermox> it might be useful, if say you want to enable universe for just one build, test builds against a particular PPA, etc.
<rbasak> I'm trying to do a test rebuild of a dependent package - it fails in a PPA, but I can't figure out why.
<cyphermox> rbasak: I was using reprepro to manage a local repository hosted in on my system with apache, in ~/public_html/
<rbasak> (it succeeded for me doing it manually in a chroot)
<janimo> rbasak, sbuild --pre-build-commands
<janimo> I wonder if it cannot add a new apt sources file in /
<rbasak> janimo, the part I don't understand is how to get my local repository into the chroot
<janimo> rbasak, ah the files themselves from a local filesystem?
<rbasak> yes
<cyphermox> rbasak: with that --pre-build-commands I guess you could echo a file in /etc/apt/sources.list.d for your local repo
<janimo> chroot-setup-commands too
<rbasak> I have a pile of debs. Usually I "dpkg-scanpackages . /dev/null|gzip -9>Packages.gz" and then add "file:///path/to/dir /" in sources.list
<janimo> not sure how to copy files in there though
<cyphermox> rbasak: oh, that's why I was using a local apache
<rbasak> yeah that's the bit where I'm stuck :)
 * janimo used sbuild a week ago for the first time
<cyphermox> otherwise if you use the security team's sbuild howto to bind mount /home you could leave the files there?
<rbasak> Ah, a bind mount would be awesome
<cyphermox> rbasak: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment ; point number 5
<rbasak> thanks cypermox - but what are ddebs?
<cyphermox> debugging symbols packages
<rbasak> I see - so irrelevant to me?
<cyphermox> rbasak: probably
<brendand> did the google talk plugin break in precise for anyone else?
<slangasek> brendand: intermittently and possibly related to the eglibc upgrade today
<brendand> slangasek, audio works for first few seconds and then stops
<slangasek> yes, that's the issue I've seen
<om26er> did anyone Pilot today?
<slangasek> brendand: however, I wasn't able to reproduce it again after shuffling packages, so I haven't raised a bug
<brendand> slangasek, what did you do?
<slangasek> brendand: I downgraded eglibc, then upgraded it again, and then I couldn't reproduce the bug... so it may have actually been a bug somewhere in the audio stack
<brendand> slangasek, what's the older version?
<slangasek> brendand: 2.13-<foo>
<brendand> slangasek, by eglibc you mean libc-bin, libc6, or all of them?
<seb128> slangasek, brendand: maybe that's the bug which was in yesterday's alsa update and fixed today?
<seb128> the configs were installed in the wrong dir
<seb128> TheMuso fixed that today
<brendand> seb128, nope i applied the workaround today. besides that didn't affect the googletalk plugin
<seb128> dunno then
<achiang> brendand: broken for me too
<tseliot> seb128: according to ricotz the new Nvidia driver seems to work with the new eglibc. I'll test it here and upload it (if successful) today
<tseliot> seb128: Sarvatt brought this to my attention
<seb128> tseliot, ok, great, thanks
<quadrispro> hi all
<quadrispro> ehy tseliot ! how are you?
<tseliot> quadrispro: hey, I'm still a little sick but fine otherwise, you?
<quadrispro> tseliot, here the same, the flu has gone away right 2 days ago. I'm not used to this deep cold weather :/
<tseliot> quadrispro: yes, I guess that's the problem..
<slangasek> brendand: all of them, they have to be upgraded and downgraded in step
<slangasek> brendand: note that at this point, due to rebuilds against the new version of glibc, you would also have to downgrade cups, bluez, pulseaudio, and libnih1 (used by upstart)
<doko> slangasek, hmm, I don't have any nvidia hw :-/
<geddy> barry, ping
<slangasek> doko: I only assigned the eglibc task to you, if that's what you mean
<doko> ahh, ok
<geddy> barry ping
<tseliot> seb128: unfortunately I'm unable to reproduce the problem on my laptop with the new eglibc...
<Sarvatt> tseliot: every dupe i've opened so far is i386, that may explain why you can't reproduce on amd64
<tseliot> Sarvatt: good point, I was starting to suspect i386...
<seb128> bdmurray, why did you assign that gnome-screenshot upstream behaviour change to our team? it's not really a bug...
<seb128> it's not a regression either, it's a on purpose behaviour change
<bdmurray> seb128: I think its a huge usability issue
<seb128> bdmurray, it's not really
<bdmurray> How are people supposed to find their screenshots?
<seb128> bdmurray, the new behaviour is how any phone or tablet out there will behave (yeah, they are different devices but still)
<seb128> bdmurray, how do they find them on phones and tablets?
<bdmurray> I don't think you take screenshots with a phone rather you take pictures and the photo software shows you the picture
<seb128> bdmurray, well android tablets have a screenshot button on their 4 standard buttons which behaves like gnome-screenshot does, sound and visual effect and storing in the images directory
<seb128> bdmurray, also the non interactive mode is only on screenshots, if you run gnome-screenshot from unity you will get an ui as before
<bdmurray> seb128: part of assigning the bug to your team was to get an authoritative statement about the bug / workflow.  I'd imagine that bug will receive quite a few duplicates and people are interested in this information.
<seb128> bdmurray, ok, I'm commenting on it, I just disagree with the regression tagging I think ;-)
<seb128> though I'm not sure we will keep the new behaviour I think we should not hurry in reverting but rather see how the new workflow works for users
<bdmurray> I can see how regression- tags can be subjective in design chagnes like this.
<bdmurray> Its still not clear to me how I am supposed to find the screenshot.  Where do I navigate to?
<bdmurray> View Photos in the dash?
<seb128> bdmurray, they should show in the dash "recent files" on the dash home screen
<seb128> bdmurray, if they don't atm we will fix that (need to check if that works)
<seb128> bdmurray, the xdg Image folder is also in the bookmarks and easily accessible, if you know screenshots go there it's obvious to find them
<seb128> (which is what phone and tablets do as well, you just need to know how to access your image dir)
<seb128> bdmurray, in fact that works, they show there
<kklimonda> hey, is it possible to change dch --increment behaviour? it always adds ubuntuX suffix which isn't really what I always want
<micahg> kklimonda: what's the use case?
<micahg> kklimonda: and welcome back :)
<kklimonda> ah yes, I haven't been around in quite a while.. hey everyone :)
<kklimonda> micahg: I maintain some packages that are not part of Ubuntu - they are either for debian or for a project based on Ubuntu.
<kklimonda> ah, I can pass --distributor to override that
<micahg> yeah
<micahg> just found that in the source
<slangasek> kklimonda: you can also pass -U, which is shorter
<kklimonda> great, I can even use DEB_VENDOR to override that
<doko> bryceh, can you confirm that an updated glibc will fix the nvidia issue?
<kklimonda> slangasek: hmm, doesn't seem to work
<kklimonda> ah
<bryceh> doko, Sarvatt and tseliot say there is an nvidia driver update which will resolve it
<kklimonda> sorry, I've misunderstood you
<kklimonda> it works just fine :)
<bryceh> <tseliot> bryceh: it seems that the latest nvidia (beta) driver solves the problem ^^
<Sarvatt> bryceh: argh
<tseliot> bryceh: I take back that. Apparently it doesn't
<Sarvatt> bryceh: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/929384/comments/16
<ubottu> Ubuntu bug 929384 in nvidia-graphics-drivers (Ubuntu) "nvidia drivers broken by the recent libc update on i386 arch" [High,Confirmed]
<bryceh> doko, which glibc update?
<doko> bryceh, there's only one, 2.15
<cjwatson> has anyone managed to get valgrind output?
<tseliot> cjwatson: do you suspect some major leak on i386?
<slangasek> probably not a leak, but maybe some memory smashing that valgrind could pick up on
<cjwatson> right
<tseliot> interesting
<cjwatson> Is https://bugs.archlinux.org/task/27737 possibly related?
<slangasek> possibly, but I don't see any of those problems here on amd64
<slangasek> oh, linked to nvidia
<doko> I don't see the delays with firefox and chromium
<slangasek> sorry, had a different eglibc issue on the brain :P
<cjwatson> ah, here we go
<cjwatson> https://bugzilla.redhat.com/show_bug.cgi?id=737223
<ubottu> bugzilla.redhat.com bug 737223 in glibc "gl applications (using libGL.so) crash with glibc-2.14.90-8 when using proprietary NVIDIA driver" [High,Closed: errata]
<cjwatson> http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0c95ab64
<cjwatson> doko: ^-
<doko> cjwatson, the fix is in the package
<cjwatson> oh, already?
<ahasenack> valgrind output: http://pastebin.ubuntu.com/835568/
<cjwatson> doko: I don't see it ...
<cjwatson> looking in lp:ubuntu/eglibc
<doko> hmm, only part of it:
<doko> /usr/share/sounds/speech-dispatcher/test.wav
<doko>               if (copy == NULL)
<doko>                 _dl_fatal_printf ("out of memory\n");
<doko>               l->l_libname->name = l->l_name = memcpy (copy, dsoname, len);
<doko>             }
<slangasek> I wonder, should this bug be reproducible without nvidia hardware just by installing the lib
<cjwatson> incidentally, lp:ubuntu/eglibc is not up to date with precise
<doko> ahh, I'll commit
<cjwatson> slangasek: if this patch is what fixes it, that looks quite plausible
<ahasenack> it's very similar to that rh bug
<slangasek> yep, testing now
<ahasenack> interesting LD_DEBUG options
<cjwatson> ahasenack: please try running whatever you were running with 'LD_DEBUG=version'
<ahasenack> it says the option "version" is unknown, I tried help and there are others
<ahasenack> all quite verbose
<cjwatson> ahasenack: er, right, =versions
<ahasenack> standard shell redirection to a file doesn't work
<cjwatson> 2>
<cjwatson> i.e.  LD_DEBUG=versions glxinfo 2>x
<ahasenack> oh, duh
<Sarvatt> slangasek: some of the bug reporters mentioned it still happened when they switched the gpu to intel but still had nvidia installed, yep it should
<ahasenack> nm
<ahasenack> cjwatson: versions: http://pastebin.ubuntu.com/835583/
<cjwatson> looks very much like the same bug to me.
<ahasenack> and with LD_DEBUG=all
<ahasenack> http://pastebin.ubuntu.com/835584/
<cjwatson> cf. https://bugzilla.redhat.com/show_bug.cgi?id=737223#c12
<ubottu> bugzilla.redhat.com bug 737223 in glibc "gl applications (using libGL.so) crash with glibc-2.14.90-8 when using proprietary NVIDIA driver" [High,Closed: errata]
<ahasenack> got the symbol lookup error too
<ahasenack> buried in those logs
<cjwatson> slangasek: any luck?
<slangasek> cjwatson: still working on it, just found that my i386 chroot didn't have eglibc upgraded yet
<slangasek> yep, got it
<slangasek> doko: it's reproducible in an i386 chroot with nvidia-current+mesa-utils installed, without needing nvidia hardware
<bryceh> I'm updating my nvidia hw test box, but will be a few more minutes
<slangasek> bryceh: reproducible in any i386 chroot
<smoser> hey...
<cjwatson> slangasek: did you say you saw audio problems as well?  I wonder if that's https://bugzilla.redhat.com/show_bug.cgi?id=769421
<ubottu> bugzilla.redhat.com bug 769421 in glibc "NPTL issues with 2.14.90-25 - mostly pulseaudio but others as well" [Unspecified,Closed: errata]
<cjwatson> cf. http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=ead7c0f93b194f6e3a100f249edd76c826debaef
<smoser> i'm looking at bacula, and its not getting correct mysql libs because it is explictly checking (in configure) for certain paths that the lib might exist in
<slangasek> cjwatson: yes; bug #929713
<ubottu> Launchpad bug 929713 in eglibc (Ubuntu Precise) "audio unreliable with eglibc 2.15" [Critical,Confirmed] https://launchpad.net/bugs/929713
<smoser> and that does not include /usr/lib/x86_64-linux-gnu
<smoser> configure looks like this: http://paste.ubuntu.com/835598/
<Daviey> smoser: doesn't it make sense to patch that in as an include path?
<elmo> I have those audio problems too, FWIW
<smoser> should i just patch it?
<smoser> it seemed wrong to patch a 'configure'
<cjwatson> is the configure script generated using autoconf?
<Daviey> smoser: are there any .in files?
<cjwatson> if so, you should patch the generating files
<cjwatson> the modern form is .ac
<Daviey> ah yeah, right
<smoser> cjwatson. yes, but i dont think they're in the upstream tarball
<cjwatson> although it might well be in .m4 somewhere
<cjwatson> smoser: crazy upstream
<cjwatson> if they don't ship the autoconf input, you don't have a lot of choice *shrug*
<cjwatson> yes, it's wrong, but they were wrong first
<cjwatson> playground logic
<smoser> so cjwatson you were saying 'configure.ac' ?
<cjwatson> yes
<smoser> yeah. not there.
<Daviey> smoser: I don't think you gain much by trying to do it 'right'
<cjwatson> smoser: sure it is, in the autoconf/ subdirectory.
<cjwatson> configure.in
<Daviey> ah.. /me retreats.
<cjwatson> autoconf/bacula-macros/db.m4 is probably what you want to change.
<slangasek> cjwatson: the "NPTL issues" backtrace is not dissimilar to my quodlibet backtrace; checking the other apps where I'm seeing it
<smoser> cjwatson, thank you.
<elmo> how did that NPTL reversion not get into eglibc 2.15 upstream?  that bug is almost two months old
<bryceh> elmo, nvidia might not be as high a priority for them?
<elmo> bryceh: nvidia is the rtld.c change - the broken NPTL patch affects audio on machines with no nvidia
<cjwatson> bryceh: the NPTL reversion is not about nvidia
<cjwatson> I don't have an answer for why the Fedora patch fixing nvidia isn't upstream either, mind
 * cjwatson -> pub, sod it
<cjwatson> slangasek: I tentatively added a Fedora bug task for the audio bug
<slangasek> cjwatson: seen, thanks
<doko> the pthread_cond_wait issue is debian/patches/i386/local-pthread_cond_wait.diff, isn't it?
<doko> cjwatson, ^^^
<slangasek> doko: I'm seeing the NPTL issue on amd64
<elmo> me too
<doko> hmm, reverted in Debian:
<doko>   * patches/amd64/cvs-pthread_cond_wait.diff: remove as it seems to cause
<doko>     some issue with some kernels.  Closes: #651746.
<slangasek> the remaining problem doesn't appear to be kernel-related
<slangasek> and the proposed fix isn't to remove the assembly version altogether, but to patch it?
<bryceh> doko, I've got 2 systems (one Nvidia, one Intel) reproducing the nvidia bug.  Both have libc 2.15 installed.
<seb128> slangasek, do you know if somebody has been looking at upgrading valgrind's suppr files for multiarch? I've been adding local ones to clean my logs but I noticed some are in the default.suppr but the paths don't match because of multiarch dirs
<slangasek> seb128: I haven't heard this mentioned before now, no
<seb128> slangasek, hum, ok
<seb128> slangasek, i.e /usr/lib/valgrind/default.supp has
<seb128>    zlib-1.2.x trickyness (1b): See http://www.zlib.net/zlib_faq.html#faq36
<seb128>    Memcheck:Cond
<seb128>    obj:/*lib*/libz.so.1.2.*
<slangasek> seb128: seems like it should be a simple bugfix though, right?
<seb128> slangasek, yeah, it's just adding * to the lib paths in a file :p
<seb128> slangasek, I was just wondering if somebody was working on it or if that was at least reported
<seb128> slangasek, I will open a bug in the bts if there isn't one yet
<slangasek> well, I'm not subscribed to the valgrind bugs :)
<slangasek> ok
<seb128> slangasek, let me check
<seb128> slangasek, btw I sent you automake1.11 multiarch diff to the bts, it got merged but they credited me even if I mentioned the patch was yours
<seb128> slangasek, sorry for stealing credit from you ;-) on the positive side it allowed us to sync automake1.11 again
<slangasek> seb128: no worries, my name is in enough changelogs :-P
<infinity> slangasek: Since we started trimming changelogs, I feel much less cool.
<infinity> slangasek: That recursive grep in /usr/share/doc isn't what it used to be.
<slangasek> :-)
<doko> bryceh, slangasek, cjwatson, elmo: test packages (amd64) on http://people.canonical.com/~doko/tmp/eglibc-2.15/
<doko> and i386
<bryceh> doko, looks good.  installed those debs on the broken nvidia box, rebooted, and unity came right up
<slangasek> interestingly, it seems to still be failing in my chroot
<slangasek> ah, no
<slangasek> it works, I just had to install libc-bin with it so the package actually got configured
<bryceh> verified NVIDIA loaded, no X errors, dmesg is clean
<doko> bryceh, amd64, or i386?
<bryceh> doko, i386
<slangasek> doko: glxinfo i386 nvidia chroot test succeeded here
<slangasek> testing the audio regression now
<bryceh> bryce@porlock:~$ uname -a
<bryceh> Linux porlock.bryceharrington.org 3.2.0-15-generic-pae #24-Ubuntu SMP Tue Feb 7 23:30:35 UTC 2012 i686 i686 i386 GNU/Linux
<bryceh> bryce@porlock:~$ apt-cache policy libc6
<bryceh> libc6:
<bryceh>   Installed: 2.15-0ubuntu2
<bryceh>   Candidate: 2.15-0ubuntu2
<doko> network sucks here, apt-get update taking now over 15min ...
<bryceh> doko, what's in that 0ubuntu2 version?
<doko> bryceh, the two patches identified by cjwatson
<bryceh> doko, also verified it fixes the unity_support_test crash on the intel box
<slangasek> doko: audio is testing out ok
<slangasek> jdstrand: care to test the updated libc from http://people.canonical.com/~doko/tmp/eglibc-2.15/ with me in G+?
<jdstrand> slangasek: sure. a browser restart should be enough I'm assuming, correct?
<slangasek> jdstrand: no, the gtalk plugin starts its own server process, which is the one that hangs; so you want 'killall -9 GoogleTalkPlugin'
<slangasek> jdstrand: possibly with a 'killall plugin-container' thrown in for flavor
<jdstrand> heh, ok. downloading-- it'll probably be a few minutes
 * slangasek nods
<jdstrand> slangasek: ok, ready
<jdstrand> joining
 * jdstrand adjusts hair
<tedg> hyperair, Do you have thoughts on this patch?  https://code.launchpad.net/~ballogy/libindicate/fix-mono-location/+merge/92313
<tedg> hyperair, I always forget where things are supposed to go with Mono :-)
<doko> jdstrand, do you see core dumps without adjusted hair? ;-P
<jdstrand> worked great :)
<jdstrand> doko: hehe-- maybe that was my problem before :)
<hyperair> tedg: if you gacutil, don't bother installing it in assemblydir.
<hyperair> tedg: afaik gacutil does that for you
<hyperair> er i think
<tedg> hyperair, How do I know if I gacutil? ;-)  It's used several times, I'm not sure which usages are important.
<hyperair> tedg: gacutil -i installs into the GAC.
<hyperair> tedg: if you do that, installing it into assemblydir like what it was before the patch was applied, and even after the patch is applied, is redundant.
<hyperair> tedg: take a look at taglib-sharp's src/Makefile.am
<tedg> hyperair, So the patch is from the arch guy, in theory it helps their packaging.  Would you say it's a no-op for Ubuntu then?
<hyperair> tedg: we'll probably just ignore things found in /usr/lib/mono
<hyperair> debian policy is to stick things into /usr/lib/cli in the .deb, and then gacutil -i it in postinst
<hyperair> whereas upstreams should just gacutil -i straight.
<hyperair> tedg: is ballogy around on irc somewhere?
<hyperair> tedg: also i really need to sleep.
<tedg> hyperair, Not sure, I've not talked with him/her on IRC
<tedg> No IRC listed on LP either.
<hyperair> tedg: well i'm pretty sure the Right Wayâ¢ for upstreams is what taglib-sharp is doing
<hyperair> so please look at how it's done there and follow suite.
 * hyperair â bed
<hyperair> it's 5am and i need to wake up early tomorrow
<tedg> hyperair, Okay, thanks!
<tedg> 'night
 * tedg doesn't want to be technical, but it already is early tomorrow :-)
<slangasek> tedg: you don't *want* to be technical, you just find that it's an innate aspect of your makeup? :)
<tedg> slangasek, I blame society
<jono> hey folks
<jono> is sound still broken in Precise for flash?
<jono> still having issues with playing flash videos and using G+
<slangasek> jono: eglibc 2.15-0ubuntu2 will fix it; building now
<slangasek> (separate issue than the flash one yesterday)
<jono> slangasek, awesome, thanks
<jono> oh I see
<dobey> slangasek: is that eglibc build the fix for the omg nvidia issuse?
<elmo> dobey: yes
<dobey> yay
<dobey> was it an issue in __memcpy_ia32 btw? i'm hitting an odd crash in it right now, and just wondering if it's related
<slangasek> dobey: no, it was in the linker
<dobey> ah ok
<dobey> then perhaps it's time for some bourbon, if i'm going to have to actually debug this crash in gnome-keyring, in introspection, in python :-/
<hrw> [6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~OQhi
<hrw> does someone know is reproductible hangs of chromium and firefox are due to eglibc 2.15 or other recent upgrade?
<slangasek> hrw: haven't seen any reports of browser hangs due to eglibc 2.15; there are two critical bug fixes in eglibc 2.15-0ubuntu2
<hrw> slangasek: here, I run chromium or firefox, enter address and it hangs - have to xkill
<slangasek> hrw: arch?
<hrw> amd64
<slangasek> hmm
<slangasek> I've been running firefox w/ eglibc 2.15 for a week, no issues
<RAOF> hrw: Possibly flash being crazy?
#ubuntu-devel 2012-02-10
<RAOF> Wasn't there some flash-not-working-right with the new eglibc?
<slangasek> yes, but that shouldn't hang the browser
<slangasek> but the flash issue is one of the two fixed in -0ubuntu2
<hrw> RAOF: ok, disabled all plugins
<hrw> ok, not hangs now so far. just waiting for packets which got stuck in queue to this 33600 modem which whole conference is using
<hrw> thanks
<hrw> ok, was too optimisti ;( but ignore me - I lack mood to debug it - its too late in day
<slangasek> hrw: just in case, please try upgrading libc6 when you have a chance (just published)
<hrw> slangasek: I will
<hrw> once will get there with elinks ;D
<slangasek> heh
<hrw> ok, ubuntu2 installed, reboot to get them reloaded
<hrw> yay! much better
<nigelb> I didn't expect a bourbon ping in this channel :)
<nigelb> Problems of having that as a safe word ^-^
 * pitti retries the webkit build which causes so much uninstallability; the i386 build hit -ENOMEM
 * micahg hopes a rebuild helps
<pitti> it's on a different buildd now
<pitti> can only cross fingers
<pitti> we really need a real staging area, such as -proposed
<RAOF> I thought precise-proposed was already open, for exactly that reason?
<pitti> yes, we just didn't start using it yet
<pitti> everyone uses PPAs
<RAOF> Yeah, I'm not entirely sure why :)
<pitti> but we can't do binary copies from them
<pitti> would be better to use precise-proposed, for new X.org, eglibc, gtk, glib etc. versions
<pitti> I guess we just need to start trying
<pitti> it's some extra overhead as they need to be hand-approved, but archive admins wouldn't actually need to read debdiffs
<RAOF> We can do binary copies from (specially calibrated) PPAs, but you're right; they're not available to all.
<RAOF> Is it trivial to auto-approve everything in precise-proposed until release?
<broder> i wonder if my pre-release backports patch already covers this...
<broder> let me look
<broder> although i suspect you want s/release/archive freeze/ or something
<ajmitch> broder: the one for opening up backports next week or so? :)
<broder> yup!
<ajmitch> what are the restrictions going to be on uploading new packages there?
<broder> uh, i believe the plan approved by the TB was that all uploads would land in UNAPPROVED
<broder> like they do now
<broder> so that might not help RAOF's problem
<broder> though i will note that currently it is not possible to upload to a non-RELEASE pocket if a release is not either frozen or stable
<ajmitch> are pre-release uploads to backports likely to be copied to the main archive for q when it opens?
<RAOF> Not really RAOF's problem; I'm a canonical employee, so can request a super-PPA that *can* be binary-copied from.
<broder> heh, fine
<broder> ajmitch: they *will* be copied to q. that's part of the rules
<RAOF> But a problem in general, yes :)
<ajmitch> broder: ah, excellent :)
<broder> though "copy" may actually be "script bumping the version number and re-uploading"
<ajmitch> either way, it's useful
<broder> the approved plan also auto-files bugs against backports if a change to the release pocket should "supersede" a change in backports
<broder> to tell us that we need to do a merge
<ajmitch> it means less bugging the release team for FFEs for new packages
<broder> right. in general, the intent is to remove some of the pressure for FFEs all aroudn
<broder> or at least part of the intent
<broder> https://lists.ubuntu.com/archives/technical-board/2011-November/001137.html is my post with the updated proposal based on TB feedback
<broder> the stuff at the end of the e-mail is more interesting/relevant than the quote
<ajmitch> thanks
<broder> pitti: ^ fyi, when i was looking into the pre-release backports stuff, i discovered that you can only upload to a non-RELEASE pocket if the series status is FROZEN, CURRENT, or SUPPORTED, so we can't actually use -proposed right now
<pitti> broder: oh, so that was it
<pitti> because we did use devel-proposed in the last days of a release heavily, but at that time it was FROZEN
<broder> yeah, i'm surprised we didn't notice it, though, since we've been using 0-day srus fairly heavily lately
<dholbach> good morning
<dholbach> It's Sponsorship Friday! :)
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, seb128
 * dholbach hugs seb128
<dholbach> let's see how many pilots we can fit into the topic ;-)
<seb128> dholbach, let's drive carefully, it's snowing out there ;-)
<dholbach> haha
<tjaalton> same here, haven't tried figuring out why
<apw> presumably its s/w center that won't install, so it gets removed and to remove it we lose ubuntu-desktop
 * apw will try and reinstall it shortly
 * diwic runs upgrade instead of dist-upgrade today.
<seb128_> could somebody reject https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040
<apw>  libwebkitgtk-1.0-0 : Depends: libwebkitgtk-1.0-common (>= 1.7.5) but 1.7.4-0ubuntu1 is to be installed
<seb128> apw, wait on the i386 build to success so the arch:all binaries are available, amd64 built first
<apw> this new interdep between arches is just causing chaos
<seb128> apw, it's not new?
<seb128> it's there since ubuntu is there
<seb128> but yeah, it's annoying
<seb128> dholbach, can you set https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 to merged or rejected or something?
<seb128> dholbach, the fix got uploaded in a sru but I can't edit the merge request
<dholbach> seb128, no, but I think pitti can
<dholbach> and now fixing a bug from 2007-10-11, thanks Pojar George :)
<seb128> dholbach, I hate how we can't edit those buggy merge requests ourself :-( do you know if anybody in launchpad is working on solving that issue?
<dholbach> I think somebody is, but I forgot the bug number and stuff
<seb128> dholbach, ok, don't bother
<apw> seb128, the new multiarch dep between i386 and amd64 is new
<apw> the randomly wanting to deinstall things is not new indeed, but we are triggering it in a whole lot of new ways now
<seb128> apw, well in this case it's not multiarch, it's good all arch:all built on i386 and binaries depending on common = binary:Version
<apw> ahh i see, my error
<seb128> we should teach people to just use upgrade :p
<apw> yeah except that doesn't work either
<apw> in fact there is nothing safe one can do, pretty much ever
<seb128> apw, well it will list those webkit binaries as on hold until they are built on i386
<apw> and stupidly the most dangerous information is always off the top of ones screen
<seb128> doing upgrade is a safe bet
<seb128> then try dist-upgrade and see the few potential issues
<seb128> upgrade at least helps to clear the one screen set of upgrade issues
<apw> though you'll just end up with a hybrid pig over time
<seb128> and let you with a small comprehensive set
<apw> perhaps we should reorder the list, so removes are last
<apw> then i might notice them :)
<seb128> yeah
<apw> or perhaps we could mark ubuntu-desktop in some way as 'ask them to type the alphabet backwards before allowing me to be deinstalled'
<seb128> or we should make dist-upgrade do an upgrade first and show you the remaining part for confirmation then
<apw> yeah, perhaps i'll alias it to that and see how that plays out
<apw> how much less often i host my machine
<apw> seb128, i thought the issue with using upgrade && dist-upgrade was that recommends arn't done for upgrades
<apw> so you end up having to do like upgrade && dist-upgrade && install ubuntu-desktop^ to get a full install
<seb128> oh, maybe
<seb128> so screwed either way? ;-)
<apw> that was kinda my point.  you do one and everyone tells you the other is the only safe one ... but clearly thats NP complete
<dholbach> looking at mame now
 * dholbach hugs jamespage
<dholbach> jamespage, seb128: I wonder if we're going to set the record of most concurrent patch pilots today :)
<seb128> ;-)
<jamespage> **\o/**
<seb128> cjwatson, on https://bugs.launchpad.net/ubuntu/+source/vim/+bug/856779 you wrote that you were going to sponsor to oneiric-proposed, it seems that didn't happen ... did you change your mind (i.e found a bug with the update) or was there an issue with the upload (i.e you forgot or it got rejected or something)
<ubottu> Ubuntu bug 856779 in vim (Ubuntu Oneiric) "gvim slow to respond" [Undecided,In progress]
<seb128> could somebody reject https://code.launchpad.net/~snicksie/ubuntu/oneiric/gdb/fix-for-typo-conjuction/+merge/86026 ?
<seb128> could somebody set https://code.launchpad.net/~3v1n0/ubuntu/oneiric/bamf/libreoffice-fixes/+merge/85199 as merged?
<seb128> looking to https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/911342
<ubottu> Ubuntu bug 911342 in jackd2 (Ubuntu) "Please merge jackd2 1.9.8~dfsg-1 (main) from Debian unstable (main)" [Undecided,Confirmed]
<dholbach> looking at unity-mail
<jamespage> looking at bacula lzo support
<dholbach> can somebody please mark https://code.launchpad.net/~geoubuntu/ubuntu/precise/tvtime/tvtime-1.0.2-fix_fulscreen_crash/+merge/92027 as 'rejected'? pitti or cjwatson maybe? (explanation in last comment)
<dholbach> ciao fabbione - auguri! :)
<fabbione> dholbach: thanks dude :)
<dholbach> taking a look at gedit-developer-plugins
<jamespage> looking at nova
<dholbach> WAH Launchpad DB offline
<Daviey> jamespage: nova?
<jamespage> Daviey: looked at - zul has it in hand!
<jamespage> unsub'ed sponsors
<Daviey> cool
<jamespage> looking at dahdi-linux
<jamespage> looking at celt upgrade - no action required from sponsors so unsubscribing.
<cjwatson> apw: your query didn't get through, so I'm not sure what you were talking about :)
<cjwatson> seb128: upgrade isn't intrinsically safe, BTW, because it means your system will forget about new Recommends that were introduced by the packages it did manage to upgrade
<apw> cjwatson, does a subsequent apt-get install ubuntu-desktop^ fix the missing recommends ?
<seb128> cjwatson, yeah, apw pointed that as well, I didn't notice that until today, thanks ;-)
<cjwatson> dholbach: tvtime> done
<seb128> cjwatson, can you do those as well?
<seb128> could somebody reject https://code.launchpad.net/~snicksie/ubuntu/oneiric/gdb/fix-for-typo-conjuction/+merge/86026 ?
<seb128> could somebody set https://code.launchpad.net/~3v1n0/ubuntu/oneiric/bamf/libreoffice-fixes/+merge/85199 as merged?
<seb128> <seb128> dholbach, can you set https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 to merged or rejected or something?
<seb128>  
<cjwatson> seb128: gdb, bamf> done
<seb128> cjwatson, thanks ;-) oh and did my question gvim went through? I timeouted at some point
<cjwatson> apw: provided that the only Recommends in question are within the ubuntu-desktop task, which is likely to cover some but not all
<cjwatson> seb128: yeah, I was just paging through the easy stuff in scrollback before looking at the stuff I'd have to think about ...
<seb128> cjwatson, ok, thanks ;-)
<cjwatson> seb128: my mailbox says the vim upload was rejected without explanation
<cjwatson> perhaps a mistake by somebody?  it should still be resurrectable from the REJECTED queue if somebody wants to ...
<seb128> cjwatson, can you reject https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 as well? thanks
<cjwatson> a few ntfs-config uploads were rejected without explanation around the same time
<apw> cjwatson, i had an overlapping apt-get update or similar break an inprogress dist-upgrade; this stopped the dist-upgrade dead in its tracks with a lock failure, but also left the system with 'E: Internal Error, No file name for libpam0g', install -f didn't fix it, i had to hand dpkg -i the file in /var/cache/apt/archive to recover
<seb128> cjwatson, hum, did you get an accept,waiting in the queue and then rejected later? i.e it got rejected by somebody?
<cjwatson> seb128: gnome-shell> done, though maybe you could leave a more detailed explanation in that case
<seb128> cjwatson, doing so
<cjwatson> apw: wacky, that should just have been impossible
<cjwatson> seb128: accept/reject> no
<cjwatson> just waited in the queue for a while and was then rejected
<cjwatson> in retrospect I suspect that somebody fumble-fingered the web interface and didn't notice
<cjwatson> it can be all too easy
<seb128> right
<apw> cjwatson, tjat was my feeling :/  still in case you see it agian, dpkg -i is your friend
<seb128> do you still have the source? will you reupload?
<cjwatson> seb128: LP still has it - it's in the rejected queue
<cjwatson> pitti or RAOF could resurrect it from there
<seb128> cjwatson, ok, thanks
<seb128> I will check with them
<cjwatson> https://launchpad.net/ubuntu/oneiric/+queue?queue_state=4&queue_text=
<cjwatson> tjaalton: it is annoyingly slow; in that ~12h there's the delay of Debian publishing the package (unavoidable, IIRC up to 6 hours or so) and then a possible delay of up to 7 hours before LP notices.  https://bugs.launchpad.net/launchpad/+bug/812597
<ubottu> Ubuntu bug 812597 in Launchpad itself "gina imports from debian arrive too slowly" [High,Triaged]
<om26er> dholbach, Hey! can you please sponsor this https://code.launchpad.net/~om26er/ubuntu/oneiric/nux/sru-888039
<tjaalton> cjwatson: yeah I was able to sync them maybe an hour ago
<tjaalton> thanks for the bug, subscribed
<seb128> dholbach, om26er: I can look at the nux sru
<om26er> seb128, great, this https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/sru-764330/+merge/92296 as well
<om26er> both should improve the overall performance of oneiric
<seb128> om26er, I'm less sure about this one
<seb128> dvv had https://code.launchpad.net/~vanvugt/ubuntu/oneiric/compiz/fix-763005-oneiric/+merge/90254 in the queue before you
<om26er> seb128, dvv handed me the patch since the initial patch created a regression
<seb128> om26er, can you merge both, test if the update work and resubmit yours?
<seb128> om26er, should we drop the one I just pointed then?
<om26er> seb128, this branch seems to fix another bug,
<om26er> seb128, should i merge his fix in as well?
<seb128> om26er, I'm confused by you saying that his fix is buggy
<seb128> is it buggy or not?
<om26er> seb128, its not buggy, its fine
<seb128> om26er, ok, can you include this one as well in your update? no need to do 2 different srus and wait  week between those
<om26er> seb128, yes doing that now, thanks
<seb128> om26er, thank you
<Sweetshark> requesting jonos rockstar skills urgently for https://plus.google.com/u/0/115750270177636397262/posts/9fNFpwRW3XK
<dholbach> jamespage, seb128: I'll take a break from Sponsorship Friday and leave a few items for others now :)
<jamespage> dholbach, ack
<dholbach> I'd still love to see the topic overflow :-P
<seb128> dholbach, same here, lunch time
<seb128> dholbach, what was the count when we started? we are to 48
<dholbach> seb128, yesterday when I sent the reminder mail it was 66
<seb128> dholbach, ok, progress, still some way to do but for a morning it's not bad ;-)
<dholbach> in my notes I have 9
<om26er> seb128, this https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/perf-sru/+merge/92444 :)
<seb128> dholbach, enjoy your lunch!
<dholbach> you too :)
<seb128> om26er, thanks, did you test run it? maybe put it in a ppa for the w.e, I doubt any sru member will approve it before monday anway
<seb128> om26er, I will upload it to the queue today but still would be good maybe to get a bit of extra testing meanwhile
<om26er> seb128, I have tested the patches from his ppa, I am going to put it into my ppa and test these two patches
<Laney> can someone make https://code.launchpad.net/~l3on/ubuntu/oneiric/pdf-presenter-console/sru-922752/+merge/90606 go away from the queue? dholbach nacked it
<om26er> Wellark, Hi
<seb128> cjwatson, ^
<cjwatson> Laney: done
<Laney> ty
<om26er> Wellark, can you please look into bug 930088 and tell what info would be needed.
<ubottu> Launchpad bug 930088 in mobile-broadband-provider-info (Ubuntu) "Add 'Ptcl EVO' as a CDMA internet provider " [Undecided,New] https://launchpad.net/bugs/930088
<Laney> cleaned two items without doing any work ;-)
<jml> how does one tell if a particular package is on the CD?
<glenn> When a patch is supplied to debian upstream, what exactly are the steps to get it into the ubuntu package?
<glenn> there is a bug on launchpad, and a patch in the debian branch of the package
<cjwatson> jml: grep the .manifest and/or .list files alongside the CD images
<jml> cjwatson: thanks.
<cjwatson> glenn: has it actually been uploaded to Debian?
<glenn> cjwatson: good question :)
<cjwatson> or committed to a branch maintained by the Debian maintainer?
<glenn> cjwatson: yeah the patch was supplied on github, and the maintainer put it in
<cjwatson> maybe URLs would help :-)
<glenn> its in the bug report :)
<glenn> https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/920995
<ubottu> Ubuntu bug 920995 in fail2ban (Ubuntu) "SysV status script returns the wrong exit code when fail2ban is not running" [Undecided,New]
<cjwatson> so not yet uploaded to Debian
<glenn> can i see that in the debian packages list?
<cjwatson> http://packages.qa.debian.org/fail2ban
<cjwatson> given that we aren't carrying any Ubuntu patches to fail2ban, I think the simplest answer is to wait for it to be uploaded to Debian, and then sync it
<cjwatson> https://wiki.ubuntu.com/SyncRequestProcess
<glenn> cjwatson: is the fail2ban package on ubuntu a complete debian copy ?
<cjwatson> yes
<cjwatson> this advice only applies to precise; if it needs to be fixed in stable releases too, then https://wiki.ubuntu.com/StableReleaseUpdates
<glenn> cjwatson: well, the exit status wasnt complient to lsb init
<cjwatson> I understand that it is a bug
<glenn> cjwatson: yeah it is
<glenn> cjwatson: my first fixed bug though :)
<cjwatson> there are however many bugs that we cheerfully don't fix in stable releases; there is a higher threshold for making any change there
<glenn> yeah im reading the link
<cjwatson> in any case, I carefully didn't express any opinion about whether this one should be fixed in stable releases or not, because I haven't thought about it enough
<cjwatson> but the links above should help
<glenn> cjwatson: so you actually saw the bugs i created
<cjwatson> well, only when you linked to it
<glenn> ah ok
<glenn> this is new to me so im trying to find out the workflow
<cjwatson> I don't have any involvement with fail2ban
<cjwatson> just offering general advice
<glenn> cjwatson: the sablereleaseupdates dont mention anything about lsb compliance
<glenn> +t
<cjwatson> nor should they
<cjwatson> the SRU guidance offers general advice on the kinds of things that are suitable for stable updates; its purpose isn't to enumerate all the things that might be considered severe enough
<cjwatson> you're meant to apply judgement :-)
<glenn> cjwatson: severe severe... i wouldnt call it severe.. was just bad init script coding :)
<glenn> its a bug though
<cjwatson> sure; most bugs I fix, I only fix in the development release
<glenn> so precise?
<glenn> or onerice
<cjwatson> precise
<glenn> k k
<glenn> so you fixed the kernel bug to?
<glenn> with 3.2.0-14
<cjwatson> huh?
 * cjwatson <- not a kernel hacker
<glenn> im using preseed, and it didnt work for 5 days
<glenn> after alpha2
<glenn> nm then :)
<cjwatson> the installer was broken for a few hours due to kernel ABI desync; not five days, I don't know what that's about
<cjwatson> probably nothing to do with me :)
<glenn> cjwatson: i had to wait the whole weekend before preseed could install linux-virtual
<glenn> and some more days
<glenn> it was failing on the wget with a weird error while it was on the repo's
<glenn> but thanks for your answers regarding the package
<glenn> :)
<glenn> cjwatson: is it correct that if the package was uploaded to debian and the debianimport for precise wasnt frozen yet, it wouldt have been auto-synced? and becuase of that i would now have to make a sync request?
<cjwatson> glenn: correct
<glenn> cjwatson: thats pretty cool :)
<jibel> sbeattie, could you look at bug 930115 . regression in lucid
<ubottu> Launchpad bug 930115 in php5 (Ubuntu Lucid) "php5 5.3.2-1ubuntu4.13 introduced regression in magic_quotes_gpc" [High,Triaged] https://launchpad.net/bugs/930115
<seb128> grrrrrr
<seb128> sorry guys
<seb128> https://launchpadlibrarian.net/92511991/buildlog_ubuntu-precise-i386.webkit_1.7.5-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> "/usr/bin/ld: failed to set dynamic section sizes: Memory exhausted"
<seb128> lamont, is there any way to get webkit i386 sent to build on a beefy builder?
<seb128> we are going to have that amd64 installability issue for at least another 8 hours
<seb128> since that build failed again
<cjwatson> Does a sufficiently beefy builder exist?
<lamont> what is the failure mode
<lamont> doh
<seb128> cjwatson, I don't know, what can we do if not? :-(
<seb128> cjwatson, it built on amd64
<cjwatson> Good question
<cjwatson> We could perhaps assign an amd64 builder to i386 temporarily
<cjwatson> Although I'd be surprised if there weren't already i386 builders in the same class
<lamont> seb128: I'd like to see someone analyze it, but roseapple and allspice are both G6's with what should be plenty of RAM
<glenn> cjwatson: the fail2ban package was just uploading to debian-unstable. could you show me an example requestsync commandliner for me on how to request a sync for it?
<lamont> and swap
<seb128> lamont, well my local built leaded to a ld using a bit over 3gb of ram
<cjwatson> glenn: 'requestsync fail2ban precise'
<lamont> penguins, antartic bases, elements, fruits, starnames.  later is better
<lamont> seb128: file an RT about it mentioning RAM needs, and the builder that failed it?
<seb128> lamont, if that helps...
<cjwatson> so it requires PAE on i386, basically?
<lamont> then get some buildd admin (webops?) to stuff the bunch on manual, score you through the roof, and automaticize allspice, and then the rest once it gets your package
<seb128> I could also retry the build and see if I get lucky, but each retry takes some 8 hours and we have amd64 in uninstallable stable due to arch all,any mismatches
<lamont> nice
<seb128> lamont, so rt is the way to go?
<seb128> sending one...
<cjwatson> lamont: allspice is amd64 right now
<lamont> roseapple
<cjwatson> I can try it on roseapple now if there's a credible hope that it should succeed there
<cjwatson> which builders has it failed on so far?
<cjwatson> grr, just loading that build log has rendered firefox entirely unresponsive
<lamont> cjwatson: roseapple or allspice should build it just fine, I expect
<seb128> cjwatson, that built was vernadsky
<seb128> let me see the previous one
<lamont> I suspect that the "not-roseapple" i386 builders all have about 512MB of swap, and 2-4GB of RAM
<lamont> seb128: and the ticket will be a dup of another one that says "review the RAM/SWAP on the builders and make it sane"
<lamont> hints as to what amount of VM is "sane" are very much helpful in that process
<seb128> cjwatson, I didn't keep the email from the previous build
<cjwatson> ok
<seb128> cjwatson, lamont: do we need a r-t or not?
<cjwatson> just waiting for https://launchpad.net/ubuntu/+archive/test-rebuild-20120201/+build/3169749 to finish on roseapple
<cjwatson> we should have an RT so that we don't have to fight with selecting the right builder in future
<seb128> ok
<lamont> seb128: not particularly for your rebuild, but yes, please file one about the memory footprint of webkit
<lamont> mixed in with all that is the presumption that you've already asked yourself "is it sane that ld needs 3GB to link this beast?"
<glenn> cjwatson: its telling me the versions are the same, but it was accepted in debian unstable with a newer version..
<glenn> glenn: should i wait a bit?
<cjwatson> seb128: try ld --no-keep-memory
<lamont> -d unstable
<glenn> mm
<cjwatson> glenn: yes, you'll need to wait for a while
<cjwatson> simplest to just make a note to try it tomorrow
<glenn> lamont: tried that already, didnt help
<glenn> cjwatson: thanks again
<cjwatson> and yes, you will need -d unstable
<cjwatson> but LP needs to have imported the package first
<glenn> k k
<lamont> ah.  that makes it make sense.  thanks cjwatson
<glenn> how much hardware does a amd64 builder have?
<lamont> about 2U
<lamont> :)
<cjwatson> seb128: possibly --reduce-memory-overheads too
<lamont> glenn: they vary
 * lamont -> town
<glenn> who pays for it? :)
<glenn> ubuntu?
<cjwatson> Canonical
<cjwatson> seb128: webkit building on roseapple now, build farm back on autuo
<cjwatson> *auto
<glenn> cjwatson: are you at the ubuntu office? or where is ur working spot
<cjwatson> glenn: most Ubuntu developers work from home
<cjwatson> including me
<glenn> cjwatson: but your doing it for free right
<cjwatson> No, I'm employed by Canonical
<seb128> cjwatson, ok, thanks, I will have a look to --no-keep-memory and --reduce-memory-overheads
<seb128> cjwatson, lamont: rt #50818
<didrocks> hey, for speeding up the call for testing on compiz, is it possible to get a higher build score on those two builds: https://launchpad.net/~didrocks/+archive/ppa/+build/3201504 and https://launchpad.net/~didrocks/+archive/ppa/+build/3201498 ?
<cjwatson> didrocks: done
<didrocks> cjwatson: thanks :)
<glenn> who would someone want to use a builder from canonical, and not your own pc?
<cjwatson> Your own PC can't easily build packages for multiple architectures and publish them on ppa.launchpad.net for people to use conveniently
<smoser> I wonder if someone here could give some quick advice.
<smoser> bug 321091
<ubottu> Launchpad bug 321091 in bacula (Ubuntu) "Bacula fails to install correctly if mysql wasn't installed before" [Medium,Confirmed] https://launchpad.net/bugs/321091
<smoser> if the user does not have mysql installed (apparently also true with postgresql) and types 'apt-get install bacula-director-mysql', then they'll also get mysql.
<smoser> mysql will not be running at the time when bacula's db-config tries to populate mysql.
<smoser> it would seem that "Pre-Depends" would satisfy this, but "You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list"
<smoser> cjwatson, i'm sure you can provide the right answer, so at your convienence, i'd appreciate it.
 * ppisati -> reboot
<slangasek> smoser: which maintainer script is db-config being called from?  if it's from the .config script, a pre-depends doesn't help at all
<smoser>   dbc_go bacula-director-mysql $@
<smoser> is in postinst
<slangasek> smoser: *never* use pre-depends for something needed in the postinst - simple depends is always sufficient :)
<smoser> wait. but also in .config
<slangasek> right, so neither depends or pre-depends helps
<smoser> slangasek, given the warning in the debian manual, i wasn't going to just shove it in there without testing..
<smoser> so you have an idea on what would be correct there?
<smoser> i'm mainly just curios. its been around for quite a while.
<cjwatson> config *must* only use Essential packages and debconf
<cjwatson> the config script seems to only use db-config if it's available, which is in principle ok
<cjwatson> unless it also needs mysql to be available at *that* point; the bug report isn't terribly clear to me
<slangasek> cjwatson: db-config-foo could be available at .config time without the database backend itself being available
<cjwatson> right, I thought of that part-way through
<cjwatson> the only suggestion I have is to check for db presence as well at config time, and make sure the config db_inputs are repeated in the postinst so that if they can't be preconfigured due to lack of database at preconfiguration time then the questions are at least asked when the postinst is run
<cjwatson> there is no way to fix this using dependency relationships
<smoser> cjwatson, slangasek gracias.
<roadmr> kelemengabor: are you here?
<kelemengabor> roadmr: yes
<kelemengabor> feel free to ask :)
<roadmr> kelemengabor: thanks! our package (checkbox) imported a bunch of .po files but they contain some commented, duplicate definitions at the end of the files
<roadmr> kelemengabor: these are keeping it from building properly :( a quick fix is to delete all those entries (always at the end of the file)
<roadmr> kelemengabor: I wanted to ask if that's OK, or if there's a better way to handle this
<roadmr> kelemengabor: it looks like our PO files are wrong as described in LP bug 333281, but that is Fix Released so I'm not sure why we're getting those bad POs
<ubottu> Launchpad bug 333281 in Launchpad itself "po export error duplicate message definition" [High,Fix released] https://launchpad.net/bugs/333281
<kelemengabor> looking...
<roadmr> thanks!
<kelemengabor> which branch has this files?
<roadmr> kelemengabor: https://code.launchpad.net/~roadmr/ubuntu/precise/checkbox/0.13.1-retry
<dholbach> seb128, jamespage: still just the three of us? :)
<kelemengabor> in general, the presence of such commented old strings should mean no problem, and LP keeps such in case they are reused sometime in the future. duplicates should not really happen, so this may be a toolchain bug
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, jamespage
<seb128> dholbach, no, just the 2 of you :p
<roadmr> kelemengabor: so in principle it would be OK to remove them?
<seb128> sorry I need to get some desktop stuff done ;-)
<dholbach> bah
<kelemengabor> roadmr: yes
<roadmr> kelemengabor: I notice this doesn't happen with the checkbox trunk, so I'll look at the differences between the branches more closely, but if all else fails I'll delete them with confidence
<roadmr> kelemengabor: thanks for your help!
<jamespage> dholbach, hrm - yes - I have been a little sidetracked this afternoon as well
<jamespage> managed to work through ~8 items this morning tho
<dholbach> nice :)
<slangasek> cjwatson: jhunt and I have a pty question for you :)
 * cjwatson holds up a copy of Stevens as a makeshift shield
<jhunt> cjwatson: looking at bug 922754, the question is whether we can
<jhunt> rework the while loop in log_read_watch().
<ubottu> Launchpad bug 922754 in upstart "booting without --no-log causes init and plymouth-upstart-bridge to spin at 100%" [High,Fix committed] https://launchpad.net/bugs/922754
<jhunt> If we only call this once a process has exited, even though the fd
<jhunt> is non-blocking, EAGAIN/EWOULDBLOCK shouldn't occur right?
<slangasek> cjwatson: my contention is that, if the process we care about has existed, and you receive EAGAIN on the pty, that's definitive that the fd was leaked and we should ignore it
<slangasek> because if there's anything in the kernel buffer, the kernel would return it immediately instead of returning EAGAIN
<cjwatson> hm, you may be right
<jhunt> and if so, we could use this to display a warning if debug is
<jhunt> enabled to state the app is not well-behaved or something.
<cjwatson> it's possible that I was simply knee-jerking on read in a while loop -> check for EAGAIN
<cjwatson> I think Steve's contention is correct
<slangasek> also, s/existed/exited/
<jhunt> thanks.
<jhunt>  
 * jhunt goes to watch the unit test firework display...
<hallyn> hi all - bug 930181 appears to be another libc fallout (this time due to its headers)?
<ubottu> Launchpad bug 930181 in qemu-kvm (Ubuntu) "qemu-kvm (1.0+noroms-0ubuntu4) fails to build on Ubuntu Precise locally" [High,Confirmed] https://launchpad.net/bugs/930181
<jhunt> slangasek, cjwatson: looks good so far - and yes, we can produce a
<jhunt> warning if a service such as openssh leaks an fd when the associated job
<jhunt> is stopped.
<slangasek> jhunt: yay :)
<didrocks> cjwatson: may I annoy you again for a priority bump on https://launchpad.net/~didrocks/+archive/ppa/+build/3202028 please?
<slangasek> hallyn: probably linked to the eglibc update, but header changes like that are rarely accidental or erroneous; are you sure this isn't either a regression in linux-libc-dev (i.e., the kernel side), or simply a bug in qemu-kvm's include usage?
<diwic> seb128, ping
<seb128> diwic, pong
<diwic> diwic, can you clarify that the decision to remove the login sound applied to the session-login sound (long jungle like sound) and not the system-ready sound (drums)?
<diwic> seb128 even
<seb128> diwic, I confirm that
<seb128> diwic, I think the system ready sound was just never implemented in lightdm by lack of time,other priorities
<diwic> seb128, thanks. So it seems like most people think we should have a system-ready sound but not a session-login sound
<seb128> I would tend to agree with that
<seb128> login sound is the annoying one
<diwic> seb128, that just leaves the live-CD without sound
<cjwatson> didrocks: sure, done
<didrocks> cjwatson: thanks again :)
<seb128> diwic, which is great ;-)
<diwic> seb128, ...unless you're blind
<seb128> diwic, well, we could turn on login sound on the liveCD easily
<seb128> and for a11y installs
<diwic> seb128, that could be something to consider at least
<ev> jdstrand: still reading through it, but thank you massively for such a comprehensive review of whoopsie.
<jdstrand> ev: you're welcome. I wanted to spend a good chunk of time on it which was hard to come by. sorry for the delay
<ev> no worries at all
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<hrw> side effect of updating eglibc - irssi session stopped resolving IPs. restart of irssi solved problem
<slangasek> hrw: new upstream versions of eglibc frequently cause nss ABI changes, yes; there's no good way to force a restart of arbitrary user processes that might be affected, but the "you must reboot to finish the upgrade" flag should have been set
<doko> slangasek, how is this set?
<slangasek> doko: /usr/share/update-notifier/notify-reboot-required - which I see that libc6 doesn't touch, after all
<slangasek> doko: so this would be a good thing to add, IMHO
<doko> ok, I'll add this for upgrades to 2.15
 * micahg also got warned about gdm on upgrade for glibc
<micahg> ah, I see why, I have it installed, but it wasn't running
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> micahg: warned> blah, yes, that needs improving then
<micahg> slangasek: want a bug?
<slangasek> micahg: yeah
<micahg> slangasek: bug 930304
<ubottu> Launchpad bug 930304 in eglibc (Ubuntu) "gdm is attempted to be reloaded even when not runnning" [Undecided,New] https://launchpad.net/bugs/930304
<quadrispro> micahg, here I am, still here
<quadrispro> micahg, whay were you saying about old glew transitions?
<quadrispro> s/whay/what/
<micahg> quadrispro: we never finished the glew 1.6 transition and as such currently have glew1.5 and glew (1.6) in precise
<quadrispro> yes, I understand
<quadrispro> micahg, so you mean it had better to defer this to precise+1?
<quadrispro> micahg, did you read my message?
<micahg> quadrispro: well, not necessarily, but I'd just suggest taking whichever one is more stable, also as seb128 mentioned unity is prone to issues with glew migrations
<micahg> and just keep in mind, there's more than just the glew rdepends
<quadrispro> ok, let's wait for feedback/suggestions from ubuntu-release
<seb128> cjwatson, still around?
<micahg> seb128: as I mentioned in -desktop, webkit is still broke on i386 (failed due to symbols changing) which means dist-upgrades on amd64 are broke still
<seb128> micahg, right, I'm doing another update and that's why I just pinged cjwatson
<seb128> I will need the i386 build to go to the right builder
<micahg> ah, ok, cool, thanks
<seb128> since some builders run out of ram calling ld
<seb128> he did it for me earlier but the build failed on a stupid .symbols cpp difference between archs
<seb128> - _ZN7WebCore12TextIterator29getLocationAndLengthFromRangeEPNS_7ElementEPKNS_5RangeERmS6_@Base 1.7.4
<seb128> + _ZN7WebCore12TextIterator29getLocationAndLengthFromRangeEPNS_7ElementEPKNS_5RangeERjS6_@Base 1.7.5-0ubuntu1
<seb128> stupid cpp mangling :-(
<micahg> ah, that's a per arch difference that existed already?
<seb128> well I reverted a (regex) use by error but there is a new symbol added which had the same issue
<seb128> I'm pondering just using -c1 instead of -c4 to be safe there, I don't want to fail another build
<seb128> will do that
<micahg> just don't forget to revert it for the next upstream release
<cjwatson> seb128: have you uploaded it yet?
<cjwatson> (dinnertime here, be quick :-) )
<seb128> cjwatson, no, I wanted to talk to you
<seb128> I've it ready, but I guess if I upload it will be too late to do your magic
<cjwatson> I can switch to manual first
<cjwatson> did you try the ld options I suggested?
<seb128> cjwatson, not yet, webkit builds take over 6 hours on my box
<cjwatson> ok
<cjwatson> seb128: upload away and tell me when you've done so
<seb128> but the build on the buildd would have worked
<seb128> ok, on my way
<seb128> cjwatson, uploaded
<cjwatson> seb128: ok, it should build when the current build on roseapple completes
<cjwatson> I have to go for dinner now, might be half an hour or so until I have time to re-auto the other buildds
<glenn> enjoy ur dinner :)
<glenn> im off too weekend
<glenn> ciao
<seb128> cjwatson, thanks a lot
<seb128> micahg, <micahg> just don't forget to revert it for the next upstream release
<hallyn> interesting - if i switch desktops at just the right time while 'debuild -S' is going, and gpg-agent is running, the pop-up asking my pwd apparently dies (without my seeing it) and debuild stops with bad passphrase
<seb128> micahg, I did revert and update the .symbols in the vcs, I just don't want to risk getting it wrong again today
<seb128> micahg, or we will keep the issue over the w.e
<micahg> seb128: sounds good, thanks :)
<seb128> yw
<bdmurray> Where / how do I submit a change to lptools?
<seb128> bdmurray, google says https://launchpad.net/lptools
<seb128> bdmurray, ?
<seb128> bdmurray, https://code.launchpad.net/~lptools/lptools/trunk
<seb128> bdmurray, same way that for any other launchpad vcs I guess?
<bdmurray> hmm debcheckout used something different
<bkerensa> slangasek: Do you know much about what was causing the "Waiting 60 more seconds for network configuration" bug?
<bdmurray> bkerensa: its a one time thing on first boot and is being looked at
<slangasek> that one should already be fixed in the dailies
<bkerensa> bdmurray: Hmm ok well it is hitting me everytime I boot in so not one time for me
<bkerensa> :D
 * slangasek sighs at bug #508083 having been marked "triaged", yet left assigned to the wrong package
<ubottu> Launchpad bug 508083 in eglibc (Ubuntu) "cron crashed with SIGSEGV in __pthread_initialize_minimal_internal()" [Medium,Triaged] https://launchpad.net/bugs/508083
<bdmurray> slangasek: which term log did you look at?
<slangasek> bdmurray: the one from jibel's autoupgrade test
<slangasek> bdmurray: can you think of a good way to suppress reports of that particular crash if it happens in the middle of a release upgrade?  Or should we just make sure cron is stopped before unpacking libc6?
<bdmurray> I'd think apport would report this as an apport-crash bug about cron so term.log wouldn't be available
 * slangasek nods
<slangasek> cjwatson: upgrade issue with libnih1 and libc6... libnih1 doesn't pre-depend on libc6, so the new libnih1 can be unpacked before the libc6 providing the symbols it requires... which will handily render init broken.  Should libnih1 pre-depend?
<bdmurray> slangasek: looking at the crash file there might be some information that gives it away as happening during an upgrade.  DistroRelease is 12.04 but the kernel is 3.0.0
 * lamont wonders what is STOMPING on resolv.conf with 127.0.0.1 for the nameserver
<micahg> resolvconf?
<lamont> possibly
<lamont> bind9's RESOLVCONF=no
<jdstrand> lamont: that would presumably be network manager's personal dnsmasq: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving
<cjwatson> slangasek: I think so, this is basically a case of (transitively-)Essential packages needing to promote Depends to Pre-Depends
<cjwatson> which is something I've agreed with Santiago in the past as being necessary
<slangasek> bdmurray: I don't think I'd like us to have to use kernel version and release version as a proxy for this, because that means we'd have to maintain that list in release-1 versions of apport
<slangasek> cjwatson: ok - think I should go ahead with that change then?
<lamont> jdstrand: bind9 has port 53 on the box.  it also doesn't want to be the resolver
<bdmurray> slangasek: oh I'd thought of using a bug pattern but yes it'd need to be updated per release
<cjwatson> slangasek: yeah
<slangasek> bdmurray: bug pattern only blocks once they try to submit, yes?  Since this is "not actually a bug", I'd rather that users never got prompted
<cjwatson> stopping cron during release upgrades sounds sensible ...
<bdmurray> slangasek: that is correct
<slangasek> bdmurray, cjwatson: right, I think stopping cron before unpack is probably the better way to go
<cjwatson> (during the whole thing?  cron jobs might well be using arbitrary stuff that will be unconfigured for sizeable amounts of the duration)
<jdstrand> lamont: aiui if you still have this in /etc/NetworkManager/NetworkManager.conf 'dns=dnsmasq', then resolvconf is in effect for dnsmasq via nm. you might want to comment out that option if you still have it
<jdstrand> not sure if you need to restart nm, presumably so
<lamont> jdstrand: ah ha!
<lamont> so what do I want to set it to?
<lamont> just comment, got it
<slangasek> cjwatson: oh, technically, we've managed to make it so that runlevel is not part of transitive essential on Ubuntu, so hmm
<jdstrand> lamont: comment it out: #dns=dnsmasq
<lamont> and # for comments.  that answers the other
<slangasek> can still do the pre-depends, but
<slangasek> I think apt would be happier if something essential pre-depended on upstart
<slangasek> (such as in the current debian-devel discussion)
<slangasek> might need to have the pre-depends on a transitional basis for upgrades regardless
<lamont> jdstrand: lrwxrwxrwx 1 root root 9 Feb 10 12:38 /usr/sbin/dnsmasq -> /bin/true
<jdstrand> lamont: if not rebooting you might need to kill off the dnsmasq and maybe other stuff
<lamont> nah, I fixed dnsmasq a while ago
<jdstrand> heheh
<cjwatson> slangasek: it's true that upstart isn't Essential, but I think that's kind of artificial
<slangasek> lamont: so there's a bug in that NM, if it fails to launch dnsmasq on port 53 for whatever reason, should not then call resolvcon
<slangasek> f
<cjwatson> it caused too many problems when we tried; but the point of using Pre-Depends is to enable the "works even when unconfigured" property of Essential packages, and I think that upstart should behave as if it were Essential
<lamont> slangasek: that saves me filing it
<slangasek> lamont: I didn't say there was a bug report, I don't know if there is ;)
<lamont> bah
<lamont> I shall check
<slangasek> lamont: I'm simply declaring that this is a bug, a conclusion that you seem to have already reached :-)
<slangasek> cjwatson: well, I believe that if something Essential had a pre-depends on upstart, apt's rules about immediate configuration would have made libnih1's dependency a non-issue
<slangasek> AIUI
<lamont> I also need to reboot for the lastest stuff, and see if unity 3d is still unusable for me
<cjwatson> I think it may only propagate that down one level
<cjwatson> and it doesn't seem like something we should rely on for individual package correctness anyway
<cjwatson> Incidentally, does unpacking the new libc break the old libnih?
<slangasek> cjwatson: but, er, consider that libc6's preinst is trying to invoke the runlevel command
<slangasek> which is not essential
<slangasek> and not in a pre-dep of libc6
<cjwatson> oh argh, I see
<slangasek> so "correct"ness may vary
<cjwatson> well, that means that runlevel must act as if it is essential, regardless of anything else
<cjwatson> so any libraries it depends on have to use Pre-Depends, strictly
<zanfur> sorry to intrude, just asking for directions -- where do I go for guidance in ubuntu packaging?
<slangasek> heh, yes, unpacking the new libc does break libnih as well
<slangasek> stupid GLIBC_PRIVATE
<slangasek> but probably breaks it less than the converse
<doko> hmm, I checked that the type of the used private symbol didn't change
<slangasek> doko: probably not between oneiric and precise... what about from lucid to precise?
<slangasek> well, it probably doesn't matter
<slangasek> the symbol is only used when libnih aborts ;)
<slangasek> so yes, unpacking libc6 first should be safe
<lamont> I suppose I'll see if I can get dnsmasq and bind9 to coexist nicely on my machine
<slangasek> lamont: does it matter? :)
<slangasek> lamont: you have bind9 on 127.0.0.1, and you don't want it to be used as your resolver.  To actually care about dnsmasq being used makes you a corner case on a 6-dimensional hypercube
<keyzs> unity is crap
<keyzs> all lefty
<keyzs> and for tv
<keyzs> now i dont love ubuntu
<keyzs> focus on user
<keyzs> not on code gurus
<tomreyn> hi, i'm looking at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule and am trying to understand when the freeze is for debian imported packages to go into the "precise" stable release. since this table lists various sates for various freezes for various releases i'm having a hard time coming up with a definitive answer.
<tomreyn> can one of you help me out?
<broder> tomreyn: there are a couple stages of how we handle imports. we've already stopped automatically importing packages from debian testing (that's DebianImportFreeze), so any subsequent imports have to be manually requested - but still can be
<broder> next week we hit FeatureFreeze, at which point imports either have to only fix bugs (not introduce features) or be approved by the release team
<tomreyn> broder: i see "LTS DebianimportFreeze", is precise an LTS?
<broder> yes
<tomreyn> okay i wasn't aware
<broder> we do LTS releases every 2 years in the spring (6.06, 8.04, 10.04, and now 12.04)
<tomreyn> oh right
<tomreyn> i remember there was some discussion that some release should have been LTS but wasn't in the end, but i forgot the details
<tomreyn> broder: so when's the point where even requests for bugfix only updates (debian imports) will be denied?
<tomreyn> is this UnseededUniverseFinalFreeze?
<broder> depends on the package. for packages included on any of our CDs, we stop taking any updates at FinalFreeze except for critical bugs
<broder> for packages in universe that aren't on CDs, yeah, UnseededUniverseFinalFreeze
<tomreyn> thanks for your help
<tomreyn> broder: actually i have another question related to this: so we released megaglest 3.6.0.3 (a bugfix) a few days ago, it's not in debian testing yet (but in sid, and should migrate to testing in 4 days). how do we request for it to be pulled into ubuntu for 12.04?
<broder> tomreyn: use the requestsync script in ubuntu-dev-tools (available in both debian and ubuntu)
<tomreyn> okay, are there limitations as to who can use it?
<tomreyn> well i'll rtfm
<broder> you just need a launchpad account
<tomreyn> cool
<bkerensa> slangasek: Do you know what "Source branch format does not support stacking, using format:
<bkerensa>   Branch format 7
<bkerensa> " means?
<broder> can i get an ~ubuntu-branches member to change the status of https://code.launchpad.net/~jtaylor/ubuntu/oneiric/subversion/sasl-crash-881862/+merge/85228 to merged?
<slangasek> bkerensa: the branch your branch is based from needs to have 'bzr upgrade' run
<bkerensa> slangasek: I'm assuming whomever maintains that package would be the one to do that?
<slangasek> bkerensa: what branch are you getting that error on?
<bkerensa> slangasek: ubuntu-wallpapers
<slangasek> bkerensa: what *branch*, not what package :)
<slangasek> http://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-wallpapers/ubuntu ?
<bkerensa> slangasek: https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-wallpapers/precise
<slangasek> ok, let's have a look-see
<bkerensa> I was proposing a merge to fix a bug
<bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/ubuntu-wallpapers/fix-for-296538/+register-merge
<slangasek> hmm
<slangasek> Standalone tree (format: 2a)
<slangasek> the target branch seems to have the right format
<bkerensa> yeah it was saying something about that when I merged
<slangasek> but maybe that's not the default stacking branch listed for the package
<bkerensa> hmm
<slangasek> yes, the associated upstream branch (lp:ubuntu-wallpapers) is an old format
<bkerensa> ahh
<slangasek> and I'm pretty sure that's a dead branch / team; I'll see about getting someone to upgrade the branch
<bkerensa> ok
<slangasek> bkerensa: were you able to successfully register the merge request, or did this issue block you?
<bkerensa> slangasek: My merge request is registered
<slangasek> ok
<bkerensa> I will big dholbach to review it tonight
<bkerensa> :D
<slangasek> then you can safely ignore the message ;)
<bkerensa> bug*
<bdmurray> slangasek: do you have an opinion about blocking package install failures from persistent live media?
<slangasek> bdmurray: I don't think so - how about if I adopt your opinion, whatever it is? :)
<bryceh> bdmurray, sounds like a good idea to me
<bdmurray> bryceh: right you worked on some weird issues in previous releases right?
<bdmurray> I just can't decide if we are just hiding other issues though
<bryceh> bdmurray, yeah related to nvidia driver installation failures
<bryceh> that class of issue tended to hit things that required updating the boot loader when installing them
<bryceh> I've not seen any similar issues lately the past two releases, so would guess the root problem got solved, but I don't actually know.
<bdmurray> I believe that was fixed in casper
<bryceh> bdmurray, do you see a lot of reports about persistent live media package install failures?
<bdmurray> bryceh: that would be a good thing to know but its hard to find out
<bdmurray> bryceh: you might need to check the dmesg attachment, I'm not certain the description has enough information
#ubuntu-devel 2012-02-11
<bdmurray> bryceh: hmm, not too many it looks like
<broder> slangasek: looks like there are a handful of packages that have popped up on <http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html>. any chance i can pawn those off on you to follow up on?
<broder> anybody on ~ubuntu-branches around? looks like https://code.launchpad.net/~evfool/ubuntu/oneiric/brasero/fixlp848340/+merge/85782 should be marked as merged (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/brasero/oneiric-proposed/revision/91)
<AlanBell> hi all, anyone know who is involved in the new sound theme project?
<cjwatson> broder: dpkg-maintscript-helper> fair number of false positives in there since it doesn't understand things being guarded with 'supports' checks
<cjwatson> though arguably it's better to just pre-dep these days
<cjwatson> broder: marked that MP as merged, thanks
<rhorstkoetter> hi. I hope this an appropriate channel for my question ;) I'm wondering how to use casper-rw persistent overlay ext2/3/4 partition for live-usb with the new hybrid iso that ships with oneiric+X
<rhorstkoetter> so far, we used f32 and ext2/3/4 partition labeled casper-rw with syslinux as a workaround
<rhorstkoetter> problem is that the hybrid iso dumped to usb doesn't actually recognize the casper-rw ext2/3/4 partition appended to the end of the stick
<rhorstkoetter> is there any conf option I'm missing, i.e telling grub to actually use that partition as an overlay?
<rhorstkoetter> thanks in advance for your help
<rhorstkoetter> sidemark: I actually tried asking in #ubuntu but they doesn't seem to understand my actual problem, thus I decided to ask here. I hope this is sufficient
<kklimonda> rhorstkoetter: does hybrid iso actually have a partition table? I was wondering that myself lately
<rhorstkoetter> kklimonda: um, I'm actually not sure
<rhorstkoetter> good question )
<rhorstkoetter> ;)
<rhorstkoetter> I know though that something similar is possible with the opensuse hybrid isos, where the ubuntu tech is (most likely) adopted from
<rhorstkoetter> but suse even does the persistence step automatically on first boot
<kklimonda> yeah, that's what I've done myself before hybrid image
<rhorstkoetter> I actually never had any issues with the f32 plus casper-rw approach/syslinux workaround, but you may have hit the nail .. the partition table
<kklimonda> I have a small initrd script that creates additional partitions and mount them
<kklimonda> (but it obviously depends on an existing partition table)
<kklimonda> I'd be interested how to do that with the new hybrid image myself
<rhorstkoetter> kklimonda: we're two then
<rhorstkoetter> I think I'll ask some people I know at suse and if they know what to do, maybe a feature request would help?
<rhorstkoetter> i.e. to adopt the rest of the suse automatism?
<rhorstkoetter> btw, before the hybrid iso, I mean with ubuntu, there isn't even a initrd script needed
<rhorstkoetter> you just need to create the live usb, add a second partition labeled casper-rw (ext2/3/4 formatted), plug in and you're set
<rhorstkoetter> kklimonda: not sure though if I misunderstand something about your initrd approach
<kklimonda> yes, but I don't want make users create partitions themselves
<rhorstkoetter> kklimonda: oh man, you just put in one sentence why I like ubuntu that much more compared to suse. they understand user-convenience
<rhorstkoetter> i.e. they know what that actually means ;)
<rhorstkoetter> anyway, this is another topic
<kklimonda> it's a great question, and it would be a good idea to check how SUSE does that
<kklimonda> I'd come back this monday when more of the foundation developers are here and talk with them about it
<rhorstkoetter> they're usually here all weekdays?
<rhorstkoetter> it may be difficult to get an answer over the weekend. but I can certainly contact some people to find out and then get back to you guys
<kklimonda> yes, most (if not all) of them work for Canonical
<rhorstkoetter> great
<kklimonda> so they are here during the week, and don't work on weekends :)
<rhorstkoetter> I'll get back once I know better
<rhorstkoetter> sure, I understand
<rhorstkoetter> well deserved spare time (as is with suse devs)
<rhorstkoetter> ok, thx so far. see you
<rhorstkoetter> have a good weekend
<jbicha> webkit i386 build ran out of memory again :(
<tumbleweed> some of the i386 builders have more ram than others
<Ampelbein> Wasn't webkit supposed to build on a more powerful builder?
<Ampelbein> Oh, it did but failed due to -c1 instead of -c0.
<tumbleweed> we have a way of pointing apckages at buildds?
<Ampelbein> Yeah, I guess a buildd admin just sets the other buildds to manual
<tumbleweed> oh, that way :P
<stgraber> tumbleweed, jbicha: so does the new webkit (-ubuntu3) need some magic to use the right builder for i386?
 * stgraber prepares to do buildd magic if that's the case
<tumbleweed> stgraber: dunno, I don't know the webkit package
<tumbleweed> but I have had trouble with an i386 bulider not having as much memory as I'd like, before
<stgraber> k, I'll force it to build on roseapple and see if that helps
<jbicha> stgraber: thanks
<Ampelbein> stgraber: roseapple should help, see the -ubuntu2 build.
<Ampelbein> That one failed only due to symbols mismatch.
<stgraber> ok, roseapple is the only buildd still in auto mode and I bumped the score of webkit, so whenever roseapple is done with the current build, it should start building on it
<stgraber> building now
<stgraber> and moved the rest back to auto mode, hopefully that'll work
<ingwa> hello
<ingwa> I searched for a unity channel but found none.  Is this the right place for unity questions?
<jussi> ingwa: for normal tech support type questions, I would say #ubuntu
<jussi> ingwa: what sort of question do you have?
<ingwa> I have a general question: are applicaitons for unity going to be developed with a certain look&feel?  Perhaps using a certain toolkit?
<jussi> ingwa: ahh, I would say #ubuntu-unity for that
<ingwa> jussi: that sounds like a good tip.
<jussi> :)
<ingwa> But it would be even better if it could be found on https://wiki.ubuntu.com/IRC/ChannelList :)
<ingwa> jussi: that channel seems well populated so thanks
<jussi> ingwa: Ill zap them to update that - its a fairly new channel replacing #ayatana
<ingwa> jussi: excellent
<ingwa> and thanks again
<jussi> yw
<AlanBell> #ubuntu-unity is now in the list
<broder> cjwatson: a supports guard isn't actually sufficient, is it? it prevents the maintainer script from erroring out, but doesn't actually handle the conffile mv/rm/etc, no?
<cjwatson> broder: yeah, that's what I thought after my initial comment
<cjwatson> broder: I've changed a few packages already on the grounds that a pre-dep creates more reliable behaviour
<cjwatson> pretty sure pcmciautils had a latent upgrade bug due to this, since update-rc.d would've failed if the old conffile hadn't been removed, for instance
<broder> cjwatson: https://code.launchpad.net/~l3on/ubuntu/oneiric/gdevilspie/fix-for-783568/+merge/89718 should also be marked as merged, if you've got a sec
<cjwatson> broder: done
<broder> thanks
<Pjotr> Hello, I have a question about a Ubiquity bug that I reported on Launchpad:
<Pjotr> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/930676
<ubottu> Ubuntu bug 930676 in ubiquity (Ubuntu) "Ubiquity quits when starting migration-assistent" [Undecided,New]
<Pjotr> My question is: should I file a bug report against migration-assistant as well?
<Pjotr> @cjwatson: maybe you know?
<udevbot> Error: "cjwatson:" is not a valid command.
<Pjotr> cjwatson: maybe you know?
<Pjotr> ev: if I'm correct, you're the maintainer of migration-assistant. Should I file this Ubiquity bug, against migration-assistant as well?
<Pjotr> Well, I suppose a separate bug report against migration-assistant is best. So I just filed it:
<Pjotr> https://bugs.launchpad.net/ubuntu/+source/migration-assistant/+bug/930754
<ubottu> Error: Could not gather data from Ubuntu for bug #930754 (https://launchpad.net/bugs/930754). The error has been logged
<Pjotr> https://bugs.launchpad.net/ubuntu/+source/migration-assistant/+bug/930754
<haled> how do I get HUD running in 12.04 alpha?
<lamont> do we think webkit is going to successfully build on zirconium?
<stgraber> lamont: I moved it to roseapple earlier but the build was killed and the builder disabled for some reason
<stgraber> lamont: we need a builder with a lot of RAM for it to build (AFAIK, I'm not webkit expert)
<stgraber> lamont: so if the current builder doesn't have plenty of RAM, we should kill the build and move it back to another builder like roseapple
<elmo> umm
<elmo> guys
<elmo> requiring > 3Gb to link isn't reasonable or sane
<elmo> and is either a webkit or binutils regression
<elmo> moving this package around buildds is not a sane long term strategy
<elmo> and eventually you're going to run into limits you simply can't get round - this is 32-bit after all
<stgraber> elmo: as I said, no webkit expert here, I just want to be able to install an amd64 system ;)
<stgraber> elmo: I definitely agree that requiring >3Gb to link is insane ;)
<lamont> stgraber: who's owning fixing it to not need >3GB to link?
<stgraber> lamont: desktop team I guess?
<stgraber> well, ultimately upstream I'd think but desktop team should be responsible of nagging them to do so ;)
<cjwatson> elmo: we know
<cjwatson> elmo: but it's breaking all amd64 image builds so we're trying short-term as well as long-term solutions
<lamont> restarting/ed on roseapple.  This should be fixed before it's uploaded again
<stgraber> lamont: thanks
<cjwatson> I already suggested a couple of ld options to seb128 that might help
<lamont> cjwatson: do you have a name for me to point people at if someone uploads ubuntu4 without it fixed?
<cjwatson> but it takes six hours for him to build it locally so it does take a while to fix this kind of stuff
<cjwatson> lamont: seb128 was the last person I was aware of who was working on it
<lamont> I'll go with that then
<cjwatson> how actively that was, I don't know
<lamont> I'll poke him on monday
 * lamont files the bug against webkit, just for completeness
<lamont> bug 930805
<ubottu> Launchpad bug 930805 in webkit (Ubuntu) "FTBFS: i386 build requires more virtual memory than 32-bit kernels provide" [Undecided,New] https://launchpad.net/bugs/930805
<lamont> and marked critical
<lamont> stgraber: cjwatson: any time we decide to jockey a build to a particular builder, there needs to be a bug filed, since there clearly is one somehow (or an RT if it's truly something that needs to be fixed on the builder, in which case the builder should be disabled)
<lamont> I wonder... is this going to break my upgrade to precise that I'm doing now?
<cjwatson> agreed
<cjwatson> quite possibly, if you're on amd64
<lamont> fact
<lamont> too late to stop now, though
<cjwatson> which is why we've been trying to fix this for two or three days now ...
<lamont> I wish I had a "go faster" button on roseapple that I could push
<cjwatson> we know it got past the link on roseapple before, but then ran into a later failure
<cjwatson> so it should manage it again if only it keeps building
<lamont> roseapple is the only 64-bit kernel i386 builder
<lamont> ah, so ubuntu3 is the fix for the later failur?
<cjwatson> lamont: yes
<lamont> well, as long as precise works with webkit 1.4.3... this does not fill me with hope.
#ubuntu-devel 2012-02-12
<hzsp> hi.  I need some help building gnome-settings-daemon (first time I've tried to build an ubuntu package from source).  first off, am I in the right channel? :)
<cyphermox> hzsp yes, or #ubuntu-desktop
<cyphermox> cjwatson: if you share ld options for testing i may be able to kick off a few test builds locally here , then poke seb with  results
<cjwatson> cyphermox: 14:12 <cjwatson> seb128: try ld --no-keep-memory
<cjwatson> cyphermox: 14:13 <cjwatson> seb128: possibly --reduce-memory-overheads too
<cyphermox> i realize it would probably take just as long to build for me though
<hzsp> ok.  so I'm getting this error when trying to make: http://pastebin.com/d3WPkTAJ
<cyphermox> cjwatson: thx
<cyphermox> building something will be a nice change from the blistering cold though. :)
<cyphermox> hzsp: its not linking properly against libnotify. how are you building it?
<hzsp> I got the source with apt-get source and build-dep, then I tried to run ./configure && make, but I ran into some issues which I think I've overcome
<stgraber> cyphermox: it's not that cold ;) though you can probably save a bit on heating and instead spend it on electricty for your build farm ;)
<hzsp> make was initially telling me 'libtool: Version mismatch error'.  I ran autoreconf -i and that problem's gone away.
<cjwatson> any reason you aren't using the package build rules?
<cyphermox> stgraber: im at the Quebec carnival, spent most of  the day outside
<hzsp> cjwatson: can you explain
<cjwatson> there's a uniform way to build packages, which normally involves calling debian/rules to do configuration and compilation, not typing the commands by hand
<stgraber> cyphermox: oh yeah, I only spent an hour or so outside today, wouldn't like to spend the whole day out, the -13C quickly becomes annoying ;)
<cjwatson> simplest way to invoke it is 'debuild -b'
<cjwatson> (requires devscripts to be installed)
<hzsp> cjwatson: I see.  I was reading the INSTALL file which told me to do a configure && make
<cjwatson> those are the upstream directions
<cjwatson> but if you're trying to duplicate the package you should use the packaging tools
<hzsp> I'll try that, ta
 * cjwatson double-checks whether gnome-settings-daemon builds in current precise
<cyphermox> most likely
<hzsp> I'll nuke the source tree and install it again just to be safe
<cyphermox> stgraber, we were dressed for the north pole
<hzsp> is debuild -b going to do a make install as well?  is it likely to install into /usr/local?
<cyphermox> hzsp: no
<stgraber> cyphermox: hehe, good ;)
<cyphermox> it Will give you .debs to installer
<cjwatson> hzsp: it's incapable of installing into /usr/local, unless you run it as root (which you shouldn't!)
<cjwatson> hzsp: it does a make install or the equivalent, but into a temporary tree
<cjwatson> which is part of the process of building packags
<cjwatson> *packages
<hzsp> cjwatson: ok, thanks
<cjwatson> hzsp: I can confirm that gnome-settings-daemon builds from source in precise using the packaging rules
<cjwatson> haven't checked other releases
<hzsp> cool.  I'm building on (and for) precise.
<hzsp> it got as far as clearsign failed: secret key not available  debsign: gpg error occurred
<hzsp> but it did build binaries ok
<cjwatson> sure, that can be ignored
<cjwatson> 'debuild -b -uc -us' if you want to bother suppressing that
<cjwatson> the build output should show exactly how it invoked configure and make if you want to then do stuff by hand
<hzsp> my next task is to figure out how to kill the default gnome-settings-daemon without it restarting itself :-P
<cjwatson> can't help you there :)
<hzsp> no, but google can ;)  anyway, thanks for your help!
<apachelogger> do we have a page listing release critical bugs somewhere?
<tumbleweed> apachelogger: not that I know of, we probably should
<apachelogger> oh, actually I should clearify ... a page that particularly also tracks progress throughout the cycle ^^
<apachelogger> I guess one can filter the interesting bugs via launchpad ui directly
<tumbleweed> we have those kind of things for some core packages on qa.ubuntu.com
<tumbleweed> http://iso.qa.ubuntu.com/qapkgstatus
<apachelogger> tumbleweed: that doesn't seem to take milestoning into account, does it?
<cjwatson> there's stuff like http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html, on the occasions when it isn't broken
<cjwatson> (to be fair it is more or less up to date at the moment)
<tumbleweed> apachelogger: no
<apachelogger> kk
<apachelogger> cjwatson: hm, I am getting process confused now ... wasn't at one point the workflow to milestone bugs before release and only nominate after?
<cjwatson> apachelogger: at least for some years the distinction has been that developers can milestone whatever they like to organise their own work, but if we want things to be release-critical then they have to be targeted as well
<cjwatson> (the page above is actually only for bugs with a certain tag though - yay for more levels of abstraction, I guess)
<broder> ubuntu-branches members - i've spotted 2 more in the sponsors queue that should be adjusted
<broder> https://code.launchpad.net/~pali/ubuntu/oneiric/pulseaudio/pulseaudio/+merge/67286 should be work in progress - there's a newer MP that should be in the queue
<broder> https://code.launchpad.net/~l3on/ubuntu/natty/gdevilspie/fix-for-783568/+merge/89717 should be merged - it's in UNAPPROVED
<apachelogger> cjwatson: makes you wonder how one is supposed to explain all that to regular folks :P
<cjwatson> aye
<cjwatson> https://wiki.ubuntu.com/RCBugTargetting makes a valiant attempt but is (of course) out of date
<cjwatson> that said I do actually look at traditional (non-rls-mgr-p-tracking-tagged) targeted+milestoned bug lists from time to time
<cjwatson> so that page isn't all that bad a start
 * cjwatson gets bored of walking down http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html and goes to bed
<lamont> interesting that dist-upgrade wants to remove ubuntu-desktop
<stgraber> lamont: yep, that's caused by webkit
<lamont> gwibber in this case
<lamont> interestingly, do-release-upgrade -d from oneiric finished
<stgraber> lamont: a bunch of important packages (apturl, software-center, gwibber, ...) all depend on some webkit stuff that in turn depends on the yet to be built arch all packages
<lamont> I'm just wondering if it's safe to reboot
<stgraber> if the only non-upgraded stuff is: gir1.2-javascriptcoregtk-3.0 gir1.2-webkit-3.0 gnome-control-center-data gwibber libjavascriptcoregtk-1.0-0 libjavascriptcoregtk-3.0-0 libwebkitgtk-1.0-0 libwebkitgtk-3.0-0
<stgraber> then that's what I have on my laptop at the moment and it works fine
<stgraber> (to start fullscreen terminals at least)
<lamont> The following packages have been kept back:
<lamont>   gir1.2-webkit-3.0 libwebkitgtk-1.0-0 libwebkitgtk-3.0-0
<lamont> I guess it's time to file a bug about 3.2.0 hating my video card
<micahg> jamespage: hi, just wanted to check with you if I missed anything, I would like to sync the latest javatools as it has bug fixes and is needed as a build dep for a new geogebra, seems sane and builds
<ScottK> Isn't the motto JFDI?
<micahg> yes, but I'd prefer not to break a bunch of java rdeps
<broder>  anybody here use nomachine? i'm trying to figure out a fix for bug #682338 that's slightly less hideous than https://launchpadlibrarian.net/89032862/nx_cairo_1.10.2-6ubuntu3.patch
<ubottu> Launchpad bug 682338 in cairo (Ubuntu Precise) "GTK programs in Ubuntu 10.10 are sluggish over NX" [Low,Triaged] https://launchpad.net/bugs/682338
<broder> in particular, i'm wondering what xdpyinfo on a nx connection looks like
<truongan> hi all
<truongan> i've used Ubuntu for 3 years. i want to become a developer. do you have any project for me?. my prefered language is C
<ion> Pick any of them.
<eQuiNoX__> hmm other than the highlighted CVE's here => https://wiki.ubuntu.com/MeetingLogs/Security/20120206 ; is there anyplace where all cve's that require traige/fixes are listed in the wiki?
<eQuiNoX__> something ive missed? :/
<jamespage> micahg, go for it
<micahg> jamespage: thanks
<ome> Where can I add/read the APT feature requests ?
<jtaylor> doko__: numpy 1.6 merge proposal https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/merge-1.6/+merge/92671
<stgraber> would be great if someone could BIN-new libindicate on i386, this would let gwibber build and allow for it to be upgradable on amd64
<micahg> it would also let another handful or so of rdeps build
<lifeless> RAOF: do you want any diagnostics - 2362 robertc   20   0  883m 374m  13m S    0  4.8   4:22.54 nm-applet
<lifeless> RAOF: (yes, thats nearly 400M resident for 'you can has network GUI')
<RAOF> lifeless: Are you sure you weren't after Sweetshark? :)
<lifeless> RAOF: oh oh a pointer to chase? :)
<RAOF> lifeless: Only for problems with his XI 2.2 backport :)
<lifeless> RAOF: XI ?
<RAOF> But I don't touch NetworkManager *at all*
<lifeless> RAOF: yeah, but you are -desktop and -mytimezone ;)
<RAOF> X Input; the upstream multitouch protocol.
<RAOF> Heh.
<RAOF> IIRC ubuntu-bug will pick up all the memory mappings nm-applet has; I guess the start might be filing a bug? :)
<RAOF> Hurray heisenbug!  Attaching gdb prevents the crash.
<lifeless> RAOF: bug 931167 :)
<ubottu> Launchpad bug 931167 in network-manager-applet (Ubuntu) "NM-applet using crazy memory" [Undecided,New] https://launchpad.net/bugs/931167
<lamont> should libreoffice work tonight, I wonder?
<ScottK> Heh.  I ask myself that every day, even post-release.
<lamont> well, it seems to try to start and then *poof*: nothing
#ubuntu-devel 2013-02-04
<pitti> Good morning
<pitti> bdmurray: darn, it got its core dump removed already; but I'll look for a few apport-failed-retrace armhf bugs
<pitti> infinity: I don't think that putting upstream changelogs into any .deb is making good use of storage space and download bandwidth; but for -doc packages I'm okay with letting them back in
<infinity> pitti: Well, in the case of glibc-doc, the upstream changelogs are intentionally included as part of documenting the package.
<infinity> pitti: I don't feel particularly strongly about it, mind you.
<infinity> pitti: (I only noticed because of a lintian warning in Debian about the upstream changelog having a non-conforming name, and then noticed we don't ship it at all in Ubuntu) :P
<dholbach> good morning
<ion> that
<ogra> wow, seems Laney had a busy weekend
<Laney> heh
<Laney> scripts are powerful things :P
<ogra> W:Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/raring/main/source/Sources  406  Not Acceptable
<ogra> *sigh*
<ogra> why the heck do i randomly see 406 errors since last week
<ogra> oh
<ogra> http://de.archive.ubuntu.com/ubuntu/dists/raring/main/source/Sources actually tells me there is no uncompressed file named "Sources", there are .gz and .bz2 variants though ... do we have an apt bug ?
<cjwatson> Always been that way
<ogra> hmm, why does apt try to download the uncompressed file then
<cjwatson> I think the URL in the error is just misleading
<cjwatson> strace or tcpdump or whatever if you want to see what it's actually doing
<ogra> well, the url actually gives me an apache error page
<ogra> "Not Acceptable"
<cjwatson> Sure, but I doubt that's the URL it actually got the root-cause error from
<ogra> pointing out that there are gz and bz2 files of this file available
<cjwatson> Like I say, get a proper trace rather than relying on that error message
<cjwatson> Because it was probably a knock-on error from something else
<cjwatson> (Yes, it might have got some other error, tried to fall back to the uncompressed variant, and then got 406 - but that just means the 406 is hiding some real error behind it)
<ogra> ok, server side i can at least grab the gz and bz2 files manually so yeah, your theory sounds right
 * ogra wonders why his 12.04 desktop feels so much more buggy than raring in so many areas 
<ogra> (screen locking doesnt work properly, update-manager is undiscoverable once it auto-started and sits in your launcher (you can click it doesnt come up) ... and now since mid last week this apt issue))
<ogra> oh, and we should consider ripping the weather indicator out of precise if nobody fixes it
<Laney> it's had several SRUs
<sladen> ogra: then people would just go back to using windows
<ogra> Laney, none that fixed anything (at least for me)
<ogra> it reliably crashes after about a day
<ogra> stat("/var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_raring_main_source_Sources", {st_mode=S_IFREG|0644, st_size=4104933, ...}) = 0
<ogra> write(1, "\r                               "..., 214) = 214
<ogra> write(16, "600 URI Acquire\nURI: http://de.a"..., 546) = 546
<ogra> hmpf
<ogra> is there any way to see the full URL here in strace ?
<ion> -s10000
<ogra> hmm, intresting, with that it hangs with "Waiting for headers" at some point at the end
<ogra> ah, there we go ... it hung for nearly 2min
 * cjwatson scratches his head
<cjwatson> jdstrand: Do you know how chromium-browser got from raring-proposed to raring?  The proposed-migration logs don't mention it anywhere, and it seems to have been done slightly incorrectly (i.e. left in -proposed)
<cjwatson> And +publishinghistory doesn't say who copied it, which is weird
<Laney> Does it usually? I thought that it only shows the user for deletes
<Laney> From: in -changes is the copier AFAIK
<cjwatson> Laney: I fixed +publishinghistory to show the copying user back in August
<cjwatson> But yes, raring-changes shows it copied manually by jdstrand
<cjwatson> jdstrand: Please don't ever do this
<cjwatson> If you find you need to, (a) you're probably hiding a problem somewhere else, (b) there are other ways to do it (britney hints)
<cjwatson> (I suspect perhaps my +publishinghistory fix only shows the copier when the publication record was copied from another distribution)
<Laney> The one I was looking at was an SRU, so that would match
<cjwatson> jdstrand: Did you check update_excuses before doing the copy?
<cjwatson> Unfortunately we don't log that so I can't retroactively check what might now be uninstallable as a result of the copy
<zequence> Hi, I'd like a bit of help regarding a SRU. bug 956438. I've got a branch of jackd2 whcih fixes a bug in quantal and precise, which I would like to get uploaded to proposed. I've followed all the procedures from what I can see.
<ubottu> bug 956438 in jackd2 (Ubuntu Quantal) "qjackctl unable to stop jackd2" [Undecided,New] https://launchpad.net/bugs/956438
<zequence> I've got testing packages (still building) at ppa:zequence/sru
<zequence> My branch is this lp:~zequence/ubuntu/raring/jackd2/fix-for-956438
<zequence> ah, I see ScottK was doing some work on the bug
<jdstrand> cjwatson: hi
<jdstrand> cjwatson: I did do the copy, yes. chromium-browser was rather horribly out of date on raring and while the armhf patches are being worked on, I decided that it was more important for our i386 and amd64 users to have the security update, and then to have the armhf fix uploaded soon
<cjwatson> jdstrand: If you're going to do such things, please do them by the medium of britney hints, not by manual copies to the development release
<cjwatson> Ah, you're not in ~ubuntu-release, so you'll need to get a member of that team to do it
<jdstrand> cjwatson: I was unware of britney hints, and I don't see it documented in ArchiveAdministration. can you point me to how to do this?
<cjwatson> jdstrand: Archive admins technically still can copy to raring, but must not
<cjwatson> jdstrand: you'll have to get one of the release team to do it, but plenty of us are around at all kinds of strange hours ...
<jdstrand> I don't plan on doing this regularly or anything-- I didn't know it was a horrible no no. I knew armhf was broken, and I figured we'd got an out of date for it , which would be fixed soon. I figured the security update for rariing was more important than that line item
<jdstrand> I'm sorry if it caused a problem
<cjwatson> It's bad because we have no way to track what it broke
<cjwatson> With britney hints, you can override specific things ("OK, I understand that excuses says that this is wrong, but try the update anyway") and still have checks for other things
<cjwatson> And it gives us a record in bzr of what's been done manually
<cjwatson> In general since we have this mechanism available we shouldn't bypass it
<jdstrand> cjwatson: can you add something to ArchiveAdminstration stating something appropriate for archive admins? I would, but probably wouldn't be able to convey what you would want me to
<cjwatson> Well - this kind of copy isn't documented at all in ArchiveAdministration right now
<cjwatson> So it's hard to find something to attach it to
<jdstrand> I was thinking conceptually it wasn't any different than copying from -proposed to -updates
<cjwatson> That isn't owned by a mechanism
<cjwatson> So it's quite different
<jdstrand> I'm not saying I was right, just that it seemed the same
<jdstrand> or rather, similar
<jdstrand> hey, my wrist was slapped (sorry) and I won't do it again. I'm just saying I didn't know I should not and that documenting it might help someone in the future
<jdstrand> (well, I knew I shouldn't generally, but I didn't know that an aa wasn't allowed to do what I did in exceptional cases)
<cjwatson> jdstrand: How about https://wiki.ubuntu.com/ArchiveAdministration#Other_copies ?
<jdstrand> cjwatson: I think that works very well. thanks
<cjwatson> Thanks - I was mostly surprised because I thought I had disseminated this information, but it's possible I only did so by IRC, which wouldn't be atypical for me :-)
 * ogra sets up a mail redirect for all the ARM whiners to jdstrand's inbox
<jdstrand> ogra: they are no worse off than before. the patches are actively be worked on :)
 * jdstrand redirects the redirect to chromium devs
<ogra> well, curerent chromium trashes all my arm desktops anyway (likely due to an incompatible cairo it ships)
<ogra> cant be worse ... but we have a lot of people complaining since a while
<jdstrand> ogra: if he doesn't already know, you might let chad know about that
<ogra> jdstrand, well, what we have is horridly outdated anyway  and only broken like this in raring atm (wehich will soon get updated)
<jdstrand> right, so hopefully once the new one is working, maybe it'll be fixed
<ogra> if it still shows after the update i'll talk to him
<jdstrand> fair enough. fyi, chad from the desktop team is your man
<jdstrand> cool
<ogra> (you can easily try on a nexus7 btw, after a while all fonts get corrupted)
<test___> a dev told me to ping him on IRC because of a bug (he gave me his username and said on freenode. Please forgive me the stupid question but how to ping someone, if i do not know the channel?
<mjt> test___: /msg somewhere sometest
<mjt> someONE not someWHERE ofcourse
<test___> mjt ist it possible to do this with http://webchat.freenode.net/
<mjt> oh no idea.
<mjt> i never used webchat
<test___> what client to use on ubuntu?
<ogra> test___,  you usually just type: <nickname> ping
<mjt> if he's in the channel
<ogra> directly messaging someone without asking first is usually considered kind of rude
<mjt> yesterdays talk is more or less an agreement in this case
<test___> orga, he asked me to do so ...  i do not know the channel, just the username and freenode
<ogra> he said to ping him
<ogra> and if he is an ubuntu dev he is most likely around here
<infinity> ogra: I'm not sure which culture that "ask me in public if you can ask me in private" thing came from, but some of us find it irritating. :P
<infinity> ogra: It's like asking if you can ask a question.  You've just wasted my time with something completely devoid of content.
<infinity> (Now, public *questions* are better than private, cause someone else might jump in and answer, but if I ask someone to poke me, I actually prefer a direct query, easier to track)
<ogra> infinity, well, i tend to ignore unasked pings (especially if the content just says "ping" without any question)
<infinity> ogra: I only get completely contentless pings from people I work with.  *cough*
<infinity> ogra: Community people are, on the whole, much better about braindumping at me in query windows.
<ogra> heh
<test___> okay i installed xchat and user "/msg someone test , but how can i be sure this user exists?
<ogra> lucky you
<infinity> test___: It should whine at you if you tried to send a /msg to no one.
<cjwatson> Yeah, in particular the "ask me in public if you can ask me in private" thing often enough causes me to have to catch up on scrollback in some window just to find out that it lit up due to somebody who could just have queried me directly
<cjwatson> (OK, this is a slight artifact of the way I read IRC, but still)
<test___> it does not, i tried many random names, which cannot exist all for sure
<infinity> cjwatson: I suspect you and I IRC very similarly. :P
<ogra> test___, check the server tab in xchat
<ogra> server error messages usually show up there
<infinity> ogra: I don't use xchat, but I assume it would have opened a query tab with the user he was /msging, if it had worked, no?
<ogra> yes
<ogra> but it wont print errors in there
<infinity> No, but you'd also have no tab.
<infinity> Which is, itself, an indication of an error. :P
<ogra> err, /msg doesnt open a tab anyway
<ogra> i think thats /query
<ogra>  /query ogra12345 foo
<ogra> that properly opens an empty tab here
<ogra> and the server tab has:
<ogra> * ogra12345 :No such nick/channel
<infinity> That's... Rather unintuitive.
<ogra> thats how xchat handles it
<ogra> server msgs go to the server tab
<ogra> (i agree though)
<infinity> If I chant "abra-cadabra, make me a shawarma", and lack magical skills to actually make sandwiches happen, I don't expect an empty wrapper to appear.
<infinity> I want a sandwich, or nothing. :P
<infinity> ogra: No, no.  The error going to the server tab is fine, it's the query tab being spawned with no query that's unintuitive, IMO.
<ogra> but now you obnly need the sandwich, not the wrapooer anymore :P
<ogra> in case you want to take your sandwich with you in the bus
<davmor2> ogra: do you get drawing issues with onboard?  for example if I hit the shift button the top of the arrow disappears leaving me with a squared u.
<ogra> davmor2, rarely but yes
<ogra> lets see how maliit behaves in that regard, it should have entered the archive by now i guess
 * ogra didnt check
<ogra> its on my plan this week to test maliit integration
<scott-work> infinity: do you have a minute to talk about a possible SRU? i wanted some advice before preceeding
<infinity> scott-work: Sure, shoot.
<davmor2> ogra: also I get really inconsistent keyboard popup on dash home.  First time seems fine but any time after that seems to be a 50-50 chance on it opening.
<scott-work> after 12.04 we (ubuntu studio) added a few new metas for publishing and photography. these aren't being picked up during 12.04 -> 12.10 upgrade. we have an idea on fixing this but wasn't sure it was the "proper" way to handle this
<scott-work> infinity: oops ^^^
<ogra> davmor2, yeah, thats supposed to be fixed in upstream onboard already
<scott-work> infinity: our thought was to update the -desktop meta and explicitly include these two metas, but it seemed a little hacky
<davmor2> ogra: nice, btw if there is anything you need testing confirming I got my nexus 7 just to play with ubuntu on so feel free to ping me
<infinity> scott-work: Well, if you want people to be able to have desktop installed, but remove the other metas, that's not a good solution.
<infinity> scott-work: Are they meant to be there on a "default install", but readily removable?
<ogra> davmor2, i just uploaded a fix for the sound issue, see if you have sound on boot (still muted, but should work without suspend cycle)
<infinity> scott-work: If so, you probably want to quirk the release-upgrader to add them on upgrades.
<scott-work> infinity: if possible, that would be prefered
<scott-work> infinity: is there any information on how to do this that i can read or an example already being used?
<davmor2> ogra: are you using proposed for this other wise I don't have it yet
<infinity> scott-work: It might be as simple as adding those packages to PostUpgradeInstall in the [ubuntustudio-desktop] section of data/DistUpgrade.cfg
<scott-work> infinity: super cool. i'll dig into that. thank you very much :)
<infinity> scott-work: There was a "might" in that sentence for a reason, you'll definitely want to do some testing. :P
<scott-work> infinity: oh yeah, i caught that ;)
<ogra> davmor2, it was just uploaded, be patient until the next publisher run :)
<infinity> scott-work: And doing only that will probably have the unfortunate side effect of reintrodcing those packages after every upgrade (when you really only want it from 12.04 to 12.10 and 12.04 to 14.04), but either that's a wart you can live with, or you get to look at more fine-grained quirking.
<infinity> scott-work: (By "every upgrade", I mean between releases, of course, not every single time a user upgrades packages or anything silly like that)
<infinity> scott-work: But maybe that's exactly the behaviour you want anyway, so users get reset to a known good state on each dist upgrade (which is sort of one of the primary goals of ubuntu-release-upgrader)
<scott-work> infinity: right, right. that seem a very reasonable wart though to make sure these packages are installed upgrading from 12.04 -> 12.10
<zequence> infinity: I wonder if it would be possible to add a query about it for the user upgrading the system
<infinity> zequence: Anything is possible, I suppose, though release-upgrader currently tries really hard not to ask questions.
<dholbach> stgraber, highvoltage: I didn't notice that a regular call of mine was moved permanently - I thought it was a one-off. This would mean we would have to move our hangout either an hour earlier or half an hour later - I'm sorry about that. :-/ Would that still work for you? Or would it have to be another day?
<stgraber> dholbach: half an hour later should be fine
<dholbach> yeehaw
<dholbach> that'll be the last move of this hangout now :)
<bdmurray> pitti: did you find armhf crash?
<davmor2> ogra: still no sound fix however there are now 2 bluetooth indicators that both work and look different
<ogra> intresting, thats a virgin image ?
<ogra> i surely dont have that here
<ogra> davmor2, rm /var/lib/alsa/asound.state ... reboot and see if sound works then
<ogra> (sudo indeed)
<Laney> cjwatson: Do I remember correctly that copyPackages doesn't generate -changes emails?
<davmor2> ogra: this was a fresh install on friday an then updates over the weekend, I enabled proposed and backports just to pull in your sound fix and that is the only non vanilla part
<cjwatson> Laney: Correct
<ogra> very strange i dont have two BT indicators here
<cjwatson> Indeed that's its purpose
<cjwatson> Laney: What are you trying to do, though?  Generally copyPackages should only be used by auto-sync
<ogra> though i havent changed my sources.list, using all defaults here
<Laney> Considering using it when syncing zillions of a certain class of package at once to avoid being complained at
<Laney> Not sure the complaints are justified though
<davmor2> ogra: I have one that has 2 switches and one that has a list similar to quantal and precise I'll take a couple of screenshots in a second
<cjwatson> Laney: I wouldn't, personally ...
<davmor2> ogra: sound fix no in place and working as you say sound is still muted on start up but then is fine after
<ogra> davmor2, right, thats known and we already have a better fix, good to know it works though
<davmor2> s/no/now
<Laney> well I don't consider it a problem. It would be only in the interests of inter-developer harmony
<seb128> davmor2, ogra: unity trunk (and the upload from today) recommends the new indicator-bluetooth, that will duplicate the indicator
<davmor2> ogra: this http://ubuntuone.com/68vJk5z8TAtGgZJdTuxtQs vs this http://ubuntuone.com/48NahUoCdw6FMvMb26TTUX
<ogra> seb128, aaah, thanks !
<seb128> davmor2, ogra: I need to drop the old indicator but I was waiting for unity to get upload ... do you guys run unity ppa?
<davmor2> seb128: that would do it then
<ogra> davmor2, so ignore it ;)
<ogra> seb128, no, but unity entered the archive today i think
<davmor2> seb128: I don't this was just with proposed and backport enabled
<seb128> davmor2, oh, proposed enabled, ok
<ogra> if i read that right between all the haskell spam
<seb128> ogra, well, it was uploaded 50min ago, that's what I call jumping on updates :p
<ogra> haha
<davmor2> seb128: to be fair I was trying repeatedly to pull in the update for sound and there were no updates that made me think to add proposed and try again then I got a bunch of update
<pitti> bdmurray: sorry, still on my list
<cjwatson> davmor2: raring-proposed?
<davmor2> cjohnston: yes
<cjwatson> davmor2: I really, really don't recommend that even for QA - the point of raring-proposed is to perform automatic checks before humans have to waste their time with things
<davmor2> cjwatson: yes even
<davmor2> cjohnston: sorry
<cjwatson> (And raring-backports is probably empty)
<davmor2> cjwatson: indeed I'm going to switch it back off again now :)
<xnox> BenC: infinity: how come powerpc is so oversized compared with the rest of desktop images? ubuntu/daily-live: raring-desktop-powerpc.iso oversized by 139128256 bytes (940128256)
<cjwatson> tjaalton: Do you know if anyone can verify bug 804109
<cjwatson> ?
<ubottu> bug 804109 in acpi-support (Ubuntu Precise) "drop synaptics from racy /etc/acpi/asus-touchpad.sh" [Undecided,Fix committed] https://launchpad.net/bugs/804109
<cjwatson> mterry: Are you able to verify bug 1083237?
<ubottu> bug 1083237 in deja-dup (Ubuntu Quantal) "Ignore Steam files by default" [Undecided,Fix committed] https://launchpad.net/bugs/1083237
<mterry> cjohnston, not on my current machine, and I'm in a coffee shop.  But I can tomorrow
<mterry> cjwatson, ^ whoops
<infinity> xnox: Probably because someone thought that shipping 4 kernels on it would be a swell idea.
<cjwatson> Daviey: Can anyone on your team 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
<Daviey> cjwatson: wilco, thanks
<xnox> infinity: =( and no magic to make them smaller / combined (e.g. is stuff for arm kernel consolidation applicable to powerpc at all?!)
<infinity> BenC: Do you actually do desktop installs on your server kit?  Is there any value at all in having -e500* on the desktop CDs?
<infinity> xnox: ppc/ppc64 obviously can't be combined anymore than i386/amd64 can be, as for the e500 stuff, there are apparently fundamental platform reasons why they can't be a single zImage right now, though I keep forgetting what those reasons are. :/
<xnox> fair enough.
<xnox> It's just 140MB oversize is excessive....
<infinity> (It's a bit ironically tragic, given that PPC has some of the best multi-platform support in the kernel tree)
<infinity> (And most of that was cargo-culted for the ARM consolidation)
<bdmurray> barry: could you have a look at bug 1112496?
<ubottu> bug 1112496 in python-imaging (Ubuntu) "python-imaging broken in raring" [High,Triaged] https://launchpad.net/bugs/1112496
<xnox> infinity: might as well build 4x images, since the test matrix has been exploded anyway. (reuse squashfs but add/rm different kernels?!)
<infinity> xnox: Ew.  No.
<infinity> xnox: If one image can boot on all the hardware, validating 4 images is silly.
<infinity> xnox: That said, the e500 kit is pretty much all server kit anyway, so dropping those two kernels from the desktop image may well be sane.
<barry> bdmurray: i've been more or less deferring that one to doko because he uploaded the pillow support and (i think) wasn't to thrilled with my previous attempts at packaging that stuff up. ;)  dunno if/when he's around (he's not right now), but perhaps we should just assign the bug to him for now and i can look at it if he's going to be away for a while
<infinity> xnox: (There's also the part where, since we ditched CD-sized images, we have some leeway here, and can just declare that PPC gets to be bigger and be done with it)
<bdmurray> barry: I'll assign it to him and we can talk about it Wed if need be
<xnox> infinity:  yeah, i know. 4 ppc images would be silly =) bigger is fine, but 140MB is a bit too big. Do all of the supported systems have dvd drives & drivers?
<barry> bdmurray: +1 thanks
<infinity> xnox: A bit "too big", why?
<infinity> xnox: Once it's bigger than a CD, how big is too big?
<xnox> infinity: was quantal ppc bigger than cd?
<xnox> infinity: i thought that somebody complained about lack of dvd, but now i can't remember if it was lack of blanks to burn or lack of dvd-drive in the powerpc box.
<infinity> xnox: I don't see quantal/desktop for PPC at all.
<xnox> quite a difference there.
<infinity> xnox: Lots of old PPC kit won't have shipped with DVD drives.  This is no different from lots of old x86 kit.
<xnox> cause e.g. pointless to have old powerpc kernels on the desktop DVD, if none of those machines had a dvd drive =)))))
<xnox> anyway, not terribly important for now =)
<infinity> Define "old".
<infinity> ppc64 boots hardware that ships today.
<xnox> kk.
<infinity> e500 isn't "the new PPC platform", it's just "a different one".
<infinity> And yes, ideally, it should be consolidated into the ppc32 kernel.
<infinity> (and e6500 should be consolidated into the ppc64 one)
<infinity> But, as I said, there are currently technical difficulties with that.
<infinity> I'm still all for dropping those kernels from the desktop media, though, if BenC concurs.
<stokachu> cyphermox: ping
<bdmurray> slangasek: bug 1096022 doesn't seem to be occurring much anymore and the virtual machine I finally created is not encountering it either.
<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
<bdmurray> https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-universe/
<bdmurray> the last failure was on 1/21
<slangasek> bdmurray: well, that's vaguely satisfying then ;)
 * infinity raises an eyebrow.
<bdmurray> psivaa: Please let us know if that upgrade fails again.
<infinity> I kinda want to know how we accidentally fixed it.
<cjwatson> jdstrand: Any reason secureboot-db shouldn't be copied to {precise,quantal}-updates?  There's no verification bug for it.
<cjwatson> Oh, yes there is, the report just isn't finding it ...
<psivaa> bdmurray: ok, will do, but did not see this after 21st Jan
<infinity> cjwatson: I was going to wait until we finished maining it and getting something(s) to depend on it.
<cjwatson> infinity: I'm not sure that's going to happen for .2.
<infinity> cjwatson: Well, you need a new grub2-signed anyway, and I'm told that was one of the things they wanted to depend on it.
<cjwatson> But it seems potentially useful for OEMs even without that.
<infinity> Oh, crap.  Does grub2-signed land in d-i images?
<cjwatson> I mean, it's currently empty anyway :-)
<cjwatson> infinity: Yah
<cjwatson> Don't they build from -proposed though?
<infinity> Poo.  Then that last upload was a wash.
<cjwatson> How come?  The grub2-signed in -proposed will be fine for .2, I expect ...
<cjwatson> Just needs the server team to get round to verifying one last bug
<cjwatson> Which should be an easy one
<infinity> cjwatson: grub2-signed in proposed is out of sync with grub2 in proposed...
<cjwatson> Oh, hmm
<cjwatson> Yeah, this secureboot-db package in -proposed is trivial.  I'm going to copy it just to make reports shorter, even though it's currently pretty useless.
<infinity> Alright, I can promote it later.
<cjwatson> Yeah, we should update grub2-signed.  I'll do that now.
 * jdstrand read the backscroll but seems there is nothing to do
<infinity> cjwatson: So, if you're doing that, you could make it pull in secureboot-db too. :P
<cjwatson> I guess.
<cjwatson> jdstrand: ^- confirm that that's wanted?
<jdstrand> we want shim-signed and grub2-signed to Recommends it
<tjaalton> cjwatson: yeah, i could..
<infinity> Or recommends, yes. Sorry.
<cjwatson> jdstrand: Could I have a bug report for this, please?
<cjwatson> If there isn't one already ...
<infinity> I was going to add tasks to the MIR.
<infinity> Once I'd done reviewing it.
<infinity> cjwatson: How about we don't upload grub2-signed just yet, and I'll do the MIR review first. :P
<mterry> jbicha, heyo.  Does the GNOME Remix want to keep patches that change "..." to the proper unicode char?  (I'm going through gnome-bluetooth's patches, now that Unity will use indicator-bluetooth
<jbicha> mterry: which patch? we might not even be using that code so it may not be worth maintaining the patch in Ubuntu
<jbicha> I'm pretty sure GNOME would take an ellipsis patch though for https://live.gnome.org/GnomeGoals/UnicodeUsage
<cjwatson> infinity: Well, I have grub2-signed uploads ready to go whenever you say the word; the sooner the better
<cjwatson> bdmurray: Will you be able to verify bug 984276?
<ubottu> bug 984276 in casper (Ubuntu Precise) "installing casper on a non live system causes update-initramfs to fail" [High,Fix committed] https://launchpad.net/bugs/984276
<cjwatson> Sweetshark: Do you know how far off we are with verification of bug 1037111 for precise?  Since it's a big download, it'd be nice to have it in 12.04.2.
<ubottu> bug 1037111 in libreoffice (Ubuntu) "[SRU] LibreOffice 3.5.7 for precise" [High,Confirmed] https://launchpad.net/bugs/1037111
<infinity> cjwatson: The last comment seems to imply it's well on its way.
<cjwatson> Indeed, but I want to make sure it finishes :-)
 * infinity nods.
<bdmurray> cjwatson: yes, I'll do that now
<infinity> cjwatson: Let me go stab secure-whoever-whatsit for you for MIR goodness.
<infinity> Maybe after I have a midnight snack.
<zequence> infinity: Where is the code for the ISOs, exactly? (Ubuntu, and other flavors)
<cjwatson> bdmurray: Thanks
<cjwatson> tjaalton: Also, do you know what's happening about verification of bug 1064192?  I think we want all the driver packages in .2 ...
<ubottu> bug 1064192 in nvidia-graphics-drivers-173 (Ubuntu Quantal) "[update request] nvidia-173.14.36 adds support for xserver ABI 13 [quantal and precise .2]" [Medium,Fix committed] https://launchpad.net/bugs/1064192
<zequence> infinity: Never mind :)
<tjaalton> cjwatson: hum, no.. tseliot ^
<tseliot> cjwatson: unfortunately I don't own a graphics card to test that driver
<tseliot> tjaalton: ^
<infinity> jdstrand: So, I only have one concern with this secureboot-db thing.  Why does the postinst ignore errors from sbkeysync?
<jdstrand> infinity: right, I did that on purpose. let me try to rethink why
<smoser> psusi, ping.
<jdstrand> infinity: I have in my notes is that sbkeysync doesn't actually exit with error under certain conditions. That coupled with the fact that I tend not to want to break upgrades, I opted for '|| true'. I also thought it conceivable that sbkeysync could have updated db/dbx but grub wasn't setup yet to use the knew kernel (resulting in an unbootable system)
<tjaalton> tseliot: does it support gf8600gt?
<jdstrand> (plus I didn't want different postinst behavior if sbkeysync changed its error handling)
<infinity> jdstrand: Well, given that we're upstream for sbkeysync, I'd like to think that if it ever exits with an error that's because we think something bad has happened.
<infinity> jdstrand: And if that's not true, perhaps we should fix it. :P
<jdstrand> infinity: "I also thought it conceivable that sbkeysync could have updated db/dbx but gru wasn't setup yet to use the knew[sic] kernel" because we exited with error
<tjaalton> tseliot: seems like it does, so i can verify it..
<tjaalton> cjwatson: ^
<jdstrand> infinity: I hear what your saying, but I felt that erring on the side of caution (ie, making sure the system is at least bootable) was paramount
<infinity> jdstrand: Assuming that's what this does, sure.  I was envisoning the opposite, I suppose.  sbkeysync tells us something went horribly wrong, we ignore it, the user has no unfriendly "egads, stuff broke" error messages and reboots into a brick.
<jdstrand> infinity: the only way that I can imagine that a system would become unbootable is if sbkeysync ran and updated db/dbx, but we didn't finishing setting up booting the non-blacklisted new grub/shim/kernel/...
<jdstrand> the || true was an attempt to guard against that
<infinity> jdstrand: Fair enough.
<jdstrand> I suppose a firmware bug would be possible there, but... /me moves hands around
<infinity> jdstrand: Thankfully, we've not seen any UEFI firmware bugs that brick systems.
<jdstrand> most of those would likely cause an unbootable situation regardless
<jdstrand> hehe
<jdstrand> true
<jtaylor> doko: can you please comment on bug 1112496
<ubottu> bug 1112496 in python-imaging (Ubuntu Raring) "python-imaging broken in raring" [High,Triaged] https://launchpad.net/bugs/1112496
<smoser> infinity, what is the lkelyhood of getting a newer util-linux?
<doko> jtaylor, later, just back from travelling
<cjwatson> mlankhorst: while I'm nagging people about X-related updates - any chance of verifying bug 1070481?
<ubottu> bug 1070481 in xorg-server (Ubuntu Precise) "memory corruption in xorg-server when closing acpid" [Undecided,Fix committed] https://launchpad.net/bugs/1070481
<infinity> cjwatson: https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1087843 is a go.  I'll pre-promote now, feel free to upload grub2-signed with the recommends.
<ubottu> Ubuntu bug 1087843 in shim-signed (Ubuntu Raring) "[MIR] secureboot-db" [Undecided,New]
<cjwatson> infinity: Right.  In progress.
<smoser> ours is quite old. i'm specifically interested in gpt features and 'partx --update' (bug 1096999 and bug 1087526)
<ubottu> bug 1096999 in util-linux (Ubuntu) "add new partx update and resize upstream features" [Undecided,New] https://launchpad.net/bugs/1096999
<ubottu> bug 1087526 in cloud-utils (Ubuntu) "need support for gpt partition tables" [Undecided,New] https://launchpad.net/bugs/1087526
<mlankhorst> cjwatson: oh go right ahead and close it, the patch has been tested so many times that as long as it's applied it works :P
<infinity> smoser: I keep meaning to set up a proper shared repository so lamont and I can co-maintain it more sanely.
<infinity> smoser: But I can certainly see about updating it in experimental/raring.  I assume you're not looking for SRU backports here, right?
<lamont> infinity: I support this plan.
<lamont> infinity: well, actually I support the plan where you actually create a shared repo, rather than the plan where you keep meaning to, but don't. :p
<cjwatson> mlankhorst: tag it verification-done then :)
<smoser> infinity, i'm not looking for SRU for those, no.
<infinity> lamont: Heh.  Yeah, I'm terminally lazy when it comes to anything alioth-related.  I'll get to it.
<smoser> but at the moment it looks to me that gpt support in trunk is much newer than any released.
<infinity> smoser: Sure, I'm not averse to backporting select patches from trunk, but may as well make sure we're at a current release version first.
<smoser> right.
<mlankhorst> cjwatson: done
<smoser> i was going to suggest that 2.22 would be a better starting point for cherry picking than where we are now
<cjwatson> mlankhorst: ta
<smoser> that said, psusi cherry picked the partx patches anad has a branch for that.
<smoser> but i'd like the gpt support also.
<infinity> smoser: Tell you what.  I'll get that done, if you find some free time to fix eglibc on Debian/kfreebsd.  Thanks in advance.
<smoser> infinity, you're welcome
<smoser> i hope i didn't sound ungrateful
<infinity> smoser: :)
<infinity> Ugh, 520 open util-linux bugs.  I sure do know how to pick the wrong packages to co-maintain.
<infinity> smoser: I'll put the Debian update on my hobbyist TODO.  I'm sick of glibc this week anyway.
<lamont> infinity: +500 - halp welcome
<smoser> infinity, the good thing is that its such a fringe package, that an upgrade of a years worth of upstream development (2.20.1 -> 2.22.2) is not likely to cause any fallout.
<jdstrand> infinity: thanks for the review :)
<infinity> smoser: Yeah, no one really uses it anyway.
<infinity> smoser: S'ok, I have a knack for adopting fringe cruft that no one uses.
<ogra> ogra@nexus7:~$ ps ax|grep -c "udevd --daemon"
<ogra> 17
<ogra> hmm, that cant be right
<mlankhorst> pgrep udevd ?
<ogra> it had different PIDs, werent threads
<Esokrates> hi, i have compiled both, compiz and unity. If i log in with lightdm i can only see the wallpaper, so i change to a virtual terminal and type:  env DISPLAY=:0  --replace composite opengl move resize decor compiztoolbox mousepoll wall expo animation switcher unityshell
<Esokrates> but what i get is different from how things are configured in default ubuntu
<Esokrates> (workspaces all in a row, minimize animation mac -like
<Esokrates> cannot snap windows etc. ...
<Esokrates> how to configure to get the ubuntu default experience?
<ogra> cjwatson, 393MB for the idling desktop (after i restarted udev to get rid of the piling up daemons) with your libgtk-3.0  \o/
<seb128> ogra, how much was it before the update?
<ogra> cjwatson, that should be a good 30M
<ogra> seb128, above 400 ... somewheer around 420
<seb128> nice
<ogra> hmm, i have a pulseaudio daemon go crazy here
<cyphermox> stokachu: pong
<ogra> oh, it even dropped to 375 now
<ogra> ah, 17M swap :P
<xxiao> saw a few old connections leaving cannonical for linaro
<smoser> infinity, would you be opposed to me grabbing psusi's backport for util-linux ?
<smoser> as it seems to "work for me"
<infinity> smoser: That has pretty much zero context.
<smoser> well, context was provided earlier , https://code.launchpad.net/~psusi/ubuntu/raring/util-linux/cherry-pick-resize
<infinity> smoser: Yeah, if you need that right freakin' now, that seems like a reasonably self-contained backport.
<smoser> infinity, well even if you pulled 2.22.2, it wouldn't have that
<infinity> smoser: I'm certainly not going to get to a new upstream tonight or anything.
<infinity> smoser: *nod*
<smoser> i dont need it *right now*
<smoser> but at som epoint i want it
<smoser> so if you're not opposed to getting it before you were to do a potential update, then i might just do that.
<infinity> Yeah, I have no objections to it.
<cjwatson> ogra: rock
<ogra> yeah
<ogra> we'll end up on 256M if it moves on like that !
<cjwatson> I wonder if we've hit the second memory target yet
<ogra> not yet, there is still something weird going on right after boot
<ogra> it peaks above 500M and then goes down to the state it keeps
<ogra> once we have that we should be able to tick off 2 and 3
<BenC> infinity: I have no problem with e500* being left off of desktop media
<cjwatson> ogra: does bootchart reveal anything interesting?
<ogra> cjwatson, to me it looks like 2 and 3 are actually flipped, shouldnt the standlone desktop be 2 and desktop +app be 3 ?
<cjwatson> I didn't set the targets :-)
<ogra> cjwatson, not checked yet, its on my plan for tomorrow ... together with finding out why i have 17 udevd's running
<infinity> BenC: I know we had this conversation before, and I've entirely forgotten the technical reasons given, but is there zero chance that e500* (and e6500 or whatever the 64-bit one is) will ever be able to be built into generic ppc32/ppc64 zImages?
<cjwatson> It depends whether browser+mail-client were >512MB at the time that list was compiled
<cjwatson> Doesn't udev keep a worker pool or something?
<ogra> they surely were >1G
<BenC> infinity: at this point, that's a negative
<BenC> ppc32 will never happen
<ogra> cjwatson, with a daemon for each of them ?
<cjwatson> ogra: I mean on their own, without the desktop
<infinity> BenC: Yes, I know it's not likely "at this point", I meant "in the future".
<BenC> ppc64 will take great effort, but I'm going to push Freescale as much as I can to do the mmio work
<cjwatson> ogra: they'll be forks of the original
<ogra> i literally had /sbin/udevd --daemon running 17 times here
<ogra> each with its own PID
<cjwatson> yes, it forks to run rules
<ogra> oh, ok
<infinity> BenC: Kay.  In theory, if the ppc64 single zImage could happen, wouldn't the same work apply to ppc32 with some judicious cargo-culting?
<ogra> hmm
<BenC> infinity: Not really...
<BenC> There's a lot more than mmio work to be done there
<cjwatson> hm, it doesn't look as though it's supposed to keep a pool around though
<kentb> where can I get some help with getting some packages into quantal/precise-backports from raring?  I've got the bug requests filed and done the testing, etc.
<infinity> BenC: Irksome.
<cjwatson> but I can't easily look through any more than small amounts of the code from here
<xxiao> what's the benefit to get freescale e5** to zImage?
<infinity> kentb: Did you subscribe ~ubuntu-backporters to your bugs?
<kentb> infinity, yes. several months ago
<infinity> xxiao: Not building and shipping several redundant kernels?
<BenC> It's not "zImage" it's getting them to be built in the same image
<BenC> xxiao: I think the idea is more like being able to build IBM Power kernel and Freescale Power kernels together
<infinity> xxiao: Oh, yes, when I say "single zImage", it's the "single" part that matters.  I wasn't actually referring to the binary format.
<xxiao> not sure if each side will ever prioritize this effort
<infinity> And, up until recently, PPC was kinda the poster child for disparate platform support in a single kernel.
<infinity> It's a bit sad that's now becoming gratuitously untrue.
<xxiao> not sure who is funding fedora's ppc64 release
<BenC> infinity: to be fair, not many platforms have a bookS and bookE type of platform seperation
<xxiao> i don't see the point for 64bit user space, will give fedora ppc64 rootfs a try sometime though
<xxiao> BenC: there is at least one FPU instruction difference between ibm and fsl e5500/e6500, that only matters if hard-float is used correct?
<infinity> jdstrand: Oh, bah.  Second problem qith secureboot-db.  It depends on sbsigntool, but is arch:all, so is "broken" on non-x86.
<infinity> s/qith/with/
<slangasek> infinity: why does that bother us?
<infinity> jdstrand: You've taken away my precious beer on http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html
<slangasek> aren't there a number of such "broken" packages?
<infinity> slangasek: Not in main, there aren't.
<slangasek> hmm
<jdstrand> huh
<slangasek> I consider this an artificial requirement
<jdstrand> I didn't realize sbsigntool was only i386 and amd64
<slangasek> Debian has never held that rule
<infinity> sbsigntool probably shouldn't be x86-only in the long term.  But it is for now.
 * jdstrand wonders why, since arm is supposed to have secure boot
<slangasek> jdstrand: IIRC it has to do with architecture dependence of the PE format we're signing
<jdstrand> that makes sense
<infinity> jdstrand: No ARM devices we care about (yet) have EFI or SB.
<slangasek> bug #1020771
<ubottu> bug 1020771 in sbsigntool (Ubuntu) "FTBFS: Tests fail on non-x86" [Undecided,Fix released] https://launchpad.net/bugs/1020771
<jdstrand> infinity: I can fix this in a bit, I'm training someone atm
<infinity> jdstrand: Yeah, I'm in no rush.  Was just pointing it out.
<xxiao> a newbie question, if soft-float and math-emulation are both turned on, which one will be used by default?
<infinity> slangasek: And, you're right, Debian's never required that arch:all deps be satisfiable on all arches, though it is mildly irksome when they can't be.
<infinity> slangasek: For something less strangely esoteric than secureboot-db, see usb-creator, which used to be arch:all, but it's actually really frustrating when some guide says "do this with usb-creator", and you try to install it and it's "broken" on your arch.  Better to just not have it available at all.
 * slangasek nods
<smoser> infinity, one other thing.. if you do ever update util-linux, change debian/source/format to something other than 1.0 please.
<smoser> it just feels dirty to change code without quilt
<infinity> smoser: lamont's been maintaining it in git, where 1.0 makes some sense.
<smoser> yeah, ok. i haven't any experience with that.
<infinity> (Basically, the same way we maintain the kernel packages in Ubuntu)
<infinity> If your upstream is just another git remote, you can cherrypick patches to your heart's content, and have a sane history.
<smoser> when you cherry-pick is there some git knowledge of the source ?
<infinity> There doesn't need to be, since git hashes are unique unlike, say, bzr revisions.
<smoser> well, bzr revisions are not, but the revision-id is in bzr
<smoser> anyway.
<smoser> i just uploaded psusi's branch.
<smoser> sanity checked that it generally functioned for what i was wanting
<smoser> (and it seems to work for gpt stuff, not sure really how)
<lamont> smoser: do not make me get upset at you by suggesting that the VCS belongs in the source package.  source-format = 1.0 is the only sane state
<smoser> i dont think its the *only* sane state.
<lamont> smoser: there was a brief period where I went with 3.0 for either bind or postfix, and I've been sad about that ever since.  OTOH, hardy EOLs soon
<lamont> smoser: for the same reason that I hate quilt and dpatch, I find absolutely no benefit to 3.0
<lamont> of course, that's mostly because when I check out the tree, I want to actually have the patched tree, not a tree with lots of unapplied patches
<lamont> if I were to majorly fork from upstream, that might make a differnce
<infinity> Yeah.  I'm finding 3.0 makes some sense with glibc.
<cjwatson> 3.0 can give you a patched tree, FIW
<cjwatson> FWIW
<infinity> Not that we're "majorly forked", but we carry a lot of patches.
<smoser> right.
<cjwatson> It always gives you a patched tree on dpkg-source -x
<cjwatson> Whether it does on VCS checkout depends how you lay out your VCS
<smoser> bzr with patches appplied seems to work reasonably well recently.
<infinity> cjwatson: But that's not generally how one wants to check it into git.  Unless you really want all your patched files duplicated in .pc
<smoser> and doesn't bother showing you the .pc/ changes.
<smoser> its not perfect, but it is loads better than it was.
<cjwatson> infinity: The way I run my 3.0 (quilt) trees in bzr (when not using UDD) is to commit debian/patches/ but not .pc/
<cjwatson> Which is not without its problems but works reasonably OK
<smoser> cjwatson, if you stop fighting UDD, its really not terrible any more :)
<cjwatson> It does mean that to get quilt working to actually develop against the checkout you have to run a script to unapply/apply
<smoser> i followed your lead and had the non-applied .pc
<cjwatson> smoser: I use UDD too elsewhere so have plenty of opportunity to compare
<smoser> now i just try to let it handle it.
<cjwatson> I still prefer my approach :)
<cjwatson> But it's true that you have to handhold sometimes - there's really no perfect approach without additional tooling
<smoser> much of my battle wounds were from fighting the importer
<smoser> as it gets all ticked off with your way
<cjwatson> Yeah, I only do this on branches the importer doesn't touch
<cjwatson> Fighting the importer is definitely a mug's game
<smoser> yeah, i just wanted it to work in both ways, so people (other people) could "just upload"
<cjwatson> My most complex package maintained this way is grub2; and my intended solution for that is to get it in sync with Debian so that I no longer have to care about the importer
<cjwatson> (In fact I don't right now, I use a different branch, but)
<cjwatson> pitti: TB meeting in <10/
<cjwatson> ?
<pitti> cjwatson: thanks for reminder, I'm back onlne
<pitti> just with missing 'i's
<jdstrand> infinity: ok, secureboot-db uploaded to raring-proposed. shall I also upload it to precise-proposed and quantal-proposed? (note, that -updates for precise and quantal has secureboot-db)
<infinity> jdstrand: Yeah, please do.
<jdstrand> cool
<smoser> Daviey, to follow up, my initial thought on how to preseed cloud-init for nocloud wont work.
<smoser> the way i was oding it for fast path installer also requires modification of the command line (kernel cmdline)
<smoser> adding 'ds=nocloud'
<smoser> hm... actually i dont know.
<smoser> well... i suspect i can get it to work on quantal, but not on precise cloud-init.
<tseliot> tjaalton: great, thanks!
<jdstrand> infinity: uploaded. I'm stepping away for a couple/few hours but will be back later if you need anything else
<xxiao> http://paste.ubuntu.com/1610479/
<xxiao> mk-sbuild for ppc core-dump
<xxiao> on precise
<cjwatson> More precisely, qemu-ppc-static core dumps.
<cjwatson> It'd be pretty surprising for mk-sbuild to core dump given that it's a shell script.
<xxiao> u r right :)
<cjwatson> qemu from raring might do better.
<xxiao> a bit surprised on doing this basic thing on LTS though
<infinity> xxiao: qemu-user-static is known-broken on a lot of architectures.
<infinity> xxiao: As a general rule, you're better off building natively anyway, since PPC hardware is far faster than anything x86 could emulate.
<xxiao> infinity: true, it's just my ppc boards(not Apple machines) are a little noise here :)
<xxiao> noisy
<xxiao> i'll live with that...
 * xxiao puts on his Optime95
<psusi> smoser, pong
#ubuntu-devel 2013-02-05
<smoser> psusi, hey. uploaded your util-linux
<smoser> was going to ask you if it would work for gpt. i didn't think it would, but it seems to.
<psusi> smoser, ahh, cool... I don't remember if kpartx speaks gpt or not
<psusi> err, partx
<slangasek> from what I've seen, it doesn't
<slangasek> but maybe I was doing it wrong
<psusi> smoser, I've got patches for upsteam parted to add a resizepart command to use the new ioctl to sync the new, larger patition size as well, so you can just run parted -s /dev/sda resizepart 1 100%
<smoser> slangasek, psusi well, what i did is shown at https://bugs.launchpad.net/cloud-utils/+bug/1087526
<ubottu> Ubuntu bug 1087526 in cloud-initramfs-tools (Ubuntu) "need support for gpt partition tables" [Undecided,New]
<smoser> it seemed like the kernel/udev could get confused easily (see comment 4), but it *did* work.
<smoser> psusi, that'd be pretty nice.
<smoser> for now, growpart does basically the same thing
<smoser> growpart /dev/sda 1
<smoser> will work for gpt or msdos
<smoser> (as of today)
<smoser> it uses sgdisk or sfdisk
<smoser> but it (growpart) does not do the partx call yet. i plan to make an option to it.
<psusi> smoser, why make it an option?  if sfdisk or sgdisk complain about BLKRRPART failing, may as well go ahead and run partx -u
<smoser> psusi, yeah, i considered that.
<smoser> the only reason to not have it just do it is that it "just didn't" before
<psusi> well, before it was run in the initramfs so it wouldn't run into that error, right?
<psusi> so now it does the same thing, just is no longer restricted to running in the initramfs
<psusi> are there any other outstanding issues to dropping the initramfs from cloud images?
<lifeless> psusi: wait, what ?
<psusi> lifeless, at UDS... what was it, october before last?  in Orlando, we discussed dropping the initramfs as a requirement for simple configs that don't really need it
<psusi> lifeless, cloud image boot time is apparently significantly impacted by the initramfs, and iirc, the one hangup for getting rid of it was growpart
<lifeless> psusi: so what would an image look like then?
<lifeless> psusi: FWIW cloud images boot in 5-6 seconds for us with the initramfs.
<psusi> lifeless, just the kernel, no initramfs
<lifeless> psusi: this worries me, because the initramfs provides an excellent debugging facility when things go wrong
<lifeless> psusi: will it be easy to revert for folk building on the cloud images?
<psusi> about the only thing that can go wrong in the initramfs with a simple disk config is can't find the root fs
<psusi> yea.. the plan was to make it optional, and most configs have no need for it, so, faster boot
<lifeless> psusi: we're using the cloud images to boot bare metal :0
<smoser> i really doubt the initramfs is a significant speed issue for cloud images. it might be. but it'd shave a second or two at most i'd think.
<smoser> clearly non-zero
<psusi> the idea was also to have regular installs initramfs scripts detect whether or not an initramfs is actually required ( i.e. you are using lvm ) and disable it unless overridden
<smoser> right. this is really a uber-fast desktop boot thing.
<psusi> ohh, maybe it was the arm guys that were driving it because for them it was a big time sink
<smoser> it was/is a time sync.
<smoser> and it is not insignificant.
<psusi> something about grub being very slow at IO on arm
<smoser> loading 10M-ish, decompressing, runnign a bunch of scripts ...
<smoser> well, bios load is generally slow (which is what grub is using)
<smoser> so its not going to be the fastest thing in the world, for sure.
<psusi> iirc, arm has no bios so grub was using its own disk module there, which was supposedly very slow
<smoser> right.
<psusi> but it does add a not insignificant time to boot on your average pc desktop and cloud images too
<smoser> anyway... during that "lets get rid of initramfs" discussion, i raised that i like initramfs , and this was one of the reasons why.
<smoser> but then psusi fixed *that* the right way, and now we dont need initramfs for it anymore. which is really cool.
<smoser> but doesn't mean we'll drop initramfs. just one less thing to prevent it being dropped.
<lifeless> ok
<lifeless> well, let me know what we need to do to keep it on, so the ops guys doing run around gibbering
<lifeless> :)
<psusi> what benefit does it provide when you are using a simple disk config?
<psusi> it's whole purpose is to locate the root fs, so if the kernel can do that on its own...
<psusi> did the kernel uuid finding patches ever get applied?
<lifeless> psusi: so - for example - the HP public cloud has two block devices
<lifeless> psusi: and there may be LVM particularly if you are using boot from volume.
<psusi> yea, lvm still would require an initramfs
<lifeless> psusi: bare metal cloud will often have more complex setups too.
<psusi> well, if / is on lvm anyhow
<smoser> lifeless, you dont have to worry.
<lifeless> psusi: MAAS is moving to using cloud images; nova bare metal uses cloud images.
<smoser> its not going away.
<lifeless> smoser: yeah, I'm not:)
<smoser> it would be going away in places where its not needed
<smoser> but you're listing places where it *is* needed.
<lifeless> smoser: that was estalished above; I'm answering psusi's question about where it may be needed.
<lifeless> smoser: I may have misparsed that question, of course :>
<psusi> right, the question  was where is it needed, other than when / is on lvm ;)
<smoser> when / is crypto
<psusi> or that ;)
<lifeless> or when / has died and you want to poke around
<smoser> when / is iscsi
<smoser> lifeless, when / has died and yrou initramfs was on /
<smoser> you're kind of dead
<lifeless> smoser: well, PXE booting initramfs+kernel
<psusi> that's grub fallback time
<lifeless> smoser: / can die, can still examine :)
<smoser> well, its not goingt away in pxe boot either!
<lifeless> indeed!
<psusi> yea... the idea was for simple disk configs.. i.e. root is on a regular disk partition
<smoser> and smart people were even discussing ways where grub would fall back automatically to initramfs if no-initramfs seemingly failed.
<lifeless> nice
<smoser> just ask yourself, do you think that OS that runs on your devices from apple have an initramfs ?
<smoser> (not that they boot fast... but probably not necessary )
<lifeless> smoser: what devices from apple? :)
<smoser> your kids devices, lifeless
<smoser> :)
<smoser> yeah, thats why i have one.
<smoser> kids.
<lifeless> You have a kid to get apple devices?
<lifeless> Seems expensive :>
<smoser> its not significantly more than the price of the device.
<smoser> and easier to justify to employer
<lifeless> rotfl
<smoser> can someone else confirm for me ...
<smoser> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1015339
<ubottu> Ubuntu bug 1015339 in debian-installer (Ubuntu) "Missing kernel modules for Mellanox ConnectX HCA Ethernet " [Medium,Confirmed]
<smoser> that doesn't look like an installer issue to me, but a driver issue.
<smoser> (as in lack of pci-ids or some other reason it wouldn't load automatically)
<lifeless> smoser: hi
<lifeless> smoser: so thats our hardware config; the driver is in a separate kernel package
<smoser> separate kernel package, as in ...
<lifeless> smoser: linux-image-extra
<smoser> ah. well, that is installed by linux-server -> linux-generic -> linux-image-generic -> linux-image-extra-3.8.0-4-generic
<lifeless> does the server image build include that by default?
<smoser> ie, it was not just missing driver in initrd.gz (at least per the reporter).
<lifeless> hi
<lifeless> smoser: EntropyWorks is the reporter
<EntropyWorks> Hi
<lifeless> EntropyWorks: I'll just pastebin the discussion so far
<smoser> oh. there, you're right. it does not include it.
<smoser> at least per report
<lifeless> EntropyWorks: http://paste.ubuntu.com/1610977/
<smoser> so you're right. thats strange.
<smoser> but EntropyWorks it seems that just having it in the intiramfs is not enoguh to make it work, right?
<smoser> yo uahve to load it manually?
<smoser> at least that goo.gl link there seems to imply that (as does another report to me)
<lifeless> so there may be two bugs :)
<EntropyWorks> let me dig up my notes on this.
<lifeless> A) Where is my driver!
<lifeless> B) Why driver not load?!
<smoser> right.
<smoser> but "where is my driver" is not (i dont think) related to "my driver is in -extra"
<smoser> so yeah, "where is my driver" i san installer/installer build process bug.
<smoser> "why my driver no load" is a driver/udev/kernel bug i think.
<smoser> EntropyWorks, so why did you do this udev rule business for modprobing?
<lifeless> smoser: right, being in -extra isn't an intrinsic bug (but if -extra isn't in the installer default initramfs...)
<smoser> nah. most every thing is 'extra' from that perspective
<smoser> i think
<EntropyWorks> I eventually did something slightly different after getting fustrated.
<smoser> but maybe your'e right. i could be wrong.
<EntropyWorks> I went and downloaded the http://us.archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz and unpacked it...
<smoser> EntropyWorks, it seems to me what you did with that udev rule should have been equivalent to adding the item to /conf/modules in the intiramfs.
<smoser> ie, by putting it in /conf/modules, you're doing what would happen if you had put it in /etc/initramfs-tools/modules during the initramfs build process.
<EntropyWorks> I added a 80-mellanox-drivers.rules to /etc/udev/rules.d
<smoser> right. but why/where did you come up with that?
<smoser> it would seem to me that you're essentially loading mlx4_en every time a "net" device was found.
<smoser> i could be missing something.
<EntropyWorks> its been a while since I repackaged this initrd.gz for the netboot so forgive me while I try to remember. I think I may have just borrowed it from somewhere else. to be honest.
<smoser> EntropyWorks, thats fine. i was just trying to see if i was missing something.
<lifeless> EntropyWorks: thats whats in the diskimage-builder rules
<EntropyWorks> before i was doing this.. echo "modprobe mlx4_en ; # Move this line up" >> init
<smoser> :)
<lifeless> EntropyWorks: we have both the modprobe and the udev rule
<smoser> you clearly should not need both.
<smoser> right?
<lifeless> https://github.com/stackforge/diskimage-builder/tree/master/elements/mellanox
<EntropyWorks> right
<smoser> and the udev rule is wierd, an I right?
<smoser> you're loading that module every time a net device is seen
<smoser> (but then, i'm kind of confused as to how linux knew it was a net device since clearly the driver didn't completely recognize it)
<smoser> EntropyWorks, just so we're clear, i'm grateful for your help, i'm just trying to figure out if you were doing stuff for a reason, so that i can make sure we take that into account.
<smoser> lifeless, where does 'init' from mellanox/init end up? hnow does that get rendered ?
<lifeless> smoser: it gets attached to the deploy ramdisk init script
<lifeless> smoser: the deploy ramdisk is a special special creature
<smoser> lifeless, thanks.
<EntropyWorks> I think this covers how I have been fixing my initrd.gz at the moment
<EntropyWorks> http://paste.ubuntu.com/1611008/
<EntropyWorks> I may have added etc/udev/rules.d/010_net-hotplug.rules but I don't think I did.
<EntropyWorks> smoser: honestly its been awhile and if there is anything confusing I can build another initrd.gz from scratch if you need it
<pitti> Good morning
<shadeslayer> hi pitti
<infinity> siretart: Hey, handbrake (in both experimental and raring) seems to be implicitly declaring a few functions that exist nowhere in the source, and I can't find reference to them in libav headers either.
<infinity> siretart: You might want to grep build logs for "implicit", and figure out where those missing functions went. :P
<infinity> siretart: (Maybe it's depending on either an old feature that was removed from libav, or a new feature that's not yet in the Debian packages?)
<tjaalton> cjwatson: um, nvidia-173 isn't in -proposed yet?
<tjaalton> cjwatson: for .2
<tjaalton> oh it's nvidia-173-updates
<tjaalton> jockey doesn't suggest any drivers for my gf8600gt
<tjaalton> the window is empty
<tjaalton> should there be a jockey launcher in system settings?
<tjaalton> on 12.10
<dholbach> good morning
<tjaalton> ..behind software sources it seems
<pitti> tjaalton: it's not jockey any more; right, software-properties supersedes it
<pitti> admittedly hard to discover
<tjaalton> yeah
<tjaalton> it should shout out tho that the system needs to be rebooted once the driver has been changed.. just logging out will end up in a crash and a bug report..
<tjaalton> a confusing one too
<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
<seb128> @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, seb128
<seb128> dholbach, alter! in what order do you go through the sponsoring list? I will try to help you a bit, I missed my shift while I was in SF
 * dholbach hugs seb128
 * seb128 hugs dholbach
<dholbach> I don't care which way we go - maybe we just say what we're looking at?
<seb128> dholbach, ok
<seb128> dholbach, I will try to grab what is desktopish first
<dholbach> seb128, I'll do cliff-tablib
<seb128> dholbach, doing alacarte nautilus language-selector xorg-gtest
<dholbach> woohoo
<seb128> ;-)
<dholbach> seb128, taking a look at ubuntukylin-theme
<seb128> Riddell, hey, do you have any comment on https://code.launchpad.net/~gunnarhj/ubuntu/raring/language-selector/help-update/+merge/145491 (dropping language-selector-kde)?
<Riddell> seb128: I'm not currently expecting to go back to using language-selector so I guess it's fine
<seb128> Riddell, ok, thanks, we can still bring it back some way if really needed
<seb128> pitti, ^ I'm sponsoring l-s then
<pitti> seb128: merci
<seb128> pitti, or did you want to do it/had it ready?
<seb128> pitti, de rien ;-)
<pitti> no, I didn't
<seb128> good
<cjwatson> tjaalton: my mistake, sorry
<cjwatson> tjaalton: I noticed the missing task and my eyes tend to pass over existing invalid tasks ...
<tjaalton> cjwatson: heh, yeah
<dholbach> seb128, taking a look at ktorrent
<seb128> dholbach, looking at telepathy-logger-qt
<dholbach> seb128, looking at ubuntu-sounds
<Esokrates> howto apply ubuntu settings to compiz compiled from source?
<Esokrates> I have compiled and installed compiz but when I login the only thing I get to see is the wallpaper
<Esokrates> so I change to a VT and start compiz using: env DISPLAY=:0 compiz âreplace composite opengl move resize decor compiztoolbox mousepoll wall expo animation switcher unityshell
<seb128> Esokrates, try asking on #ubuntu-unity but the compiz package ships a profile, export COMPIZ_CONFIG_PROFILE="ubuntu"
<seb128> Esokrates, not sure how you can get the profile and apply it from a source build
<Esokrates> @seb128 thank you
<udevbot> Error: "seb128" is not a valid command.
<seb128> dholbach, looking at sphinxbase
<seb128> dholbach, commented on the python-tz from stokachu, seems like a possible direct sync
<seb128> stokachu, ^
<jibel> doko, python2.7 2.7.3-15ubuntu1 broke the testsuite of bzr, I filed bug 1116079
<ubottu> bug 1116079 in bzr (Ubuntu) "Test bzrlib.tests.test_tuned_gzip.TestToGzip.test_enormous_chunk fails - potential regression in python2.7 2.7.3-15ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1116079
<jibel> doko, it's probably caused by this change "Issue #1159051: GzipFile now raises EOFError when reading a corrupted file with truncated header or footer.", could you have a look
<jibel> ?
<dholbach> seb128, cool
<seb128> dholbach, looking to vino
<dholbach> wow, you're quick :)
<seb128> dholbach, french efficiency my german friend :p
<dholbach> haha
<dholbach> tjaalton, Sarvatt: do we have someone we can ping upstream about bug 985202? :)
<ubottu> bug 985202 in libxrandr (Ubuntu Precise) "libx11 causes kwin to crash on login (over NX protocol)" [High,Triaged] https://launchpad.net/bugs/985202
<tjaalton> dholbach: sure
<seb128> pitti, hey, can you set https://code.launchpad.net/~baltix/ubuntu/precise/ubuntu-defaults-builder/remove-quotes-from-firefox-bookmarks-titles/+merge/137107 as needs work/work in progress/whatever status is available to indicate it needs the comments to be addressed before being ready for sponsoring?
<dholbach> tjaalton, and a bit more recently bug 1112147
<ubottu> bug 1112147 in mesa (Ubuntu) "gbm_dri_bo_create fails to initialize bo->base.base.format" [Medium,In progress] https://launchpad.net/bugs/1112147
<tjaalton> hmm, could be that they'd have better success via the list(s)
<tjaalton> although the mesa-dev list does get all the bugmail too
<seb128> pitti, can you set those as merged (they are in the unapproved queues for SRU):
<seb128> https://code.launchpad.net/~arges/ubuntu/precise/iptables/fix-lp982961/+merge/145941
<seb128> https://code.launchpad.net/~arges/ubuntu/quantal/iptables/fix-lp982961/+merge/145942
<tjaalton> dholbach: got a rev-by for the libxrandr patch, I'll upload it
 * dholbach hugs tjaalton!
<tjaalton> the mesa patch doesn't apply as-is to the version we're preparing, will investigate further..
<dholbach> seb128, looking at the raring part of firebird2.5
<seb128> dholbach, looking to bind9
<seb128> lamont, hey
<seb128> lamont, I'm looking at https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1090593 , e.g https://launchpadlibrarian.net/130013535/quantal.debdiff ... those debdiffs only change the ip, I saw that your version adds a "D.ROOT-SERVERS.NET.	 3600000      AAAA  2001:500:2D::D" ipv6 entry as well (in addition of autotools noise)
<ubottu> Ubuntu bug 1090593 in bind9 (Ubuntu Quantal) " D.ROOT-SERVERS.NET changing January 3rd 2013" [Undecided,New]
<seb128> lamont, should the ipv6 entry be added in those SRUs or are the current debdiffs with only the ip change fine for upload?
<dholbach> for security uploads to the current devel release - is it normal to use a *ubuntu0.13.04... version number?
<seb128> xnox, hey, is there still anything blocking https://bugs.launchpad.net/ubuntu/+source/player/+bug/979841 to be uploaded (you mentioned python issues)? you can probably fix the bug number/target and upload rather than just to block on the submitter to fix those typos
<ubottu> Ubuntu bug 979841 in player (Ubuntu) "robot-playercam crashed with SIGABRT in __assert_fail_base()" [Medium,In progress]
<xnox> seb128: let me check if python multiarch hacks got uploaded or not.
<cjwatson> dholbach: I wouldn't bother, just increment the version as usual
<dholbach> cjwatson, my question was the other way around (the suggested patch had 13.04 in it) and I thought it looked weird :)
<cjwatson> Yeah, I know.  It's not forbidden but I agree it's weird.  If I were sponsoring that I would just amend the patch and tell the contributor I'd done so (if it were otherwise OK)
<dholbach> cjwatson, since I have you here... do you have any feelings about bug 1102107? (I just saw that an earlier request in Debian was not acted on yet: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676533)
<ubottu> Debian bug 676533 in openssl "please enable arm assembler code in openssl" [Wishlist,Open]
<ubottu> bug 1102107 in openssl (Ubuntu) "Add basic arm64 support" [Undecided,New] https://launchpad.net/bugs/1102107
<dholbach> yeah, I changed it to ubuntu1 :)
<cjwatson> those bugs are quite different - arm != arm64
<cjwatson> I'll review 1102107, thanks
<cjwatson> dholbach: (And BTW 676533 was already applied in Ubuntu)
<seb128> xnox, I'm unsubscribing sponsors from https://bugs.launchpad.net/ubuntu/+source/libsemanage/+bug/1103271 btw, your comment indicates that the patch will need to be reworked if it's still needed at all, right?
<ubottu> Ubuntu bug 1103271 in libsemanage (Ubuntu) "libsemanage: Add crossbuild support" [Undecided,New]
<seb128> xnox, oh, you already did that, ignore me ;-)
<dholbach> cjwatson, yes, I saw that - I just thought that if the request for arm wasn't replied to after half a year, we probably shouldn't block on debian for arm64
<dholbach> thanks a lot for having a look at it!
<cjwatson> Eh, it's really not that related - that's arm optimisation, not arm enablement
<cjwatson> Enablement rightly normally jumps the queue
<dholbach> oh ok
<cjwatson> dholbach: I'm going to have to look around as I'm not convinced the second patch is correct either - it doesn't seem to agree with my reading of the arm64 abi
<dholbach> thanks a lot
<seb128> @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
<seb128> dholbach, ok, if/when pitti is around and mark the merge requests I pointed before as needs work/merge we should be < 35 in the queue
<seb128> dholbach, time to get some lunch ;-)
 * dholbach hugs seb128
<dholbach> good work
 * seb128 hugs dholbach
<seb128> thanks, you too
<jamespage> @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, jamespage
<jamespage> dholbach: how low can we go :-)
<dholbach> yes yes yes! :)
 * dholbach hugs jamespage
<dholbach> piloting party :)
<dholbach> jamespage, looking at 'player' right now
<jamespage> dholbach: OK _ I'll look at the bind SRU
<dholbach> jamespage, if you check the backlog - seb128 pinged lamont about something related to bind earlier
<dholbach> not sure if it's the same issue
<seb128> jamespage, I looked at bind9, I wanted to know if we should add the ipv6 record lamont added in his ppa and debian or not
<jamespage> seb128: right-oh
<marga> o/
<marga> I just uploaded two debdiffs to https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1100587
<ubottu> Ubuntu bug 1100587 in gnome-control-center (Ubuntu) "gnome-control-center does not remove system-wide proxy settings from /etc/environment when switch from manual to automatic mode." [Undecided,Confirmed]
<marga> I was wondering if this could be considered for an SRU or not.
<seb128> marga, hey, that debdiff seems fine to me, I will sponsor it today
<marga> seb128, tnx
<seb128> marga, yw, was there any other bug/patch that you want review on? (asking because some might be lost in email backlog from our side)
<pitti> seb128: sorry, missed your pings! doing now
<seb128> pitti, hey, danke!
<marga> seb128, I need to discuss the dropbear patch with vorlon
<marga> But I'm guessing I still need to wait a few hours for him to be around.
<seb128> yeah
<seb128> I will let non desktopish ones to Steve ;-)
<marga> Aside from that, I think I don't have anything else pending.
<seb128> ok, good
<lamont> seb128: "my version" is the current-n-correct file, not some patch applied to some randomly old file. :D
<lamont> seb128: my ppa has some bits sitting in it - though I suspect I'll have even-newer for raring
<lamont> seb128: so yes, the answer is we should have all of the entries in the file...
<seb128> lamont, hey
<seb128> lamont, well the only difference between "current-n-correct file" and "some randomly old file" is a one line ipv6 record ;-)
<seb128> lamont, your version also has some autotools noise, not sure how much the SRU team like that
<lamont> hrm
<seb128> lamont, I saw you uploaded those fix to Debian and to your ppa, any plan to deal with the SRUs for Ubuntu as well? ;-)
 * lamont was hoping to avoid learning the SRU process
<lamont> s/learning/being reminded about/
<seb128> lol
<seb128> lamont, the bug is SRU ready, you just need to get sources uploaded targetting the right series
<seb128> lamont, with the changelog having a reference to the launchpad bug, and without the autotools noise if possible
<lamont> ah, that's not so bad
<lamont> I think I might be talked into that
<lamont> is tomorrow soon enough? tuesdays tend to be crazy
<dholbach> seb128, jamespage: I'll do some more sponsoring tomorrow - now need to get some other things done first :)
<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: jamespage
<dholbach> and: we're at 31!
<marga> seb128, thanks again :)
<seb128> dholbach, great work!
<seb128> marga, yw ;-)
<seb128> lamont, yeah, no hurry, I was going to upload the version of the guy who took the time to contribute the debdiffs but as I said he didn't include your ipv6 extra entry ... anyway if you want to take care of it this week great, I will just get it off the sponsoring queue and assign to you ;-)
<lamont> sounds good
<rbasak> seb128, lamont: that was me. My understanding is that SRUs need to be minimal
<seb128> rbasak, hey, they do, but if the ipv6 entry (which is a one liner) is considered useful there is no reason to do 2 uploads for a 1 liner each, we can as well include both changes in that update
<rbasak> Sure, I understand. I suppose this comes down to my original philosophy that it barely matters anyway. bind will immediately bootstrap the ipv6 entry from any of the other addresses listed, so I saw the SRU as merely fixing the soon-to-be-broken entry rather than anything else
<seb128> rbasak, I think what you did is right, but if lamont (who is the bind maintainer) wants to include the ipv6 change as well I will not stop him
<lamont> rbasak: by your logic, we don't need to update the ipv4 address either - 1 time in 13 the startup will be delayed by a few seconds.  So yeah, fixed is better
<lamont> so yeah, keeping that file current is a good thing
 * jamespage gets the feeling he's now just following dholbach through bugs...
<Riddell> kirkland: anerd has binary files in the .orig.tar.gz, should I reject to let you fix that?
<jamespage> @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:
<tjaalton> doko: hey, so about llvm.. would it be possible to include a snapshot of the r600-branch just for mesa?
<tjaalton> doko: as a new package
<tjaalton> doko: upstream says the branch will stabilize tomorrow, since mesa 9.1 was branched last week
<kirkland> Riddell: sure, you bet
<kirkland> Riddell: sorry about that :-/
<mjt> hallyn: telling the truth, i didn't understand anything in your lxc reply... :)
<Riddell> kirkland: voila
<tomreyn> hi, according to apport i'm affected by https://bugs.launchpad.net/bugs/925545 but this bug is hidden. can you tell me whether there is a known workaround, though?
<ubottu> Error: ubuntu bug 925545 not found
<barry> seb128, stokachu shall i just sync python-tz now?
<hallyn> mjt: heh, sorry, rant :)
<jamespage> doko: did you see this? http://lists.debian.org/debian-java/2013/02/msg00005.html
<dholbach> highvoltage, stgraber: ready for in 45m? :)
<jbicha> cjwatson: could you add clutter-1.0, clutter-gst, clutter-gtk, cogl, gnome-bluetooth, gnome-icon-theme-symbolic, and vte3 to the ubuntu-desktop set?
<jbicha> I already sent https://lists.ubuntu.com/archives/devel-permissions/2013-January/000440.html for all but gnome-bluetooth
<stgraber> dholbach: yep
<dholbach> stgraber, greta
<dholbach> great
<kirkland> Riddell: can you give her another look?  cheers!
<Riddell> kirkland: accepted!
<kirkland> Riddell: cheers, bud, thanks
<smoser> cjwatson, ping
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1015339
<ubottu> Ubuntu bug 1015339 in linux (Ubuntu) "Missing kernel modules for Mellanox ConnectX HCA Ethernet " [Medium,Confirmed]
<cjwatson> smoser: yes?  I followed up this morning and made that bug not my problem :)
<smoser> there seem 2 issues there.  1 (as you stated) the network driver does not get into the initrd.gz.
<smoser> 2. the modules dont get auto-loaded
<smoser> i dont think this is "your problem"
<cjwatson> there was a horribly confused pile of stuff involving manually created initrds
<smoser> but can you verify for me, that they should "just get loaded"
<cjwatson> I decided it was unlikely to be diagnosable until we had something more sane
<smoser> if they're present, based on udev and pci-ids built in.
<cjwatson> smoser: that is generally up to the modalias tables in the kernel
<smoser> right
<cjwatson> smoser: if the ids are correct then they will be auto-loaded, yes
<cjwatson> and usually if they aren't then the driver won't bind to the device anyway
<smoser> k. so it would appear to me that those need updating also.
<smoser> in this case at least, manual 'modprobe' gets them functional.
<smoser> thanks, cjwatson . as you said "not your problem" :)
<cjwatson> there's a big list of ids in the driver; certainly possible it's missing one or two
<cjwatson> can't tell from the bug since it doesn't quote any ids
<cjwatson> and I would say that any id update should be regarded as a separate bug
<stokachu> barry: should i remove that MP since im going to do a sync ?
<barry> stokachu: probably not delete it.  what status options do you have?  (probably different than me since it's your mp)
<stokachu> barry: i got WIP, needs review and merged
<barry> stokachu: hmm
<barry> stokachu: yeah, i guess delete it then
<stokachu> ok
<ogra> hmm, so diggin into the udevd issues on the nexus7(i now end up with 26 daemons on boot), stracing shows that only two of them are actually active, the rest just sits and gives no output via strace
<Quintasan> \o
<cjwatson> tumbleweed: Your mk-sbuild change to improve naming of cross-building chroots doesn't align with what Adam committed to upstream sbuild; your version has an extra "-cross" in the output name.  Would you mind if I removed that extra "-cross", since it hasn't been uploaded yet anyway?
<cjwatson> I don't think it's necessary - SERIES-BUILD-HOST should be clear enough
<stokachu> barry: pad.lv/1116418
<stokachu> i did a brief explanation about most of it being in debian, and i didnt notice any other Ubuntu specific changes
<barry> stokachu: looks good, thanks.  i'll do the sync momentarily
<stokachu> barry: awesome! :D
<stokachu> barry: since its a request sync do i get any credit for it? (mainly for when i apply for core-dev)
<barry> stokachu: if i run syncpackage correctly, you should ;)
<stokachu> lol ok cool, thanks man for your help
<barry> stokachu: thanks for working so hard on this package.  it's always fun when you think you've got an easy one and it turns out to be "interesting" :)
<stokachu> barry: yea no kidding, i was like hmm python-tz should be easy its just timezones :X
<cjwatson> pitti: Do you think we're good to go with language-pack-* for precise-updates?
<marga> slangasek, I'm hoping you'll be around soon.
<marga> slangasek, I'd like to discuss the fix for https://bugs.launchpad.net/ubuntu/+source/dropbear/+bug/834174
<ubottu> Ubuntu bug 834174 in dropbear (Ubuntu Quantal) "cannot login via ssh when using dropbear in initramfs" [Undecided,New]
<slangasek> marga: hey there
<slangasek> marga: otp, but I have a couple spare brain cycles
 * marga tries to expand "otp"
<slangasek> "on the phone" :-)
<marga> Anyway, the thing is, do you want me to prepare a new upload without the "echo 'passwd: compat'" line? Or do you want a completely different patch?
<slangasek> marga: I think it needs to be changed to be "echo 'passwd: files'".
<marga> Alright.  Next question, what version should this package be? Because the one with the bad patch is in precise-updates
<slangasek> marga: the current hook is buggy if plymouth isn't already pulled into the initramfs
<ogra> slangasek, oh its not "out to pee" ? and i was wondering about the weak blatter of all our managers :P
<slangasek> hmm?  how did it get into precise-updates?
<marga> oh, maybe I'm wrong
<marga> I thought I had had this sponsored
<slangasek> marga: I was reviewing it prior to accepting it into the archive
<slangasek> marga: sponsorship just gets you to the queue, then you have to pass the SRU team gauntlet ;)
<marga> ah, precise-proposed, not updates
<marga> I always mix them, sorry.
<slangasek> and I was the SRU gauntlet here
<marga> alright.
<marga> So, same version number or different?
<slangasek> same
<marga> ok.  Will have it there for you tomorrow.
<marga> (with chekcing that it works and that)
<slangasek> sounds good, thanks!
<pitti> cjwatson: yes, from my side
<cjwatson> pitti: excellent, I'll get going on that then
<xnox> slangasek: marga: don't we need an upload into raring to diverge with "s/compat/files"
<xnox> ?
<slangasek> xnox, marga: yes, this should also get fixed in raring - or at least have a bug opened against dropbear in Debian about the use of 'compat' being buggy
<cjwatson> pitti: I can get the list easily enough; we just hand an enormous list to sru-release, right?
<pitti> cjwatson: I usually use sru-release -p language-pack-
<pitti> cjwatson: (--pattern)
<pitti> cjwatson: http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/doc/operator-guide.txt
<pitti> cjwatson: "Releasing -proposed packages to -updates
<cjwatson> oho
<infinity> ev: *poke*... whoopsie that builds? :)
<ev> oh yeah
<ev> on it now
<pitti> cjwatson: yeah, documentation -- scary, isn't it?
<infinity> ev: Thanks.
<ev> infinity: done
<arges> is there anyway pad.lv/1052038, can be sponsored, then SRUed for Precise? thanks
<infinity> Laney: Not that I disagree that C++ symbols files are a pain, but why not just feed all the maliit-framework build logs to pkgkde-symbolshelper batchpatch, and be done with it, instead of dropping the symbols file entirely?
<Laney> infinity: I tried, but the tool kept refusing to apply patches and also applied some in a way that broke other arches. So in the end I saw red.
<Laney> Hopefully I have enough state to file bugs
<Laney> s/refusing to apply/ignoring/, perhaps
<infinity> Laney: Sounds like you were trying to apply each arch individually.
<infinity> Laney: Hence "batchpatch".  If you take -0ubuntu1, grab ALL the build logs, and feed them all in at once, it tends to DTRT.
<Laney> I was doing that - that was when it didn't apply all of the hunks and still FTBFSed
<ev> ughhhhhhh
<infinity> Hrm.  Weird.
<Laney> then I tried some other permutations and that was when it undid some other correct arch annotations
<Laney> which I agree is because I was using it wrong at that point
<infinity> ev: I've heard good things about test building. :)
<ev> I did! (just not in raring)
<ev> fixing, throwing it at sbuild, shouting angry things, etc
<infinity> Heh.
<smoser> cjwatson, can i make the installer load modules via the kernel cmdline ?
<smoser> ie, as if they were in /conf/modules or something.
<cjwatson> smoser: I don't think s
<cjwatson> o
<infinity> smoser: There's a general assumption that udev actually works correctly these days.  How is this failing you?
<infinity> smoser: (You can blacklist modules from the commandline, but not the other way around)
<smoser> infinity, its failing by design on this issue.
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1115710
<ubottu> Ubuntu bug 1115710 in MAAS "Mellanox mlx4_en network driver is not automatically loaded" [Critical,Triaged]
<smoser> infinity, its not loaded here becaujes the thing that gets automatically loaded is mlx4_core , not mlx4_en .
<smoser> that is how it is designed by upsream as ethernet or infiniband usage is somewhat "configruration"
<cjwatson> eh, if something isn't autoloaded by design then the design is wrong
<infinity> smoser: Yeah, uhm.  Fix the kernel bug?
<cjwatson> there are several other modules like this that we've dealt with in various ways
<cjwatson> unfortunately I don't currently remember their names ...
<smoser> its not necessarily a kernel bug.
<infinity> smoser: This will be just as broken on the installed system as in an installer initrd, so I don't see how it's not a bug.
<smoser> correct. and the user will configure the device to act as infiniband or as ethernet
<infinity> smoser: (Unless we're to assume this driver is a unique snowflake that needs to be manually loaded on installed systems too, which pretty much anyone will tell you is exactly how this isn't supposed to work)
<cjwatson> there are ways to deal with this kind of thing in installer code - but we haven't had to add any new examples of those in years and I don't want to do so ever again
<smoser> so it wont "just work" because you codn't know which "just work" is right.
<cjwatson> you *could* have a udev rule that interrogates the device for whether it's in ethernet or infiniband mode and loads the right other module
<cjwatson> but if udev can do that, so can the kernel
<infinity> Exactly.
<cjwatson> and either is more appropriate than adding configuration to the initramfs or to the installed system
<smoser> i'm in agreement with that.
<cjwatson> hardware upstreams are generally terrible at this kind of thing; there is no reason you should trust their design decisions implicitly
<smoser> but as it is here, upstream kernel isn't going to magically load, and just saying "make the ethernet driver load" is not the right solution either.
<cjwatson> Linux has plenty of history with overriding foolish decisions made by hardware vendors
<infinity> Dear god, you referenced a 211 page PDF in the bug.
<smoser> well, search for mlx4_en in it, infinity
<infinity> smoser: Last I checked, we build those kernels, we don't trust upstreams or mainline blindly.
<cjwatson> smoser: fixing the driver isn't necessarily that hard; if it's important, find a kernel team victim to help.  This shouldn't be unfamiliar territory for our kernel team.
<cjwatson> It's the sort of thing we do.
<infinity> smoser: The other curious question is if all the drivers can be loaded together.
<smb> says the one defining the SEP
<smoser> well, i did find one. its just not as simple as we'd like.
<smoser> infinity, i'm not sure. i wondered that too.
<infinity> smoser: What happens if one modprobes mlx4_ib mlx4_en and mlx4_fc?
<smoser> but i dont know why youd' have your softwar stack have configuration for whic hone to load if they loaded at the same time with no fallout.
<cjwatson> smb: Well, yes :-)  But it's simple truth that you guys have done this kind of thing before
<infinity> smoser: If it's a tiny waste of RAM, but they all load and the "right" one works, the simple solution could be to just build it statically.
<cjwatson> And fixing it in the installer is definitely the wrong place
<infinity> smoser: If they all refuse to bind except the "right" one, that's a simple udev rule (or a kernel fix).
<cjwatson> smoser: Don't assume that the driver authors had the same priorities as we do
<cjwatson> They might have thought that saving a tiny bit of kernel memory was more important than anything else
<infinity> mlx4_core
<infinity> Handles low-level functions like device initiali
<infinity> zation and firmware commands processing. Also
<infinity> controls resource allocation so th
<infinity> at the InfiniBand and Ethernet
<smb> cjwatson, Some kind but not really assuming "cannot be hard" without knowing the hw design which sometimes is hard
<infinity> functions can share the device
<smoser> cjwatson, alright. i'll try to figure that out.
<infinity> without interferin
<infinity> g with each other.
<infinity> Okay, ignore the bad line breaks.  But this doc implies that the driver is designed specifically to "do it all at once".
<smb> infinity, But I would think the same. That in theory the ports can be mixed, so could be both modules needed
<cjwatson> smb: It's an Ubuntu design principle to automatically probe hardware, and if the probing is possible in userspace then it's just as possible in kernelspace
<infinity> So, the simple first-try workaround is a udev rule that loads all the sub-modules when core is loaded.
<cjwatson> And (at its crudest) a bunch of "load this other module" calls is AIUI quite doable in the kernel
<cjwatson> Not saying that's necessarily the best option
<infinity> cjwatson: I could see one argument for keeping it a udev rule, which is just that some people may care deeply about upstream's attempt to save 25kB of kernel memory. :P
<cjwatson> Sure
<infinity> But, yeah.  First pass should just be "load everything and see".
<arges> jdstrand: ping
<infinity> And the docs here imply that should work.
<jdstrand> arges: hey
<arges> jdstrand: hey I see you uploaded for pad.lv/1052038, did precise also get uploaded as well?
<stokachu> arges: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=ecrypt
<smoser> infinity, cjwatson what you. testing to see if they seem to live together.
<stokachu> if thats the correct one it just needs sru
<infinity> smoser: If "load everything" works, a udev rule to do the same it almost certainly your path of least resistance.
<infinity> s/it/is/
<smoser> yep
<smb> infinity, Could even be a modprobe.conf thing. There is something about softdep
<cjwatson> Let's not add to modprobe.conf
<cjwatson> I have a feeling that is somewhat painful with d-i
<cjwatson> udev is probably better for this kind of thing
<infinity> d-i's initrd has a properly populated /etc/modprobe.d, I believe.
<smb> ok, no strong preference there
<infinity> But it's more about where you're shipping that file, and if it's there at build time. :P
<jdstrand> arges: yes - https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=ecryptfs-utils
<infinity> (Which is true of the udev rule too)
<stokachu> jdstrand: could we get that one approved?
<stokachu> so sru can take a look at it
<infinity> stokachu: Hrm?
<stokachu> infinity: hai!
<infinity> stokachu: How does Jamie factor into this?
<jdstrand> stokachu: ubuntu-sru needs to look at it (I am not on that team)
<infinity> I think I may have intentionally not accepted it while the bug was in flux.
<stokachu> ok
<jdstrand> (besides I did the sponsored upload, so someone else would need to do the approval anyway)
<arges> infinity: the fix should be settled now
<infinity> I'll look at it in a sec.
<arges> thanks
<infinity> arges: Yeah, I see that.
<stokachu> the bug still has sponsors subscribed to it
<infinity> (Don't expect it to make .2, unless you make a really good case for it, it'll probably stay in -proposed until after 12.04.2 release)
<infinity> But that gives you plenty of time to test very thoroughly. :P
<tyhicks> Hmm... I think arges did need it in 12.04.2
<arges> let me check
<cjwatson> I thought I'd asked what else you guys needed in .2 a while back :-(
<infinity> I can certainly see an argument for it being in .2 but, then again, I can see an argument for it being in .0, which it clearly wasn't. :P
<arges> so whats the ETA then if not in .2?
<stokachu> cjwatson: i think we just glanced over this one
<infinity> Anyhow.  I'll quickly review and accept, you can argue promotion after.
<arges> thanks
<cjwatson> Any reason it has to be tied to a particular release?
<infinity> arges: If it passes all verification, etc, and we don't intentionally target it for .2, it would hit -updates right after release.
<infinity> arges: If there's no reason it MUST be on installation media, that's perfectly fine.  If the old version can cause such horrific problems that we don't want it on an ISO, speak up.
<arges> infinity: ok this should work, I don't think it is necessary to be on media.I'll make sure
<cjwatson> pitti: language packs copied
<cjwatson> that should make sru-report run rather more quickly ...
<stokachu> infinity: thanks for looking at it so quick
<arges> infinity: indeed. thanks,
<cjwatson> (well, after the removal pass, which I'll take care of once the report lists them)
<smoser> what package would i put such a udev rule in? infinity ?
<infinity> smoser: If the goal is for this to be in d-i images, and every base system, it would probably have to be in udev itself, not some leaf package.
<smoser> thats what i thought too
<infinity> smoser: That said, after testing the udev rules option, the proper solution is probably in the kernel, as Colin argues.
<infinity> smoser: One could add an "auto_load=[yes,no]" option to the _core module, defaulting to "yes" in our kernels, so users who really want to old behaviour can change the module load parameters, but the default Just Works.
<smoser> infinity, so.. the ude rule.
<smoser> DRIVER=="mlx4_core", RUN+="/sbin/modprobe -bv mlx4_en", RUN+="/sbin/modprobe -bv mlx4_ib"
<infinity> smoser: Was the -v just for testing?
<smoser> no.
<smoser> becausae i didn't test :)
<smoser> i just ocpied from entry in /lib/udev/rules.d/80-drivers.rules
<infinity> Oh, -bv seems to be the standard in other rules.  I guess for logging.
<infinity> smoser: Anyhow, I'm no udev wizard, but if that works, it seems plausibly correct. :P
<smoser> right. you're in the same place as me then
<infinity> smoser: Testing on actual hardware would be sane.
<smoser> i seem to be somewhat limited in access to such.
<infinity> I'm assuming from agy's input on the bug that we have this hardware in the DC somewhere?
<infinity> Surely, you can get a sysadmin to help.
<infinity> (If you intend to SRU this back to precise, you'll need some hardware access to verify anyway)
<siretart> infinity: did you observer run-time errors, or are you "just" concerned about the build logs?
<siretart> -r
<infinity> siretart: There's no just about it, it's broken if anything actually calls into that.
<infinity> siretart: (In Ubuntu, we hard fail on implicit pointer conversions on 64-bit arches, so it's also a build failure, but the root cause is the implicit declaration, which is entirely a real problem here when you're calling into something that doesn't exist in the code you link to)
<siretart> I guess it's a missing #include. the three functions refer to the audioconvert API, which we do have in libavcodec
<infinity> siretart: A missing include of what?  I couldn't find those functions referenced in /usr/include at all.
<infinity> siretart: Which is why I pinged you instead of just fixing it.
<siretart> avcodec/audioconvert.h
<siretart> HA, that's a private, non-installed header. fun
<infinity> Ah-ha.  There you go.
<siretart> yeah, that's upstream (ab)using private headers. bad upstream
<infinity> So, you can either tell them to stop that, or include those prototypes in the handbrake source as a stub.
<infinity> Linking against private symbols is generally considered a Bad Thing, but whatever. :P
<infinity> Most of ffmpeg/libav scares me enough as it is, I can't see how this would make it worse.
<mlankhorst> ... famous last words
<siretart> thanks for notifing me about this. it seems that handbrake upstream is also hanging around in #libav-devel, where I'm trying to clarify what we can do about this.
<cyphermox> @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: cyphermox
<siretart> infinity: okay, the situation is this: the audioconvert API was work in progress, never made public, never finished, and is scheduled for removal for the next libav release
<infinity> siretart: Thanks for looking into it.
<siretart> infinity: yet, handbrake is still using it. which is bad
<infinity> siretart: Ahh, so handbrake just needs to be fixed to stop using it. :P
<siretart> infinity: the replacement for this is libavresample, which is already part of libav 9, which I really would like to see in raring but am desperatly seeking for help to fix the remaining packages. (but that's another story)
<siretart> infinity: it seems that handbrake has already been ported to libavresample in git, but there is no release for that yet.
<infinity> siretart: Okay.  So, the way forward is new libav, and git pulls to handbrake?
<siretart> infinity: yes
<siretart> btw, help is desperately needed at https://launchpad.net/~motumedia/+archive/libav9-raring/ - I've added all relevant links to the PPA description
<siretart> otherwise we'll have to defer for raring+1, which would be really, really sad :(
<infinity> siretart: Are those 7 open FTBFS bugs the entirety of what needs fixing?
<siretart> infinity: AFAIUI, the raring release process requires all FTBFS in https://launchpad.net/~motumedia/+archive/libav9-raring/+packages to be fixed. if we can shortcut this, I'm all for it :-)
<siretart> afk (dinner)
<infinity> siretart: I'd certainly prefer they all be fixed, yes.  That's a bit longer than the 7 bugs filed. :P
<infinity> siretart: Probably entirely doable, though.
<tumbleweed> cjwatson: not at all, please do so
<siretart> infinity: some of the packages seem rather abandoned upstream. i'd suggest to just phase out such packages
<cjwatson> tumbleweed: OK, done, thanks.  I didn't bother with a changelog entry since this is all new since the last upload
<cjwatson> Unable to obtain lock  held by laney@bazaar.launchpad.net on taotie (process #13112), acquired 483 hours, 50 minutes ago.
<cjwatson> Laney: ^- I figured it was OK to break that on ubuntu-dev-tools :-)
<cjwatson> Probably isn't actually an epic 20-day commit
<tumbleweed> heh
<infinity> siretart: If you want to "phase them out", get them removed from Debian.
<infinity> siretart: But I'm betting most of the porting is fairly trivial, and I'm not a fan of shafting users.
<robru> barry, ping
<smoser> infinity, smb would using MODALIAS be any better or worse than udev rule ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/286977
<ubottu> Ubuntu bug 286977 in linux (Ubuntu) "ipmi_devintf needs a MODALIAS of platform:ipmi_si" [Undecided,Fix released]
<slangasek> for anything that /can/ be expressed as a modalias, you should be using a modalias and not a udev rule
<barry> robru: pong
<smoser> slangasek, bug 1115710
<ubottu> bug 1115710 in MAAS "Mellanox mlx4_en network driver is not automatically loaded" [Critical,Triaged] https://launchpad.net/bugs/1115710
<smoser> forgive ignorance, is that something that could be done as modalias?
<infinity> smoser: That seems like a plausible solution to the problem.
<infinity> smoser: Patch the kernel and find out? :P
<slangasek> smoser: do you have a more precise pointer to the rationale for not autoloading the module, than a 212 page driver user manual?
<slangasek> smoser: ah, I see your comment 9 explains what you meant, ignore me
<smoser> slangasek, "upstream does not do it, and smoser is largely ignorant about this hardware"
<slangasek> so the one problem is that you can only load one module per device, AIUI
<slangasek> so if you have to pick between autoloading the ethernet module, and autoloading the infiniband module, then what?
<smoser> slangasek, that seems like it was invalid logic
<slangasek> what was?
<smoser> at least  at the moment we're under hte impression that we can load both at the same time.
<smoser> and at the expense of wasting kernel memory :)
<slangasek> sure, you can load them but you can't make the kernel /autoload/ them via modalias
<smoser> ah.
<slangasek> unless you have two different device identifiers that you can associate each driver with
<slangasek> still, rather than a udev rule, I would use a modprobe rule
<smoser> slangasek, any reason why?
<slangasek> because udev isn't really meant to be used that way, and I'm not sure it'll work
<slangasek> sometimes the reentrancy of udev is suspect
<smoser> slangasek, what package would you suggest this rule to be delivered in ?
<slangasek> /etc/modprobe.d/alsa-base.conf shows the kind of thing you want
<slangasek> smoser: er, what package delivers the driver?
<smoser> linux
<slangasek> hmm
<slangasek> there isn't really a common package for the kernel, then
<slangasek> is there any runtime package associated with these drivers?  Probably not?
<slangasek> if not, then I'd say use the kmod package for it
<smoser> no.
<smoser> and then that should get packaged all the way into installer initramfs and any other initramfs , right?
<siretart> infinity: yes, that's my plan, but surely not before wheezy release, which will not happen before raring's feature freeze
<infinity> siretart: Which is your plan?  Removing all the packages that don't build with the new libav? :/
<infinity> siretart: See above, re: shafting users.  If the porting is trivial, we should JFDI.
<infinity> siretart: (We don't remove everything that fails to build with a new GCC even if upstream isn't fixing it, this should be no different)
<siretart> infinity: most of them should be rather easy to port. there are some harder ones, which I've bugged upstream about, and from a few others, upstream seesm to be defact dead (e.g., dvbcut)
<siretart> infinity: packages that don't build with newer gcc does not hinder gcc from passing britney. unlike what she would do with libav9
<infinity> smoser: If it's in kmod (or module-init-tools, in older releases), it'll make it into initrds and d-i and such, yes.
<infinity> siretart: No, but it still makes all those packages RC-buggy.  The fact that britney can't detect that is a process flaw, not a free pass. :P
<smoser> ok. so now i'm being dense again.
<smoser> install mlx4_core /sbin/modprobe --ignore-install mlx4_en; /sbin/modprobe --ignore-install mlx4_ib
<smoser> that line causes recursion
<siretart> infinity: ;-)
<smoser> ok. here, this seems right now:
<smoser> softdep mlx4_core post: mlx4_en mlx4_ib
<smoser> slangasek, ^ that make sense ?
<tjaalton> bdmurray: hey, could you accept the precise-proposed upload as well for bug 1095052?
<ubottu> bug 1095052 in gnutls26 (Ubuntu Precise) "Client certificate authentication fails" [Medium,In progress] https://launchpad.net/bugs/1095052
<bdmurray> tjaalton: I wasn't sure about that with the point release being imminent
<bdmurray> infinity: ?
<cjwatson> bdmurray,tjaalton: I'd prefer that to wait until after 12.04.2
<tjaalton> cjwatson: ok
<Laney> cjwatson: hah, no idea how that happened
<slangasek> smoser: I've never seen/used softdep before; I was thinking of this: install mlx4_core /sbin/modprobe --ignore-install mlx4_core; /sbin/modprobe mlx4_en; /sbin/modprobe mlx4_ib
<dobey> slangasek: hey, got a second? just wondering if this dependency makes sense to you: https://code.launchpad.net/~dobey/software-center/oc-lesser/+merge/146749
#ubuntu-devel 2013-02-06
<slangasek> dobey: that looks like it would DTRT
<nik90> Is the right place to ask python related questions?
<nik90> this*
<nik90> nvr mind I will come later :)
<smoser> slangasek, the issue with your suggested 'install' is that modprobe of mlx4_en triggers recursion
<smoser> as it depends on mlx4_core
<smoser> ok... so i tested, and your way does not seem to cause recursion . do you have a preference on which way that is done?
<slangasek> smoser: I don't have a preference, I just don't know anything about the 'softdep' so don't know how "standard" it is
<smoser> slangasek, well, it documented in natty modprobe.conf
<slangasek> then I guess you're ok :)
<infinity> smoser: Oh, if you plan to upload module-init-tools/kmod for this, mind if you toss the kmod patch to me to upload?  I'm trying to keep TIL on it, so I can watch for merges. :P
<infinity> And it's getting irritating to find a bug to fix to steal it back every time someone else uploads it...
<smoser> infinity, https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710
<smoser> i think we're ready for "propose for merging" if you are ok to look
<infinity> smoser: Shiny.  I'd love it if someone could do a by-hand test of that on real hardware to see if it actually DTRT, mind you.
<smoser> me too.
<smoser> i'll see what i can do about hat.
<smoser> EntropyWorks, lifeless ^
<infinity> smoser: Would be nice if they could test it with both module-init-tools in precise and kmod in raring.  I make no guarantees that kmod actually honors softdep correctly.
<infinity> (Though it's meant to...)
<smoser> either of you able to do that for me? basically we want to boot a system , disable whatever hacks you have inside it that are loading mlx4_en, and then add the /etc/modprobe.d/mlx4.conf file that you see http://bazaar.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/revision/11 and reboot.
<smoser> infinity, i can verify that it honors it.
<smoser> i've tested 'modprobe mlx4_core' with those in place
<smoser> and seen the _en and _ib get loaded.
<smoser> on raring.
<smoser> but i cannot attest that they actually load and function if the hardware is present
<lifeless> smoser: EntropyWorks: - will see what we can do
<smoser> lifeless, thanks. update/comment at https://bugs.launchpad.net/maas/+bug/1115710
<ubottu> Ubuntu bug 1115710 in MAAS "Mellanox mlx4_en network driver is not automatically loaded" [Critical,Triaged]
<Niraj_>  Hi can anybody tell me, as a beginner to ubuntu dev, where can I find issues to fix?
<scientes> how can i debug plymouth without changing my kernel cmdline?
<scientes> i'd really like to be connected to it in gdb during bootup
<scientes> oh looks like xorg problem nvm
<scientes> but probably stilla bug i n plymouth
<Ramsrambo> I am running Quantal 12.10 I need libcstdc++ lib for installing lotus Symphony where do I get this from?
<scientes> Ramsrambo, probably libstdc++-dev
<scientes> * libstdc++6-dev
<scientes> but you may need another version
<Ramsrambo> but the IBM installation manual says libcstdc++
<scientes> wait libstdc++6-4.7-dev
<scientes> thats the same thing
<scientes> basically you just need to install build-essential
<scientes> apt-get install build-essential
<Ramsrambo> I hope so let me install that lib thru synaptic and see if I can install this lotus
<Ramsrambo> just hang on I will give the feed back
<Ramsrambo> essential not able to locate ?
<scientes> build-essential
<Ramsrambo> that was installed already
<scientes> may need old libstdc++5 then
<Ramsrambo> so go to synaptic and install this ?
<scientes> you need the -dev version
<scientes> probably
<scientes> but yeah install that
<Ramsrambo> I hv synaptic installed already
<scientes> apt-get install libstdc++5
<Ramsrambo> I installled the old libstdc++
<Ramsrambo> when I click on the .deb file it goes to software centre
<scientes> Ramsrambo, this doesn't belong in #ubuntu-devel
<Ramsrambo> and gives a error that dependency is not satisfiable libnotify
<scientes> yeah its using the old libnotify1
<scientes> (like firefox did a few months ago)
<Ramsrambo> that is right libnotify1
<Ramsrambo> >=0.4.4
<scientes> packages.debian.org/libnotify1
<scientes> * packages.ubuntu.com/libnotify1
<Ramsrambo> so I cannot install then
<scientes> you can
<scientes> you just have to pull from old version of ubuntu
<Ramsrambo> maybe on the old lib will do ??
<Ramsrambo> How do I do that ?
<scientes> i just told you packages.ubuntu.com/libnotify
<scientes> i just told you packages.ubuntu.com/libnotify1
<Ramsrambo> yeah! after installing libnotify1 it started installing
<Ramsrambo> I cannot see any progress at all in software centre ! not sure what is going on
<kees> hallyn: so... CAP_TO_MASK only seems valid for __u32 caps...
<kees> hallyn: and is 7b9a7ec565505699f503b4fcf61500dceb36e744 valid then?
<cyphermox> @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:
<didrocks> @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: didrocks
<kees> hallyn: unping; I see now how CAP_TO_INDEX works with CAP_TO_MASK :)
<pitti> Good morning
<didrocks> pitti: do you mind marking as merged the 3 following branches:
<didrocks> https://code.launchpad.net/~dobey/ubuntu/quantal/tomboy/no-more-u1/+merge/146674
<didrocks> hhttps://code.launchpad.net/~dobey/ubuntu/precise/tomboy/no-more-u1/+merge/146675
<didrocks> https://code.launchpad.net/~dobey/ubuntu/oneiric/tomboy/no-more-u1/+merge/146676
<pitti> didrocks: done
<didrocks> pitti: thanks :)
<dholbach> good morning
<didrocks> hey dholbach
<dholbach> hey didrocks
<Whoopie> cyphermox: Hi, just saw the network-manager upload and the enabling of connectivity check. You need libsoup build dependency so that it's correctly enabled.
<Whoopie> cyphermox: oh sorry, it's already there.
<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: didrocks, dholbach
<didrocks> @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
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<vibhav> Hey, is somebody aquinted with autopkgtests?
<didrocks> dholbach: short day (2h30 of sponsoring), but look at the ML, tomorrow is Qt5 sponsoring for me
<vibhav> I wanted to know whether one must test all packages for a test case
<vibhav> I was creating test cases for libestr
<vibhav> (http://developer.ubuntu.com/packaging/html/auto-pkg-test.html)
<dholbach> vibhav, you might want to ask in #ubuntu-quality - but if the test case works for you as described in the packaging guide, things should be all right
<vibhav> dholbach: Actually, I dont have time to test all functions. Would it be fine to test some functions only? (Of course they can be extended later)
<dholbach> some tests are better than no tests
<vibhav> Indeed.
<vibhav> Anyways, Ill try to do my best
<dholbach> great!
<dholbach> pitti, jibel: ^ :)
<pitti> vibhav: indeed, and the first test usually covers a lot more implicit stuff (loading library, etc.) than it might seem
<vibhav> pitti: thanks
<jibel> vibhav, it's perfectly fine to start with a small set of tests and increase the coverage afterwards when you have time
<caribou> Q: what is required to get a newly available Debian/Sid package synchronized in the Raring archive ?
<vibhav> jibel: So basically, I only have to check if function work correctly (return 1 or 0, etc), right?
<pitti> caribou: which package?
<caribou> pitti: makedumpfile & kdump-tools
<caribou> pitti: they're not available yet, they were just uploaded last night
<caribou> pitti: but since the freeze is getting near, I'm inquiring ahead just to know
<pitti> caribou: they are both unmodified, so we can just sync them
<tjaalton> doko_: ping re: llvm-snapshot
<pitti> caribou: once you see the new version on https://launchpad.net/debian/+source/makedumpfile/+changelog , feel free to prod me
<caribou> pitti: true, matter of fact, the Debian modification that I made is specific to a requirement I have for an Ubuntu blueprint
<caribou> pitti: ok, will do. This is regarding the email I sent to ev (you were CC) yesterday
<jibel> vibhav, very basically yes :) actually your test script will verify that the systems functions as expected, as for example checking the returncode of a function for different set of conditions
<dholbach> blueyed, Happy Birthday! :)
<caribou> pitti: a while back I asked about getting a package in main when its source is already in main
<caribou> pitti: you guys told me that it was only a matter of having a dependancy on this package from another package in Main
<caribou> pitti: does it applies to meta-packages as well ?
<pitti> caribou: in general as well, yes
<caribou> pitti: ok. kdump-tools will have a dependency from the linux-crashdump tool meta-package soon. we'll see
<caribou> pitti: thanks
<smb> pitti, Would it be enough to have only the source in main but not the binary (to be ok depending on the binary from meta)?
<cjwatson> caribou: makedumpfile and kdump-tools will be auto-synced without any human intervention
<caribou> cjwatson: thanks, good to know
<pitti> cjwatson: oh, we are still before DIF?
<caribou> cjwatson: just wanted to be sure as the freeze date is approaching
<cjwatson> the freeze is still eight days away
<pitti> smb: MIRs are source based, so promoting a binary is not a big process indeed
<cjwatson> and the auto-sync runs four times a day
<caribou> cjwatson: ok, I'll keep an eye on it
<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:
<dholbach> down to 29! (once http://reqorts.qa.ubuntu.com/reports/sponsoring/ updates)
<dholbach> yeehaw
<seb128> dholbach, \o/
<ion> down to 8841761993739701954543616000000 :-)
<dholbach> ion, what are you counting? :)
<ion> 29!
 * pitti hugs dholbach
 * dholbach hugs pitti back :)
<dholbach> ion, ok, I'm still a bit slow it seems ;-)
<ion> dholbach: That was just a stupid joke, ! is the factorial operator.
<dholbach> yeah, it took me 4 minutes to figure it out :)
 * dholbach hugs ion
 * ion hugs dholbach
<ev> cjwatson: thanks for recommending sbuild. I'm finding it a lot better than pbuilder.
<xnox> \o/
<cjwatson> ev: Great, glad you got over the initial hump
<vibhav> jibel: ping
<caribou> xnox: just saw your upload; I'll test it after lunch
<xnox> caribou: lvm2? it's not published yet.
<cjwatson> And won't be until after 12.04.2, unless there's a pressing urgency.
<caribou> xnox: true; I'll wait 'til the "please test" msg comes in
<xnox> caribou: ;-)))))
<vibhav> pitti: what does `pkg-config --cflags --libs glib-2.0` in the gcc flags mean? Is it important for me to include those flags? (Of course, I will need to replace glib-2.0 with something else)
<vibhav> pitti: wrt http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
<cjwatson> It's important to include those flags if you're building something that uses glib headers
<vibhav> cjwatson: I am writing autopkgtest cases for libestr. Do I need to replace glib-2.0 with libestr?"
<cjwatson> You probably need some kind of build flags for libestr.  I have no idea whether they'll involve pkg-config
<cjwatson> Check the library's documentation
<vibhav> ah, so it varies with libraries. Thanks cjwatson
<jibel> vibhav, libestr supports pkg-config, you can replace glib-2.0 by libestr on the line above
<jibel> vibhav, pkg-config --list-all will tell you which modules are found in the path
<vibhav> jibel: Hmm, will -lestr too work?
<vibhav> jibel: I already uploaded a debdiff at https://bugs.launchpad.net/ubuntu/+source/libestr/+bug/1117222
<ubottu> Ubuntu bug 1117222 in libestr (Ubuntu) "autopkgtest test cases for libestr" [Undecided,New]
<cjwatson> vibhav: with programs that ship pkg-config configuration, you always *can* compile/link without it but it's more correct to use pkg-config
<cjwatson> vibhav: it insulates you against changes
<vibhav> cjwatson: changes as in?
<cjwatson> to the way the library requires you to compile or link
<cjwatson> for example 'pkg-config --cflags gtk+-3.0' has a bunch of useful -I options that you really wouldn't want to write out by hand
<vibhav> ah, so it makes work easier
<vibhav> I will upload the correct debdiff then
<vibhav> thanks cjwatson
<jibel> vibhav, the test exit 1 but there is no output at all and don't know which function call failed.
<jibel> vibhav, you'd rather use one method/function per test, read http://xunitpatterns.com/Obscure%20Test.html#Eager%20Test for example
<tjaalton> are the builders having some issues, or why do they reject uploads with timestamps "too far in the future"?
<vibhav> jibel: So, shall I print "Failed"?
<cjwatson> tjaalton: Are the timestamps in the future?
<tjaalton> cjwatson: yes, some files of the packages, like lintian overrides and copyright
<tjaalton> hmm
<cjwatson> You'll probably find dpkg-source -x does that by default.
<cjwatson> I mean, errors.
<tjaalton> I'm building off a git branch, and for some reason some files under debian/ were touched
<cjwatson> Since you have to pass a special option to get tar not to issue a warning.
<vibhav> jibel: Also, would should I print in case of an error?
<cjwatson> tjaalton: I would suggest just fixing the timestamps :)
<tjaalton> cjwatson: well they are ok here, on my timezone
<cjwatson> You could ask #webops (internal) to check that the builder's time is OK, I suppose
<Quintasan> \o
<Quintasan> Laney: \o/ thanks for uploading maliit to Debian.
<jibel> vibhav, in case of error, you could print which function you're testing, the expected result and the actual result
<jibel> vibhav, keep in mind that human are reading log files, so the message in case of failure must be as clear as possible
<jibel> vibhav, I added a comment to the report
<ogra_> ogra@anubis:~$ pkexec gedit /etc/fstab
<ogra_> ** (gedit:8717): WARNING **: Befehlszeile Â»dbus-launch --autolaunch=806ff5b359b95482f2158d5e000009df --binary-syntax --close-stderrÂ« brach mit von Null verschiedenem Beenden-Status 1 ab: Autolaunch error: X11 initialization failed.\n
<ogra_> Anzeige kann nicht geÃ¶ffnet werden:
<ogra_> pitti, any idea why that happens ? ^^^^
<ogra_> pitti, i',m executing it from a gnome-terminal, i would assume i have access to the display (adding DISPLAY=:0 doesnt change a thing btw)
<pitti> ogra_: yes, pkexec doesn't pass through $DISPLAY by default
<ogra_> pitti, hmm, so how would i use it as gksu replacement as an enduser ?
<pitti> ogra_: you'd need to define a policy for gedit with the allow-gui attribute, like in /usr/share/polkit-1/actions/com.ubuntu.apport.policy
<ogra_> pitti, eeek, so that means we cant drop gksu ?
<pitti> ogra_: pkexec is not meant to be a general gksu replacement
<ogra_> sigh
<pitti> ogra_: but on the command line you can use sudo?
<ogra_> sure
<ogra_> but thats npot what users do or what our docs recommend ...
<ogra_> i would like to remove gksu from the images in raring
<pitti> I discussed that with David a while ago, and he wasn't fond of making pkexec a general user tool
<pitti> we could write some wrapper, of course, which passes through $DISPLAY
<ogra_> bah, but that forces us to ship two tools for similar purpose
<nik90> anybody here familiar with GTK  Treeview? I am trying to get the row index to the currently selected row (all in python)
<ogra_> a wrapper thats called gksu ;)
<ogra_> nik90, did you read the topic ... i guess a gtk channel would be better
<pitti> pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit
<pitti> ogra_: ^ that works, for example; but ugh :)
<nik90> oh thnx
<pitti> ogra_: well, it's still not "su"; users shold just call sudo from the CLI reall
<pitti> y
<pitti> ogra_: and from .desktop files we could use such a pkexecx wrapper?
<ogra_> pitti, generally thats not what supporters seem to recommend (or wikis and other docs)
<pitti> ogra_: well *shrug*, those need to be changed anyway, no?
<pitti> from gksu to pkexec or pkexecx or sudo
<ogra_> hmm, probably
<smartboyhw> dholbach, ping
<mpt> ev, http://store.steampowered.com/hwsurvey
<mpt> Expand the "OS version" row under "Windows and Mac"
<ev> excellent, thanks!
<ogra_> pfft, that wants to install flash on my nexus7
<ogra_> (if it only would !)
<ev> slangasek: a while back you had a better idea for measuring the health of the retracers than the current graphs of the average processing time and the success/failure rate
<ev> I don't suppose you remember what it was? :)
<ev> I can dig through all my notes if you can't
<smartboyhw> dholbach, help me to test https://code.launchpad.net/~smartboyhw/ubuntu/raring/calligra/2.6.0-0ubuntu1/+merge/146644 again, new things uploaded
<ev> mpt, bdmurray, pitti, slangasek: https://bugs.launchpad.net/errors/+bug/1117372
<ubottu> Error: ubuntu bug 1117372 not found
<ev> just in case you have interesting ideas
<hallyn> kees: ok, so to be sure, all is good? :)
<ion> (Re: the Steam stats) Over 1 percent total? Thatâs actually more than i expected. Thatâs, like, half a million users.
<ion> I wonder if it counts those who run it under Wine?
<smartboyhw> dholbach, DON'T. I've got a patch error now
<dholbach> smartboyhw, maybe you best point out in the merge proposal when it builds for you, etc
<dholbach> smartboyhw, then others can jump in any help too
<smartboyhw> dholbach, ok
<mlankhorst> for MRE sru's, do I still need a bug?
<Laney> yes
<mlankhorst> ah thought so, I originally cherry picked some fixes so my game would be stable in nouveau, now I can't get it to crash >:(
<Laney> MREs are only valid for changes in the new upstream release btw
<Laney> so your cherry-pick would be a normal SRU
<vibhav> jibel: Ive correct the debdiff
<vibhav> corrected*
<mlankhorst> Laney: well in this case I was part of upstream :-)
<jibel> vibhav, thanks, I'll review it in a bit.
 * vibhav hugs jibel 
<mlankhorst> Laney: hm what about things that have been sru'd already? like the patches to reduce size in mesa's renamed lts-quantal package
<ev> mpt: Whenever you have a free moment, do you think formatting the function column this way makes it easier to read: http://poppy-dev.local/ ? See http://errors.ubuntu.com for comparison.
<ev> I'm tempted to implement a custom ellipsize
<Laney> mlankhorst: what about them? I assume they went through SRU verification ~normally
<ev> that tries to take from the center of the call stack, rather than the right hand side
<Laney> mlankhorst: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<mlankhorst> yeah, I'll try piglit on it, but mesa is a pain point so the update wouldn't be falling under MRE I suppose :/
<tjaalton> mesa has a provisional mre
<Laney> MRE is for micro releases
<Laney> it's still valid to follow the normal SRU process for non-micro-release changes
<tjaalton> well mlankhorst is testing 9.0.2 for quantal
<mlankhorst> It'll have to be a hybrid then. MRE for the version bump, normal SRU for the patches cherry picked from mesa-lts-quantal in precise.
<Laney> sounds right
<Laney> you'll assume that upstream's fixes in the micro release are good and verify your cherry picks normally
<vibhav> Hmm, are libraries like libxdo (Which simulate X11 keyboard/mouse input) work with autopkgtest?
<vibhav> AFAIK, these tests will run on Launchpad Servers, which probably dont have GUIs
<mlankhorst> I don't want to assume, but looking  seems there have been no big regressions in mesa for raring, which is mostly identical to the version I want to upload. Only difference is a revert to wayland 0.95.
<Laney> assume means not having to manually verify each one - broad testing and running piglit is required as said on the page I linked you to
<mlankhorst> yeah
<mlankhorst> but it's on top of that :-)
<Laney> and then explicitly verifying anyting extra, yeah
<hrw> can someone help me with debconfing package? http://tygrysek.juszkiewicz.com.pl/~hrw/tmp/chromium-mali-opengles_0.45-0ubuntu1.dsc - builds fine but does not display license ;(
<geser> hrw: did you forget to update the preinst or is the checking the msttcorefonts license intended?
<hrw> ops
<geser> you've updated the license variable but not the configuration space
<hrw> ysp
<hrw> rebuildng
<hrw> yay! works now
<hrw> previous version was based on nexus7 firmware and I had other bugs
<bdmurray> mterry: might you have a look at bug 1110585?
<hrw> so my first multiverse package works. but I wonder about pushing it into archive
<ubottu> bug 1110585 in update-manager (Ubuntu) "update-manager in raring opens debconf prompts in embedded terminal instead of using gnome frontend like it should" [High,Confirmed] https://launchpad.net/bugs/1110585
<sveinse> I've written a local-premount script for an embedded device running precise. In this script I mount some filesystems, do something and umount them afterwards. However the script is failing because umount reports Device or resource busy on the device I just mounted. Why could that be?
<hallyn> I'm confused.  3.8.0-4.9~userns1 <= 3.8.0-0.4-userns1  ?
<mterry> bdmurray, huh
<sveinse> hallyn: http://www.debian.org/doc/manuals/maint-guide/first.en.html#namever
<tjaalton> cjwatson: so, didn't think to check that my machine had jumped forward a month after a hibernate cycle.. it caused the archive upload fail
<sveinse> hallyn: Your version statement is true. (Notice the tilde vs the dash)
<zaytsev> hi folks. i noticed base-files bump to 12.04.2, but can't find images on cdimage. the latest is still 12.04.1. any etas?
<infinity> hallyn: Having two dashes in the second version is reolcating what you believe is the "debian" and "upstream" versions.
<infinity> hallyn: And 3.8.0 is definitely << 3.8.0-0.4
<infinity> zaytsev: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-January/001009.html
<hrw> hallyn: two dashes are killer with debian versioning ;(
<hallyn> sveinse: i notice the tilde, but i would expect in 'dpkg --compare-version X~Y lt Y~Y' for the ~Y to be ignored
<dobey> is it just me, or did the libc 2.17 update break squid3? (i can't think of anything else it might be)
<infinity> dobey: I might need more to go on than that.
<hallyn> infinity: i guess
<hallyn> <blink>
<hallyn> all right, thanks all :)
<infinity> hallyn: The last dash is the one used for the Debian revision.
<dobey> infinity: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1111880
<ubottu> Error: ubuntu bug 1111880 not found
<hallyn> i see, so it was my fault at the *last* submission.  drat.
<zaytsev> infinity: thank you very much, this is what i was looking for, but failed to fine.
<dobey> infinity: also, there seems to be a squid3 in quantal-security/updates that is newer than what's in raring. not sure why there isn't a -1ubuntu2 in raring with the fix in that -1ubuntu1.1 security update
<zaytsev> s/fine/find/
<hallyn> infinity: good news, the cleanup patches for spice are on their way into debian archive.  should be able to sync soon
<dobey> infinity: but anyway, since the libc update, i've been seeing squid3 crashing while running tests in ubuntu-sso-client and ubuntuone-client (but we don't run those tests in the ubuntu builds, because they depend on the poorly maintained qt4reactor package which isn't in main)
<jdstrand> dobey: I'll update squid3
<infinity> dobey: Hey, I'm all for blaming glibc but, on the other hand, when only one package is exploding, I tend to blame that package. ;)
<dobey> jdstrand: thanks
<dobey> infinity: i'm not blaming glibc. but maybe it exposed a bug, which was working fine before the update
<dobey> infinity: but the stack trace is a bit suspiscious, too, given how short it is :)
<caribou> slangasek: ping
<infinity> dobey: Really short stack traces when you manage to segv libc aren't uncommon. :)
<infinity> dobey: (Usually due to doing something undefined, out of bounds, or just plain silly)
<dobey> infinity: well, usually, crashes in strcmp are because someone passed in a NULL and the trace is several function calls deep. but maybe ncsa_auth is just a really small file too
<dobey> but i would also expect passing NULL to strcmp to crash in the older glibc, as it's done many times before :)
<infinity> You'd generally expect, yes.
<infinity> Anyhow, if Jamie updates and it and it still explodes, I'll pass the buck to him.
<dobey> heh
<slangasek> caribou: in a meeting, but pong
<caribou> slangasek: no rush, just disregard my last comment about install with secureboot/UEFI
<caribou> slangasek: in the LP bug#1100247
<caribou> slangasek: tl;dr : I used the +mac Quantal iso to install which doesn't have the ./efi bits
<slangasek> caribou: hah, indeed it doesn't
<caribou> slangasek: I'll update the bug & mark it invalid once I've completed the install
<slangasek> caribou: oh, you mean /all/ this testing was with the mac image?
<slangasek> or the original problem is just no longer reproducible?
<caribou> slangasek: yep
<slangasek> man
<slangasek> I need to be more careful about asking people for image URLs :)
<caribou> slangasek: all the testing with the mac, which is why it didn't see it on startup
<slangasek> thanks for following up
<slangasek> also, I need to kill the mac image with fire, but ENOTIME :/
<caribou> slangasek: I _really_ wanted to nail this one down
<caribou> slangasek: I don't even know why this image made it to my HDD to start with
<hrw> how does repo for package is selected? I mean universe/multiverse - it is on server only or in package somehow?
<xnox> hrw: as in, what adds univer/multiverse to apt config - or how does apt chooses which package version out of multiple available to install?
<xnox> (your question is a bit ambigious to me)
<hrw> xnox: no. I have package which is multiverse material - should I mark it somehow in debian/* or is it repo admin job?
<ogra_> hrw, by the archive admins iirc ...
<xnox> hrw: you will upload it into ubuntu and it will end up in the New queue. Archive Admins will accept and assign it to multiverse. Make sure your debian/copyright is correct.
<hrw> xnox: thanks
<hrw> ogra_: thx as well ;)
<infinity> hrw: You can totally mark it multiverse in the source package.
<ogra_> but that wont auto-move it there, will it ?
<infinity> hrw: "Section: multiverse/whatever" instead of "Section: whatever"
<hrw> thx
<infinity> ogra_: No, but it'll land in the right place in the queue, so I don't have to override it.
<xnox> infinity: ha =)))) *cheat*
<ogra_> good to know
<infinity> ogra_: Overrides and packages should match, they just often don't because we're importing from Debian and have different overrides.
<infinity> ogra_: But in Debian, dinstall actually yells at you every time you upload something where debian/control doesn't match the overrides.
<ogra_> ah
<infinity> (The reason you tend to want them to match is so people making custom archives without overrides get the same Sources.gz/Packages.gz as the primary archive)
<ogra_> i'll try to develop a habit for that in plain ubuntu packages then
<infinity> hrw: If it's something you'd be eventually targetting for Debian, then "Section: non-free/whatever" also works fine, and our queues will s/non-free/multiverse/
<hrw> infinity: due to non-mainline kernel it will probably not land in Debian but adapted
<hrw> ok, so whole NEW queue is mine :D
<vibhav> Does Launchpad allow root privilages on its build servers?
<vibhav> Oops, wrong channel
<sladen> vibhav: errm, for the sys-ops that run the buildds.  What are you trying to do?
<marga> slangasek, you around?
<marga> slangasek, I just sent an update to the dropbear bug.  Please let me know if you have any comments.
<vibhav> sladen: autopkgtest case which uses Xvfb, which requires root
<vibhav> sladen: Or, is there any way to run Xvfb without root?
<slangasek> marga: around-ish, fighting kernel bugs; I'll have a look at the bug report in a bit, thanks
<slangasek> vibhav: why would you think Xvfb requires root?
<vibhav> slangasek: It does not seem to work with xdotool then
<marga> slangasek, no rush, don't worry.  Turns out it was a cosmetic issue not a real one.
<vibhav> slangasek: I am writing a autopkgtest for libxdo. Since launchpad build servers dont have X11, I need Xvfb. According to http://mojo.codehaus.org/selenium-maven-plugin/examples/headless-with-xvfb.html , Xvfb cannot functino correctly without root
<slangasek> vibhav: yeah, that page is nonsense.  Have a look at any of the packages that build-depend on xvfb for example usage
<vibhav> Wait, it works without root
<vibhav> slangasek: Yes, that page is nonsense. Thanks!
 * vibhav slaps forhead
<sladen> vibhav: /usr/bin/Xvfb :42  works for me  ... but it seems you just discovered that
<vibhav> sladen: Yes, I am a fool
<xnox> vibhav: you are not a fool. you simply learned something new today ;-) which is good. all of us should be learning something new every day.
<vibhav> xnox: :)
<vibhav> xnox: Not only something new, something very important too :)
<slangasek> marga: hey, followed up to the report; there is still a bug here
<slangasek> marga: it's fine if you don't consider it high enough priority for an SRU, but plymouth is not always used in the initramfs so dropbear should not be relying on plymouth doing the file copy
<doko> infinity, will you update the cross-toolchain-base packages?
<infinity> doko: Yeap.  Was looking at that during the meeting.
<vibhav> I cant find anything in the archives, does the repositories still have xlib?
<infinity> vibhav: libx11, you mean?
<vibhav> infinity: ah, found it
<vibhav> I was searching for xlib and got libxcb
<infinity> vibhav: Unlike many RPM distros, where library packages have bizarre names based on upstream project names, ours are always (except when someone messes up, *cough*) named after the SONAME, which should make them rather obvious to find.
<vibhav> ah
<infinity> I kinda wish I could convince Fedora to do the same.  Having to remember that your headers for libx11.so.6 are in xlib-dev is pretty unintuitive, IMO.
<vibhav> Indeed. It is rather confusing
<infinity> (Especially since there's no consistent naming scheme, and you get to hunt every time)
<vibhav> yep
<marga> slangasek, yes, I understand there's a bug, but it's unlikely to get triggered, since you need to not use plymouth nor mountall...
<marga> slangasek, about the nsswitch file, there is also a different file being generated by these same tools.
<marga> Much more complex than just the passwd line from dropbear
<leighman> any one have any idea about https://launchpadlibrarian.net/130549294/buildlog_ubuntu-quantal-amd64.evolution-data-server_3.6.2-0ubuntu0.2~ppa1_FAILEDTOBUILD.txt.gz - it is just the quantal-updates branch with a single patch applied
<dobey> infinity, jdstrand: ah, looks like squid3 failed to build. i wonder if it's the same issue causing my crash :)
<geser> leighman: try a give-back (as it built on i386); might be due your gnome-online-accounts was not build for amd64 at the time evolution-data-server was tried
<infinity> dobey: It's just because it builds with -Werror
<leighman> geser: yeh, okay, cool
<dobey> infinity: right. but -Werror wasn't added in that change. i guess a new gcc might have added a new warning though, or the change in libc caused the warning to happen, since it's an (apparently new) attribute on the setuid method
<dobey> anyway
<seb128> ScottK, hey, https://launchpad.net/ubuntu/+source/pyside/1.1.2-1 is depwaiting for over 3 months, is that something on your todolist?
<ScottK> seb128: No.  It's non-trivial to solve and nothing I care about really needs pyside.
<seb128> ScottK, well, you are the one who synced it according the raring-changes... should we revert to the previous version then?
<xnox> seb128: we removed binaries from raring. maybe it will be fixed in debian at one point.
<ScottK> seb128: No.  The version before was even more broken.
<xnox> seb128: there is nothing to revert to =)))))
<ScottK> Make xnox fix it.  He loves that kind of pain.
<seb128> ScottK, xnox: ok, thanks ... some of the #ps guys need it, I will point them to xnox
<ScottK> seb128: If they think they want pyside, I think you should convince them they want python-qt4 instead.  AFAIK, pyside is no longer developed upstream (or not much).  Python-qt4 already supports Qt5.
<seb128> ScottK, ok
<seb128> ScottK, I don't think they "want" anything, they are trying to package something that uses pyside
<ScottK> I see.
<jdstrand> dobey: I have the fix, I just got pulled into a meeting
<jdstrand> (and infinity ^)
<jdstrand> (I even filed 1117517 for myself)
<marga> slangasek: sorry, had to reboot my vps.  If you said anything after I last spoke, I lost it :-/
<dobey> jdstrand: great. thanks again
<slangasek> marga: mountall doesn't put anything at all in the initramfs.  This is specific to whether plymouth is in the initramfs, which is *not* the default in Ubuntu
<slangasek> marga: plymouth is only in the initramfs if cryptsetup is installed
<marga> slangasek: ah, right.  That was what I was testing, because otherwise is really hard to get the boot image to stop and wait for connections
<marga> In any case, you still want the patch for the correct copying?
 * xnox thought we always have plymouth in initramfs. I guess I simply always have cryptsetup.....
<hallyn> mjt: I'm not yet seeing new spice in debian experimental - is there some place we can watch it roll through the queue?
<slangasek> marga: I'm indifferent, I'm just pointing out that it's still a real bug with real consequences - but if you know that *you* always have plymouth in the initramfs, thus making it a low priority for you, then I wouldn't bother
<marga> slangasek: ok, I already closed the bug on our side.  But given that I spent easily 20 hours on this bug, I'm willing to send a new diff so that it doesn't all go to waste
<slangasek> marga: up to you :)
<slangasek> marga: if we do go ahead with it for precise, please also send the fix to the Debian maintainer
<bdmurray> what are the status.ubuntu.com templates written in?
<bdmurray> or maybe for is the right question
<mterry> If I'm trying to reliably reproduce a debconf question (any question, testing frontend support in update-manager), is there an easy way to force a package to ask?
<janimo> mterry, dpkg-reconfigure packagename or you mean something more specific?
<mterry> janimo, I want to put my system in a state so that when I run update-manager, I get asked a debconf question
<janimo> mterry, for ex lightdm
<mterry> janimo, lightdm asks a debconf question?  hmm, maybe if I install an old one.  The other one I knew about was libc6, but that was so intertwined with my system I had problems installing an old one
<janimo> mterry, I don't know then. I thought such questions are asked when a package is installed/upgraded or forcibly reconfigured not on any run of update-manager
<mterry> ah, lightdm doesn't
<mterry> janimo, if update-manager upgrades a package it may have to ask
<janimo> mterry, ok it did for me as I have gdm installed, so a question pops up about picking the default login manager
<mterry> janimo, ah... interesting
<dobey> anyone have any idea why "python-all (>= 2.6.6-3) |
<dobey> err
<dobey> anyone have any idea why "python-all (>= 2.6.6-3) | python-support" as a Build-Depends for a package building on Lucid, would fail in a PPA? it builds fine locally, and have built other packages with the same dependency before :-/
<dobey> problem is: python-all(inst 2.6.5-0ubuntu1 ! >= wanted 2.6.6-3)|python-support(missing)
<Elbrus> dobey: I don't think | is allowed or at least working in a buildd
<Elbrus> but maybe I am wrong
 * Elbrus means as a build-depends obviously, not as a depends
<Laney> kirkland asked that exact question in #-motu yesterday - it's https://launchpad.net/bugs/594916
<ubottu> Ubuntu bug 594916 in launchpad-buildd "buildd does not install alternate dependency for versioned ORed build-dependencies" [Low,Triaged]
<Laney> summary: alternate build-depends don't really work
<Laney> dobey: ^
<kirkland> Laney: yeah, I still think that's strange :-)
<Laney> bug's a bug
<dobey> kirkland: indeed. what's even more strange, is that i've used it quite often, and am only hitting an issue now :(
<Laney> perhaps you had python-support installed before
<infinity> dobey: It's never worked on the buildds (or, rather, that bug has always existed).
<adam_g> is my assumption correct that a test suite's attempt to use udev_monitor_new_from_netlink() via pyudev or similar will fail on a buildd and FTBFS?
<dobey> infinity: i'm pretty sure i would have noticed before now if it's never worked at all
<infinity> dobey: I'm pretty sure, as the person who wrote the bug, that it's never worked. Just sayin'.
<dobey> infinity: considering i have had lots of packages building in multiple PPAs that depend on that exact thing :)
<infinity> dobey: Alternate deps work, but not in that one corner case.
<kirkland> Laney: dobey: infinity: now, if I were to put "python-support | python-all (>= 2.6.6-3)" as a build-depends, would that cause a package currently in main to trigger a mismatch (since python-support is in universe)?
<kirkland> even though python-all is in main and satisfies the build dep?
<dobey> kirkland: it doesn't matter if it's in main or not. first satisfied would be used; at least in a PPA, maybe not for actual archive buidls
<infinity> kirkland: If your package is in main, that'll work splendidly.  If your package is in universe, that'll probably pull in python-support, even though you didn't need it.
<dobey> builds
<infinity> dobey: PPA and archive resolution is exactly the same.
<infinity> (Well, except that PPAs have all components enabled and such)
<kirkland> infinity: interesting, let me give that a go...
<infinity> kirkland: The whole reason we support alternate deps at all is because of the main/universe split.
<infinity> kirkland / dobey: Worth noting that Debian doesn't support alternate build-deps, period, so it's generally best practice to not bother.
<infinity> (You can have them in your Build-dep line for ease of backporters, but the Debian archive buildds will only ever take the first option, by design)
<kirkland> infinity: ack,thanks
<infinity> Because non-deterministic build-deps were considered a bad idea.
<kirkland> ^ boring
<dobey> well, if there was some way to do if $DISTRO_VERSION; elsif... in build-deps, that would be nice too. but having to do a control.in and write a bunch of sed commands into a makefile to do it, sucks
<infinity> dobey: Or, you could not expect the same source package to build on 5 releases.
<infinity> I do believe that's the root of most people's concern here. :P
<dobey> when i don't have to support 5 different versions of ubuntu, then we can discuss that :)
<Laney> VCS are quite good at this kind of thing
<infinity> dobey: What package do you have that has to support multiple versions from the same source package?
<infinity> dobey: Note I said "has to" not, "you want to".
<dobey> infinity: all of ubuntu one
<infinity> (But yes, VCSes are really good at this whole "having a delta and merging branches" thing, as Laney points out)
<dobey> VCSes don't know anything about dependencies or ubuntu releases.
<infinity> Uhm.
<infinity> You have a branch per ubuntu release.  They have subtly different debian/control.  You merge your upstream into each branch.  Done.
<infinity> Pretty sure your VCS doesn't need to know what a raring ringtail is to get that job done.
<dobey> yeah, i don't want to have to manage N copies of the same code just to build it on N versions of ubuntu
<dobey> and i'm no going to
<dobey> having to maintain N debian/ directories is pain
<infinity> You could be wrong with the "and I'm not going to" assertion.
<infinity> I'm down with your "I don't want to", but such is life.
#ubuntu-devel 2013-02-07
<smoser> infinity, https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/+merge/146760
<smoser> that is tested now.
<smoser> and i'd like it pulled.
<smoser> tested on actual hardware (that takes 3 minutes to boot)
<smoser> now i go to bed.
<infinity> smoser: Heh.  Cool.  Thanks.
<pitti> Good morning
<vibhav> hey pitti
<vibhav> pitti: I was writing autopkgtest cases for ncurses. I have manageed to cover all library functoins relating to output, any idea how do I test input functions? Is there any idea except redirecting input?
<vibhav> s/manageed/managed/ , s/functoins/functions/
<pitti> vibhav: hey
<pitti> vibhav: oh, very good! That almost sounds like upstream tests already
<pitti> vibhav: does upstream have a test suite which we could run in autopkgtest?
<vibhav> Taking a look
<pitti> vibhav: I haven't tried this, but perhaps one could run it under Xvfb and inject keypresses through xtest
<vibhav> pitti: ah, yes there are test suites
<vibhav> pitti: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/ncurses/raring/files/head:/test/
<pitti> vibhav: if they run during the build, then the "detailled" functionality doesn't need to be tested again in autopkgtest
<pitti> vibhav: for autopkgtest it's more important to test "is the library working at all", and "can I build something against it which works", such as most of our compile/link/run tests that we have in glib, gtk, and many others
<vibhav> pitti: So Ill assert() some basic functions for autopkgtest. Thaat should do it, right?
<pitti> vibhav: it seems the upstream tests don't run during package build; fixing that would also help, but if they are too broken then maybe they can at least serve as an inspiration on how to run input tests
<vibhav> Basically, the aim is to see if the headers and pkg-config and alright, they shouldnt be that comprehensive too
<pitti> vibhav: or maybe a subset of them will work
<pitti> vibhav: right; that's what I meant with compile/link/run tests
<pitti> vibhav: such as http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/glib2.0/raring/view/head:/debian/tests/build
<vibhav> pitti: I was following this :)
<infinity> smoser: So, I'm going to go with sotfdep in raring, since it works right with kmod, and it feels like the Right Way to do this.  For the SRUs, of course, we can go the more hackish route.
<infinity> smoser: I'm also not entirely convinced we actually care about loading the _ib driver, and might only care about _en...
<alexlist> siretart: do you have a minute for dput stuff?
<alexlist> siretart: any reason not to add the upstream git to https://launchpad.net/dput/trunk ?
<vibhav> pitti: As the tests will be compiled by gcc, should I use function attributes too? (They _might_ optimize the tests)
<pitti> vibhav: do you think that will make them less likely to succeed? I. e. cover more corner cases?
<vibhav> pitti: nope
<vibhav> All functions are pure, so __attribute__((pure)) and stuff
<pitti> I don't know what this is doing, but it doesn't seem to me that this is something we ought to put into a simple compile test?
<vibhav> ah, ok
<vibhav> pitti: If you have some time could you have a look at http://paste.ubuntu.com/1619001/ ? If it is right I will make a merge proposal for it.
<pitti> vibhav: what does wgetch() read from?
<pitti> vibhav: i. e. how do you emulate pressing 'a' there?
<pitti> vibhav: can you just call this with "echo a | ./test-curses ?
<dholbach> good morning
<dholbach> does anyone have any comments/input on the last comment in bug 1113529?
<ubottu> bug 1113529 in Ubuntu "[sponsor request]add into archive for UbuntuKylin" [Wishlist,Confirmed] https://launchpad.net/bugs/1113529
<vibhav> pitti: Yes, it works!
 * vibhav cheers
<pitti> vibhav: with echo, or does that function not actually read from the console?
<vibhav> pitti: wgetch() also works without echo (when I enter myself)
<vibhav> So, yes it works from the console
<pitti> vibhav: ok, so the test would use echo, so that it runs noninteractively
<pitti> vibhav: congrats!
<vibhav> pitti: thanks
<vibhav> Okay, Ill branch ncurses and request a merge
<vibhav> pitti: Any other suggesstions?
<pitti> vibhav: if you take glib's debian/tests/ script as an example, please add -Wall -Werror for extra pickiness
<pitti> vibhav: I did that for a few packages already, but not for glib yet
<vibhav> pitti: Should I add "ncurses" to depends in debian/tests/control?
<pitti> vibhav: I rather think you'd need a -dev, and build-essential?
<vibhav> pitti: Okay so, will it be libncurses5-dev, build-essential, pkg-config
<pitti> that ought to suffice
<vibhav> perfect
<jibel> vibhav, hey, I reviewed your patch, the test script is fine, but the test of es_str2cstr fails
<vibhav> jibel: Thans for the notice, I will hve a look soon
<vibhav> pitti: done :) https://code.launchpad.net/~vibhavp/ubuntu/raring/ncurses/add-autopkgtest/+merge/147038
<vibhav> jibel: Uploaded correct diff
<jibel> vibhav, it passes, congrats!
<vibhav> This is a good day
<vibhav> Everything is working perfectly.
<vibhav> pitti: I need to go, please inform if there are any more chaanges to be done.
<tjaalton> is there a way to stop sbuild from generating ddeb's? reprepro can't import them..
<geser> IIRC pkg-create-dbgsym has a config file to disable it (or delete the package completely from your sbuild)
<tjaalton> thanks, I'll check it out
<tjaalton> meh, I'll just add an exit 0 to the script..
<Laney> I just sed -i '/\.ddeb/d' foo.changes if I want to reprepro it
<tjaalton> that would be one way, though I can't see much use for local ddebs anyway :)
<cassidy|Nexus> hey everyone
<cassidy|Nexus> I was told yo come
<cassidy|Nexus> *to come here from #ubuntu-on-air
<Laney> depends how often you like to debug stuff
<tjaalton> the ones I build usually have -dbg anyway
<cassidy|Nexus> Is anyone working on a service like Contractor or Android Intents?
<cassidy|Nexus> http://www.omgubuntu.co.uk/2011/03/contractor-brings-seamless-file-sharing-between-apps-to-the-linux-desktop
<tjaalton> like most of pkg-xorg stuff
<cassidy|Nexus> or would it be possible for some collaboration with elementary on Contractor? :)
<cjwatson> tjaalton: Not sure why you wouldn't just remove pkg-create-dbgsym from the relevant build chroot
<cjwatson> tjaalton: It's not build-essential - it's just that mk-sbuild puts it there by default for Ubuntu
<RAOF> cassidy|Nexus: That looks like it's trivially implementable by the existing .desktop file infrastructure?
<tjaalton> cjwatson: right, best to just remove it then
<cassidy|Nexus> RAOF, not using anything that exists so far. It's not just telling an app to open a fine, but acting upon the data in a way that makes sense in that context
<cassidy|Nexus> *file
<RAOF> cassidy|Nexus: You're basically asking for mime-type handlers; these exist - it's what populates âopen withâ
<RAOF> So it's not entirely implemented, but you can pretty easily implement it on top of what we've got.
<cassidy|Nexus> RAOF, but I wouldn't want to share a picture to a gallery app, I'd want to share it to my email app or gwibber
<cassidy|Nexus> RAOF, it's a very distinct use case
<RAOF> So annotate the desktop files.
<RAOF> It's not *that* distinct a use case âº
<cassidy|Nexus> RAOF, I encourage you to chat with the devs in #elementary-dev about in.
<cassidy|Nexus> *it
<RAOF> Not that I think this is a bad idea at all, just that I don't see why it requires extra infrastructure.
<cassidy|Nexus> I'm not a desktop dev myself so I'm probably not doing a very good job of explaining it. :-P
<cassidy|Nexus> RAOF, but iirc there was a very specific reason it wasn't done through .desktops... :-/
<cassidy|Nexus> RAOF, either way, it'd be sweet to work together on a standard implementation. I think part of that is how apps that can share data display the sharing menu and whatnot.
<cassidy|Nexus> RAOF, some interesting use cases we've already seen devs using it for are like highlighting text in a code editor and then sharing it to pastebin with a single click, uploading videos to online services, and even providing a simple plugin architecture for the file manager (for things like archiving files)
<cassidy|Nexus> There's even a "set as wallpaper" contract so any app that is sharing image data can share to that and it sets it as the wallpaper. lot's of really interesting things.
<RAOF> Yeah, it's kinda interesting.
<mjt> hallyn: re spice in experimental - i pushed it just to the repository, not yet to any archive.  I had no chance to reply to your email or to do anything else with spice, was very busy a few last days.  As for uploading, I hoped that Liang will reply -- it looks like he will not...
<lifeless> barry: do you know whats up with https://bugs.launchpad.net/subunit/+bug/1025392 ?
<ubottu> Ubuntu bug 1025392 in subunit "FTBFS with Python 3.3: tests fail" [High,Triaged]
<pitti> vibhav: splendid, thanks! I'm in a train, too little bw to sponsor; but please feel free to add me as a reviewer, then I'll get mail for it
 * xnox recalls fixing something like that
<xnox> lifeless: i had a branch for that indeed.
<xnox> lifeless: https://code.launchpad.net/~xnox/subunit/hash-ordering/+merge/131732 ?!
<xnox> lifeless: jelmer did upload this to experimental https://bazaar.launchpad.net/~ubuntu-branches/debian/experimental/subunit/experimental/revision/13#debian/patches/fix-ftbfs-python3.3.patch
<lifeless> xnox: the merge proposal for it got cancelled by you AFAICT ?
<lifeless> xnox: so was waiting for an updated version ...
<xnox> I think I did push an updated revision later.
<xnox> Also I uploaded twice into https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/subunit/raring-proposed
<xnox> (revisions 16 & 17)
<lifeless> xnox: [not to mention that the original change wasn't suitable for production use]
<xnox> lifeless: what do you mean by not suitable for production use?
 * xnox was just doing bulk porting to python3.
<xnox> You mean shebang changes?
<lifeless> xnox: I said it in the review; the code was correct, the issue was only in the test suite.
<lifeless> xnox: making the actual code slower to make tests pass is inappropriate
<xnox> ah, ok.
<lifeless> the serialiser is in the critical path for speed
<lifeless> its not as fast as it probably needs to be already, so I'm a tad sensitive.
<xnox> ok. I'll rework it. But i have a few urgent things to push out today.
<lifeless> no rush
<lifeless> I just released 0.0.10, which doesn't have that patch.
<lifeless> but fixes some more python 3 issues
<xnox> cool
<lifeless> (subtle ones that you can only detect with stuff running on stop of subunit :))
<mjt> when importing package from debian, should something be changed in d/control if the rest is okay?  Maybe, if the said pkg is maintained by other people, ubuntu maintainer should be added to Uploaders?  And, how about revision numbers?
<geser> mjt: if nothing needs changing (like an additional patch) the the package is taken from Debian as-is
<xnox> mjt: if you are uploading into ubuntu ahead of debian's -1 : version should be -0ubuntu1. And maintainer should be changed using update-maintainer utility from ubuntu-dev-tools (available in debian as well)
<xnox> mjt: and target raring
<mjt> ok, thanks!
<mjt> (i'm not uploading anything to ubuntu, i'm just making life for some ubuntu'ers easier :)
<xnox> =)
<hallyn> mjt: oh, ok, thanks
<hallyn> mjt: do you expect to push it to archive this week?  If not I'll go ahead and merge the current debian-experimental version with the cleanups on top
<hallyn> hm, the raring netboot image (which worked for me two weeks ago) is failing to boot
<barry> hi lifeless, xnox all sorted out?
<mjt> hallyn: i just replied to your email.  If Liang wont reply tomorrow I'll just push it
<hallyn> mjt: awesome, thanks, then i'll wait
<mjt> hallyn: together with the configure fix
<xnox> barry: yeah. mostly agreed what I should do next.
<barry> xnox: excellent!
<cjwatson> hallyn: failing how?
<cjwatson> hallyn: oh, yeah, I think I heard there was some syslinux breakage, could be that
<cjwatson> hallyn: it's been reported in Debian too ...
<cjwatson> oh my god, enormous thread on debian-ctte about it
<Laney> oh yes.
<cjwatson> well, I can cherry-pick the reported patches to d-i/debian-cd at least and see if they help
<hallyn> cjwatson: yeah, it's right at boot failing to find ldlinux32.c32
<hallyn> sounds like it's covered then, thanks :)
 * hallyn goes to look for that m-l
<hallyn> oh.  heh.
<seiflotfy> hey guys
<seiflotfy> mhall119: http://libqzeitgeist.geekyogre.com/ :D
<seiflotfy> booom
<mpt> Hey seiflotfy, long time no see
<seiflotfy> hey mpt
<seiflotfy> mpt: how are you
<seiflotfy> ?
<mpt> seiflotfy, splendid. Have you heard from Manish Sinha lately?
<seiflotfy> yeah, he was working on the activity log manager
<seiflotfy> he has exams atm
<seiflotfy> mpt i am willing to take a look after the weekend
<seiflotfy> i am busy releasing zeitgeist 1.0
<mpt> Ooh, congrats
<seiflotfy> thanks
<seiflotfy> much faster, directreading (no dbus roundtrips) and gobject introspection support
<mpt> Will that make the Dash faster? :-)
<seiflotfy> yep
<seiflotfy> much faster
<seiflotfy> dash is mostly slow due to ubuntu1 spamming it
<seiflotfy> mpt if you want to make it faster, just delete the DB and make it rebuild itself
<seiflotfy> :D
<seiflotfy> because old u1 entries kinda messed things up big time
<mpt> ooh, how do I do that
<seiflotfy> ok
<seiflotfy> first
<seiflotfy> in a temrinal
<seiflotfy> zeitgeist-daemon --replace
<seiflotfy> then kill it
<seiflotfy> the mv ~/mpt/.local/share/zeitgeist ~/mpt/.local/share/zeitgeist-backup
<seiflotfy> then in a terminal
<seiflotfy> zeitgeist-daemon --replace
<mpt> woo-hah
<mpt> Now it opens in less than two seconds!
<seiflotfy> mpt: its still busy
<seiflotfy> give it time
<seiflotfy> it gets quicker
<seiflotfy> :d
<seiflotfy> zeitgeist is busy building the index again
<seiflotfy> takes 60 seconds or so
<jpds> seiflotfy: http://zeitgeist-project.com/ - you need to update that logo.
<mpt> ok
<seiflotfy> jpds: i know, but i am lacking resources
<seiflotfy> right now we are 4 ppl doing the zeitgeist besides our real jobs
<seiflotfy> mpt: run zeitgeist in a terminal
<seiflotfy> zeitgeist-daemon --replace
<seiflotfy> then open the dash
<mpt> seiflotfy, it is
<seiflotfy> and show me the output on the terminal
<seiflotfy> mpt: ^
<mpt> Hm, the Terminal is stuck behind a HUD that won't close
<marga> tseliot, hey there, are you around?
<seiflotfy> oh man
<mpt> "Thanks HUD! ... Thud!"
<tseliot> marga: yep
<marga> tseliot, I work with Michael Wisheu, he sent you a mail regarding the regeneration of initramfs images in nvidia's postinst
<jpds> seiflotfy: http://www.canonical.com/sites/default/themes/canonical10/images/footer_logo.png
<seiflotfy> jpds: on it later today
<marga> tseliot, my idea was to add a low priority debconf question that asks if the user wants the current (default) behaviour, or wants all kernels
<tseliot> marga: right, I haven't replied to him yet
<marga> tseliot, if you think this approach is fine, I could prepare the patch for you.
<tseliot> marga: but given the headaches we've had with debconf in the past I'd rather not do that. Maybe it's simpler if I check the existence of a file in /etc such as /etc/dkms_build_all_kernels, or something like that
<marga> tseliot, hm, that had been my first thought, but it's rather ugly that you have to have the package there before installing the package
<marga> What were the debconf headaches of the past?
<tseliot> marga: some serious problems with the nvidia-common package causing problems during dist-upgrades, etc.
<marga> tseliot, hm, knowing what the problems actually were might be helpful in not falling into the same mistakes.
<xnox> what's the question here?
<tseliot> marga: and this has to work smoothly also with our drivers manager app, so we don't want users to have to answer questions during the installation
<marga> But, in any case, if you prefer dropping a file somewhere, I can try to find a place to drop a file and then send you the patch.
<marga> xnox, nvidia-current only regenerates the initramfs for the running kernel and the newest kernel.  This might be problematic in cases where the user wants to run an older kernel
<marga> So, we want to _optionally_ regenerate all images.
<mpt> seiflotfy, http://paste.ubuntu.com/1621263/
<seiflotfy> mpt now keep it running and open dash
<seiflotfy> then tell me what the terminal says
<tseliot> marga: so yes, advanced users (or maybe only developers) could do something like "touch /etc/dkms_build_all_kernels" and then install the package
<mpt> seiflotfy, no further output.
<marga> Alright.  I see this as less than optimal, because you need to do that before the package is installed.  And the package is installed at installation time in the machine.  It's easier to pre-seed than to pre-write a file.  But, we'll manage.
<seiflotfy> mpt: my bad
<seiflotfy> zeitgeist-daemon --replace --log-level=debug
<marga> Do you want me to send you the patch?
<tseliot> marga: or you can touch the file and do dpkg-reconfigure nvidia-310 (or whatever)
<tseliot> marga: aah, I see your problem
<seiflotfy> mpt: what does it spit
<tseliot> marga: patches are always welcome
<seiflotfy> mpt: ?
<mpt> seiflotfy, http://paste.ubuntu.com/1621279/
<seiflotfy> so when you open dash it does not contact zeitgeist :D
<seiflotfy> but the times are very fast
<seiflotfy> [15:45:11.377989 DEBUG] ext-fts.vala:186: Got 13[/398] results from indexer (in 0.229272 seconds) [15:45:11.378658 DEBUG] ext-fts.vala:186: Got 10[/54] results from indexer (in 0.083086 seconds) [15:45:11.713494 DEBUG] ext-fts.vala:186: Got 0[/0] results from indexer (in 0.017680 seconds) [15:45:17.236664 DEBUG] zeitgeist-daemon.vala:181: Zeitgeist.Daemon.find_events executed in 0.009232 seconds [15:45:17.240314 DEBUG] zeitgeist-daemon.vala:181: Zeitge
<seiflotfy> woops sorry
<seiflotfy> mpt: the first search is slow iwth 0.2 second
<seiflotfy> but then all under 0.1 seconds
<seiflotfy> do you notice a difference
<mpt> seiflotfy, yes. :-) It now has what, in the early days of Mozilla, we used to call "teh snappy"
<seiflotfy> my DB is HUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUGE
<seiflotfy> mpt: but with the next release it will be faster
<seiflotfy> :DS
<seiflotfy> http://seilo.geekyogre.com/2013/01/zeitgeist-1-0-almost-there-call-for-hackers/
<luist> hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories?
<dholbach> kirkland, intriguing changelog entry ;-)
<kirkland> dholbach: which one?
<stgraber>   * UNRELEASED
<stgraber> ^ that one :)
<dholbach> https://lists.ubuntu.com/archives/raring-changes/2013-February/005725.html
<dholbach> :)
<kirkland> wtf
<kirkland> dholbach: stgraber: thanks... let me see what went wrong with my release scripts....
<dholbach> don't worry - it might feed some rumour mill somewhere ;-)
<kirkland> dholbach: I'm your Huckleberry!
<mpt> seiflotfy, maybe the OS upgrade script should rebuild the zeitgeist database?
<mpt> seiflotfy, though I guess that doesn't really work if it's user-specific
<mpt> Maybe zeitgeist updates set a RebuildIfLastRebuildWasEarlierThan flag, and looks at it on each login
<mpt> or something
<seiflotfy> mpt: just delete all u1 entries
<seiflotfy> and things are back to normal
<seiflotfy> :P
<caribou> xnox: sorry to bother you with that, but do we have any idea of how long it can take for the lvm2 SRU to get to -proposed ?
<caribou> xnox: Bug #833368
<ubottu> bug 833368 in lvm2 (Ubuntu Precise) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [High,In progress] https://launchpad.net/bugs/833368
<kirkland> dholbach: stgraber: ah, I missed a debcommit in my upstream tree;  thanks;  I'll add a bzr stat check in my release scripts
<xnox> caribou: not until after 12.04.2 is released. If it's urgent to get into 12.04.2 (which I thought it isn't since clvm package is not on the server cds) you can raised it with cjwatson / release team
<caribou> xnox: ok, thanks for the info
<xnox> caribou: yeah, currently 12.04.2 is in preparation for candidate images.
<rbasak> I've got an FTBFS in a PPA builder that I can't reproduce using sbuild. I think it's because of an extra build-depend that's being pulled in for some reason, but I can't figure out why (ruby1.9.1 in addition to ruby1.8). Is there a way I can get sbuild to do exactly what the PPA builder is doing for build dependency resolution please? And oddly, the last build I did didn't change the build dependencies but worked.
 * rbasak is confused
<cjwatson> rbasak: what's the package?
<rbasak> cjwatson: I'm experimenting with puppet 3.1 out of debian git vcs
<rbasak> success: https://launchpadlibrarian.net/130544489/buildlog_ubuntu-raring-i386.puppet_3.1.0-0ubuntu1~ppa1_UPLOADING.txt.gz
<rbasak> failed: https://launchpad.net/~racb/+archive/experimental/+build/4279299
<rbasak> failed: https://launchpad.net/~racb/+archive/experimental/+build/4279299/+files/buildlog_ubuntu-raring-i386.puppet_3.1.0-0ubuntu1%7Eppa2_FAILEDTOBUILD.txt.gz
<cjwatson> rbasak: So two things: (a) --resolve-alternatives (generally makes sbuild operate more like the LP one) (b) since puppet is in main, configure your schroot to have only main sources
<cjwatson> Haven't analysed this particular case but that should bring it closer
<rbasak> OK, I'll try that, thanks. What confuses me is that two subsequent builds on the PPA failed, but I only changed control fields that shouldn't matter.
<rbasak> Sorry, that the first build on the PPA succeeded and the second failed
<cjwatson> Dunno, could be changes elsewhere in the archive
<rbasak> OK
<cjwatson> I'm partially guessing :)
<Riddell> tjaalton: ping
<rbasak> So removing !main didn't work (and then I noticed that the PPA FTBFS log has universe et al. enabled), and nor did --resolve-alternatives. I'll keep looking
<tjaalton> Riddell: pong
<Riddell> tjaalton: xfixes seems to cause breakage
<Riddell> http://paste.kde.org/666956/
<Riddell> tjaalton: sorry xinput rather
<Riddell> tjaalton: clashing variable name with xfixes
<tjaalton> huh
<tjaalton> ok then
<Riddell> tjaalton: is there an upstream to moan to?
<tjaalton> my bad, should've pushed it to the staging ppa..
<tjaalton> no, it's conflicting with our old implementation aiui
<tjaalton> which is shipped by the xserver
<Riddell> tjaalton: with an old xfixes?
<tjaalton> Riddell: right that's where it's from..
<tjaalton> Riddell: ok, I'll revert it from libxi for now
<Riddell> tjaalton: I'll also upload kde-workspace without the patch that uses xfixes for now since upstream is unsure if it's a good idea
<luist> hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories?
<tjaalton> Riddell: uploaded -0u2 which reverts the upstream code for now
<Riddell> thanks tjaalton
<Riddell> tjaalton: will you also file a bug upstream, or should I?
<tjaalton> Riddell: no upstream is fine, we'll be dropping our own implementation of pointer barrier events together with xserver 1.14 before feature freeze
<tjaalton> Riddell: so kde has added support for our own implementation of it (like unity) you'd need to port it
<tjaalton> +if
<Riddell> tjaalton: own implementation of what?
<tjaalton> Riddell: once the build works with -0u2 I'll upload -0u3 to canonical-x/x-staging ppa which restores the upstream stuff
<tjaalton> Riddell: pointer barrier events
<Riddell> tjaalton: when I tried kubuntu on a nexus recently I couldn't interact with plasma widgets or anything QML so we have something messed up
<tjaalton> no this is for dualhead, resistance for the pointer when crossing screen barriers
<tjaalton> so if you don't have versioned build-deps against our libxfixes then you're safe :)
<tjaalton> it's just that including both new and old headers cause issues, like you pointed out..
<smoser> infinity, ping.
<infinity> smoser: Pong, ish.
<smoser> just asking about 115710 (kmod mellanox)
<infinity> smoser: Yeah, I nick highlighted you overnight, I think.
<smoser> shoot.
<infinity> smoser: Started off by saying I thought softdep was the cleaner way to go in raring, there's no reason to make it be stuck with the same hack as older releases.
<smoser> infinity, i think the issue is present on raring also
<smoser> i can veryify that though.
<infinity> smoser: But then I got to wondering if we really need the automloading magic to load the _ib module too.  Is that a behaviour people will expect/want?
<smoser> the update-initramfs... i think thats where i was testing.
<infinity> smoser: It works fine in raring.
<smoser> really?
<infinity> Yeah.
<infinity> Given that kmod and module-init-tools share absolutely zero code, the behaviour changing isn't shocking.
<infinity> Not that m-i-t is "wrong" for noting the loop (mlx4_en depends on mlx4_core, after all).
<marga> tseliot, in the end, no changes will be needed.  There already is a flag in the update-initramfs.conf file that allows to regenerate for all kernels.
<marga> tseliot, thanks for your time :)
<tseliot> marga: you'll still have to rebuild the modules manually
<smoser> infinity, ok. so you're right. it seems cleaner with the post in raring.
<smoser> and i just tested no crying there.
<smoser> so lets do that.
<smoser> so, then, reguarding the _ib module...
<smoser> i just think if we believe that _en should be loaded, then why would we not load _ib ?
<infinity> Note that the _ib module hack doesn't actually work for you from initrds anyway, since infiniband modules aren't included in initrds by default.
<smoser> it seems arbitrary to decide that ethernet usage is expected but infiniband is not.
<smoser> (they get pulled in with the soft-dep)
<infinity> They sure don't.
<smoser> http://paste.ubuntu.com/1621558/
<infinity> Is that with the install or softdep setup?
<infinity> I didn't get that behaviour on either raring or precise when I tested.
<smoser> softdep
<infinity> And what release?
<smoser> i just re-built that initramfs with no soft-dep and its gone.
<smoser> that is raring, but i'm running quantal kernel
<smoser> because of hardware issues.
<infinity> Oh, confusing.
<smoser> well if you want to fix compiz so it doesn't hang after 3 minutes of use, i'd love to use a 3.8 kernel
<infinity> So, I intentionally deleted the _ib module while testing a different thing, let me restore that and see. :P
<infinity> But it also would pull in the whole _ib stack into the initrd too.
<smoser> it would, yes.
<smoser> is there a reason we wouldn't want that?
<smoser> i wondered about this too, and thought maybe we should not do _ib
<infinity> Well, I'm not sure how all of this is generally used, to be honest.
<smoser> but it just seems random to decide that "of course you want ethernet drivers for your hardware, but maybe not infiniband"
<infinity> Isn't infiniband something people have to consciously configure anyway?  We don't have any out-of-the-box It Just Works IB stuff, do we?
<smoser> "if you want infiniband, then manual action is required"
<smoser> i dont know.
<infinity> Yeah, me neither. :P
<smoser> infinity, well., you want to ditch the _ib ?
<infinity> smoser: I'm thinking no one will notice if we do.
<smoser> ok.
<smoser> so soft-dep for raring
<smoser> and no _ib loading
<infinity> smoser: And it gets rid of the minor initramfs-tools/modprobe interaction issue for the backport. :P
<smoser> ?
<infinity> Well, for precise, where the _ib module doesn't end up in the initrd, but then modprobe still tries to install it.
<infinity> Anyhow.  I think it's sane to keep it small, and _en is small.
<smoser> infinity, so what do you want from me?
<smoser> i'll change my non-raring branches
<smoser> and comment in the bug to this decision
<smoser> but you pick up raring ?
<infinity> smoser: Yeahp, that works for me.
<infinity> smoser: Well, if you want upload credit, you can give me a branch/diff for raring too.
<infinity> smoser: (My name doesn't need to be in the changelog to keep TIL for merges, I just need to sponsor it :P)
<smoser> i'l update raring
<smoser> infinity, ok. we're good at https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/+merge/146760
<seb128> marga, I rejected the g-c-c update for precise that I sponsored earlier this week, don't worry about it if you get a rejected email. I'm going to upload, I had to do a small update to update the version logo to stop saying 12.04.1 in preparation of 12.04.2
<siretart> alexlist: now I'm around. what's up about dput?
<dobey> seb128: hi there. what about https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600 ? slangasek said in IRC at least that my patch looked sane to him. :)
<ubottu> Ubuntu bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress]
<seb128> slangasek, ^ want to sponsor it? ;-)
<seb128> or I can dput but I will deny any responsability if it has issues ;-)
<siretart> alexlist:  oh, I see. it seems that I'm the 'owner' of that project. I don't even remember when I have touched that entry the last time
<siretart> any takers?
<Kano> hi, what tool is used to create the final ubuntu iso?
<luist> hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories?
<roadmr> luist: did you read https://help.ubuntu.com/community/LiveCDCustomization ?
<lifeless> barry: yeah thanks
<arges> infinity: hey. i'm looking at an eglibc issue. Is there a wiki on bisecting between svn commits? Make && make install looks dangerous
<xnox> arges: do that, but in an lxc container? =)
<arges> xnox: yea i'm doing this in a vm for sure
<arges> but last time I did it completely borked the system, and I couldn't even 'ls' anymore
<sarnold> vm with rollback :)
<xnox> arges: always install busybox-static ;-)
<sarnold> you might wish to glance over https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment and see if the uvt tool is something you'd like to steal :) I like using it, anyway..
<arges> sarnold: thanks i'll take a look
<arges> xnox: yea, that's not a bad idea. I'll put that in there too
<sarnold> uvt stop -rf virt-machine-name ; uvt start -v virt-machine-name -- and try again :)
<arges> sweet.
<siretart> I'm looking for the script/program that creates the Ubuntu server CDROM. can someone please point me to the right direction? I need to recreate it with less packages.
<stgraber> seems like it's a popular question lately ;)
<siretart> stgraber: oh, did I miss the answer?
<stgraber> short answer for the server CD is, it's not public
<cjwatson> eh, the server CD is practically all debian-cd
<stgraber> siretart: not today, no. Kano asked the same question a bit earlier on but nobody replied.
<stgraber> cjwatson: even with the new fancy livefs stuff?
<cjwatson> lp:ubuntu-cdimage + lp:~ubuntu-cdimage/debian-cd/ubuntu
<Kano> why not main?
<cjwatson> I think you might have to glue something in manually to call BuildLiveCD from livecd-rootfs - the glue in ubuntu-cdimage is "ssh to another server of the right architecture" in any event
<seb128> cjwatson, did you see my g-c-c 12.04 ping on -release earlier?
<cjwatson> Yeah, been on a call since, having a look
<cjwatson> I assume you've eyeballed the logo and I needn't bother :)
<seb128> cjwatson, ok, no hurry, you timeouted at some point so I wanted to make sure you got it
<seb128> cjwatson, I copied back the one we have in precise at release time
<seb128> had
<siretart> cjwatson: thanks a lot, I'll have a look at the scripts!
<bdmurray> hallyn: the qemu-kvm upload in the proposed queue for quantal does not have bug 1033727 in the changelog ... only a debian bug
<infinity> arges: make and make install from upstream glibc sources will land you in pain.
<ubottu> bug 1033727 in qemu-kvm (Ubuntu Quantal) "USB passthrough doesn't work anymore with qemu-kvm 1.1.1" [Medium,In progress] https://launchpad.net/bugs/1033727
<infinity> arges: Build the package, then apply your patch, make, and copy the one library/binary you're testing.
<infinity> arges: The re-make will be pretty quick cause, y'know, that's how make works.
<slangasek> seb128: feel free to dput and redirect the blame to me :-)
<hallyn> bdmurray: well <slap>
<seb128> slangasek, thanks ;-)
<arges> infinity: ok that sounds a  lot more sane
<cjwatson> grr, having serious network problems today
<cjwatson> seb	accepted now, thanks
<cjwatson> seb128: ^-
<seb128> cjwatson, thank you! ;-)
<hallyn> bdmurray: resubmitting
<infinity> arges: Out of curiosity, what's the bug you're hunting?
<Kano> cjwatson: can you update ntfs-3g to 2013 release because of w8?
<arges> infinity: bug 1109327
<ubottu> bug 1109327 in eglibc (Ubuntu Quantal) "who command gets "who: memory exhausted" for certain inputs" [Medium,In progress] https://launchpad.net/bugs/1109327
<infinity> arges: Oh right.  Well, tracing where it gets leaky and dies might be helpful, then you can biset a bit more fine-grained.
<arges> infinity: yea i've been gdbing it, it happens when asprintf returns an err
<infinity> arges: I assume this is a somehow broken/corrupt wtmp?
 * arges checks
<infinity> Well, random googling suggests this has been on-again/off-again through the ages (like, back to 1998 or more), and wiping wtmp, or even logging out and back in has "fixed" it for people.
<arges> infinity: yes afaik it was a validly created wtmp (i had to replace the hostnames)
<arges> infinity: the odd thing is that with this input it works with eglibc-2.16 and greater, but not 2.15
<infinity> arges: And if I tell you it works fine on precise for me...?
<arges> infinity: you typed 'who wtmp.clean'
<infinity> Yes...
<arges> at the end did you get 'who: memory exhausted'
<infinity> No.
<arges> precise amd64 ?
<infinity> Just tried amd64 and i386
<arges> i can reproduce this on my desktop/laptop/vms etc
<arges> i've reproduced this on raring install with eglibc-2.15 installed
<arges> amd or x86?
<infinity> Works here with libc6 2.15-0ubuntu10 and 2.15-0ubuntu10.4
<infinity> Intel CPU.
<infinity> Don't have any AMD kit handy.
<arges> yea i've tested on intel and was able to reproduce
<arges> hmm
 * ajmitch can reproduce on precise amd64
 * infinity blinks.
<infinity> Kernel?
<infinity> These are precise chroots on a raring kernel in my case.
<arges> 3.2.0-37, and raring 3.8
<arges> umm let me try in a chroot
<ajmitch> 3.5.0-22-generic for me, libc6 2.15-0ubuntu10.3
<arges> infinity: ok works fine in a precise chroot
<arges> for me
<infinity> Okay, that's what I was seeing, so that's comforting.
<infinity> But on a precise kernel with raring's glibc, it works?
<arges> infinity: yes this I've tested
<infinity> Or was that test on a raring kernel too? :P
<arges> i did it both ways
<arges> tested the raring/precise versions of the libraries both ways
<infinity> arges: I was about to say "works fine on Debian's 2.13 as well", but that's a kFreeBSD machine, not Linux.
<infinity> arges: So... One more "maybe the kernel matters" datapoint, I guess. :P
<arges> infinity: i can try testing that as well... i imagine this bisect will be slow and painful
<ajmitch> fwiw, I can reproduce on lucid amd64
<infinity> Yeah, pure precise reproduces it fine, but raring kernel fixes it.
<infinity> So.  I'm not sure what to make of that, if the inverse (precise kernel and raring glibc) also fixes it.
<arges> infinity: testing that now
<infinity> Uhm, this is absolutely corrupt.
<arges> infinity: precise userland / 3.8 kernel still fails
<infinity> Who has TTYs that are random unicode garbage?
<dobey> slangasek: thanks! (re: gnome-keyring)
<infinity> arges: precise userland and 3.8 kernel worked fine here...
<infinity> arges: Anyhow, seriously, have you looked at what it's failing ON?
<arges> non chroot?
<arges> yes I know the odd unicode char
<infinity> "Odd"?
<infinity> Where and how did they get that in there?
<infinity> stat("/dev/\260", 0x7fff42df8100)       = -1 ENOENT (No such file or directory)
<infinity> ^-- That's not a sane device node.
<arges> you could do something like: sudo sessreg -l ï¿½ -h "127.0.0.1" -a test
<arges> so should this fail and cause a memory exhausted error? though
<infinity> arges: The better question might be how are they getting those sessions, not why does who dislike them.
<infinity> arges: No, it probably shouldn't throw the error it does, but this could also be a big "who cares", when the real bug is that data being in wtmp in the first place.
<infinity> Waaaaaitaminute.
<infinity> I bet it doesn't fail in my chroot because of the locale.
<infinity> Or maybe not.
<arges> mine has been en_US.UTF-8 on both fail and passing cases
 * infinity generates some locales...
<infinity> Nope, I was right.
<infinity> arges: LANG=C fixes it, LANG=en_US.UTF-8 reproduces it.
<infinity> arges: (in a precise chroot)
 * arges checks
<arges> (not that i don't believe you)
<arges> it works!
<infinity> If this is something that's hindering some internal script of theirs or something, "export LANG=C" is the workaround for now, at least.
<arges> infinity: yes
<infinity> But it also hints somewhat at places to look for the fix.
<infinity> But seeing the char it was vomiting on was enough of a hint there. :P
<arges> this is why it helps to check with the local guru.
<infinity> arges: 9954432e309c8fddaec2fe53e601702a5c981624 perhaps
<arges> infinity: i'll make a test build now
<infinity> arges: That's just a random stab from git log, I haven't read the commit or anything. :P
<arges> infinity: works now for UTF-8 locales...
<infinity> Though not entirely implausible.
<infinity> arges: srsly?  First try?
<arges> infinity: no no just reading the git commit
<arges> : )
<infinity> Oh.  Heh.
<infinity> Well, yes, the commit is entirely about abuse of wchars in UTF-8, which definitely touches on this area.
<infinity> But if it actually was what fixed the bug, I don't know.
<arges> yea testing it out now
<arges> or rather building the package
<arges> hmm backporting will take some work for this one
<infinity> arges: Stacking d3ed722566f42d3f614b1221a8e4f19092976531 on top might help.  It kinda reverts half of it. :P
<infinity> arges: What are you trying to backport this to?  Just 2.15?
<arges> infinity: yea
<infinity> Let me spin up a build tree here.
<dobey> woah ev
<dobey> dude
<idank> hello, I'd like to do some research with man pages and could really use a dump of those available here http://manpages.ubuntu.com/manpages/precise/en/man1/ (the .gz format)
<idank> kirkland (the maintainer of that subdomain) suggested I create my own mirror, but I was hoping someone with access to the machines that hosts it could be of assistance
<NishanthMenon> Fuchs, thx
<Fuchs> You're welcome
<kirkland> lamont: infinity: elmo: is there an rsync-able Ubuntu archive mirror within ec2?
<kirkland> lamont: infinity: elmo: AFAICT the s3 backed mirrors are not rsyncable
<luv> hi there - what would be the best place to discuss ubuntu online accounts - the inability to logout/revoke tokens is unacceptable for me and is the reason why im sticking with 12.04 LTS, im happy to help with coding to add the functionality though!
<infinity> kirkland: No idea.
<infinity> utlemming: You're a cloudy guy, do you know the answer to Dustin's question?
<dobey> what the heck
<dobey> i just installed valgrind, and "Ubuntu Core Installer" dialog popped up
<dobey> does anyone know a possible way to run /usr/lib/squid3/ncsa_auth outside of the squid process, to test it? it's crashing on raring, and the backtrace is a bit lacking of usefuleness, so i need to run it under valgrind
<infinity> tjaalton: Wat.
<tjaalton> infinity: que?
<infinity> tjaalton: Looking at your sssd uploads via mdeslaur in the security PPA (sorry for the delay).
<tjaalton> oh
<infinity> tjaalton: Same changelog entry for each.  One is a 718 byte diff, the other is 639 KBytes.  That seems.  Wrong.
<tjaalton> hum
<utlemming> infinity: chatting with dustin now
<tjaalton> infinity: oh, it's correct, they had the same flaw :)
<infinity> tjaalton: What's correct?
<tjaalton> ah...
<infinity> tjaalton: if the changelogs are correct, the diffs aren't.
<tjaalton> kB
<tjaalton> infinity: the quantal one should be fine, need to check the precise upload..
<cr3> jdstrand: in bug #1031090, you mention "add the required flag to the MSRs passed to guests" so that quantal guests can load from precise host. I'm not seeing what those flags are in the bug report though, do you have a hint? :)
<ubottu> bug 1031090 in linux (Ubuntu Precise) "kvm_intel not loadable in a quantal guest" [High,Fix released] https://launchpad.net/bugs/1031090
<tjaalton> infinity: the diff for precise shows files "removed" that aren't in git that the tarball has, for one reason or another.. I'll check with upstream
<infinity> tjaalton: Not sure how upstream relates here.  There shouldn't be a change between two packaging revisions.
<infinity> tjaalton: It's not like this was a diff between two upstream tarballs.
<tjaalton> infinity: well running debdiff against the versions I had built shows only the changes to debian/*
<tjaalton> the tarball doesn't have those files either
<infinity> tjaalton: Is the version in precise-proposed the same as on your computer? :P
<tjaalton> I'll check :)
<infinity> tjaalton: The one in precise-proposed has all that junk in the diff.gz
<infinity> tjaalton: So, someone screwed up.  And if it's not meant to be there, cool.  But you need to make sure the current one's now right. :P
<tjaalton> oh
<tjaalton> infinity: 0.1 isn't the same
<tjaalton> as here
<tjaalton> the diff.gz is nearly 1MB
<tjaalton> perhaps a bit too sensitive to how it's generated..
<tjaalton> still amazing how it has files the tarball doesn't :)
<tjaalton> so yeah, 0.2 looks fine, the diff still has the po stuff but not much can be done there
<tjaalton> infinity: satisfied? :)
<infinity> tjaalton: Never.
<infinity> tjaalton: But this'll have to do for now. ;)
<infinity> tjaalton: Say, did someone actually fix my intel GPU lockups, or have I just been having a good week?
<tjaalton> infinity: did you enable some workaround?
<infinity> Nope.
<tjaalton> and running the current packages?
<infinity> Oh...
<infinity> xserver-xorg-video-intel (2:2.20.19-0ubuntu1) raring; urgency=low
<infinity>   * Merge from unreleased debian git
<infinity>   * rules: Use SNA as the default acceleration method.
<infinity>  -- Timo Aaltonen <tjaalton@ubuntu.com>  Mon, 21 Jan 2013 10:18:31 +0200
<infinity> I didn't enable a workaround, but you did. :P
<tjaalton> oh sna helped, thought you tried it out earlier
<infinity> No, I intentionally didn't switch, cause you told me it was a performance loss.
<infinity> And I'm not keen on hackish workarounds.
<tjaalton> no that was the semaphore thingy, sna was testable to see if switching uxa->sna would fix this hang :)
<infinity> Hrm.  Well, it hasn't hung, so success, I guess.
<tjaalton> yeah, nice
<cjwatson> dobey: hm, "Ubuntu Core Installer" popped up for me earlier after a dist-upgrade - I didn't track down why
<sarnold> cjwatson,dobey: does this look familiar? https://bugs.launchpad.net/bugs/1117165
<ubottu> Ubuntu bug 1117165 in usb-creator (Ubuntu) "Ubuntu Core Installer pops up over login screen" [Undecided,Confirmed]
<sarnold> s/familiar/similar/
<sarnold> similer? sigh. now nothing I type looks correct.
#ubuntu-devel 2013-02-08
<cjwatson> sarnold: not the same situation, but there are multiple causes, I guess
<hallyn> Daviey: around?
<infinity> Uhm.  What just spawned Ubuntu Core Installer from its postinst? :P
<sarnold> infinity: funny, cjwa tson and dob ey were mentioning it earlier..
<infinity> Yeah, I'm going to fix this with fire right now.
 * sarnold gets his ovegloves out
<hallyn> jamespage: is there a way to have the server seed depend on 'qemu-system-$arch' ?  (new qemu will have separate qemu-system-x86, qemu-system-ppc, qemu-system-arm, etc;  qemu-kvm depends on qemu-common which will depend on all of them)
<infinity> hallyn: Sure.
<hallyn> infinity: I'm still ironing out the details on the new qemu merge from debian, but when I push that qemu-system-x86 will be a new package containing only files from qemu-system (which is in main) - will it be hard to get into main?
<infinity> No, splits don't need an MIR.
<hallyn> phew
<infinity> And you'd want seeds something like this (adjusted for whatever the actual truth is):
<infinity>  * qemu-system-ppc [powerpc ppc64]
<infinity>  * qemu-system-arm [armel armhf arm64]
<hallyn> ah cool
<infinity>  * qemu-system-x86 [i386 amd64 x32]
<hallyn> so just like you do in a debian/control :)
<infinity> Pretty much.
<hallyn> thx
<infinity> Plenty of examples of this in the seeds currenty.
<hallyn> that should reduce the size of the server seed a bit,
<hallyn> but theni still need to figure out why oh why qemu-system is depending on libgl1-mesa-glx | libgl1 all of a sudden
<infinity> spice?
<infinity> Or is this pre-spice-enabling?
<hallyn> pre-spice
<infinity> Oh, indeed.
<hallyn> feh, i do hope spice won't add that, that could suck
<infinity> Every single qemu-system-* has a libgl dep.
<infinity> And given our aggressive use of --as-needed, that probably means they actually use symbols from it.
<infinity> Unless there's some gross hand-made linking going on.
<hallyn> is that libglib-2.0.so.0 ?
<infinity> Oh, my grep might be bad. :P
<hallyn> right i don't actually see a 'libgl' as such, or any *mesa* or *qxl
<infinity> /usr/bin/qemu-system-lm32 is the only one.
<infinity> (base)adconrad@cthulhu:~$ for i in `dpkg -L qemu-system` ; do if ldd $i 2>/dev/null| grep -q libGL; then echo $i; fi; done
<infinity> /usr/bin/qemu-system-lm32
<infinity> (base)adconrad@cthulhu:~$
<infinity> I always forget it's uppercase GL.
<hallyn> <scowl>
<infinity> That's sort of a self-solving problem after the split.
<infinity> Assuming lm32 isn't one you care about. :P
<infinity> Whatever it is...
<hallyn> right it's not :)
<hallyn> but libGL comes from nvidia for me
<infinity> lm32-uclinux         lm32 platform for uClinux and u-boot by Theobroma Systems
<infinity> lm32-evr             LatticeMico32 EVR32 eval system (default)
<infinity> milkymist            Milkymist One
<vibhav> libxcb test cases completed \o/
<infinity> Well, yes.  Your libGL comes from nvidia cause you have the nvidia drivers installed, so?
<vibhav> pitti: ^^
<hallyn> infinity: I'm still just trying to figure out what libgl1-mesa-glx is
<infinity> hallyn: It's libGL.
<hallyn> all right
 * hallyn checks where lm32 falls in the split - hopefully qemu-system-misc
<infinity> hallyn: Your dep is "libgl1-mesa-glx | libgl1", and binary drivers all provide the latter and use alternatives.
<vibhav> pitti: I will request a branch merge after I come from school, the bus is here
<hallyn> infinity: ah, i see
<hallyn> infinity: phew, yeah, it's in -misc, so that may solve that
<infinity> hallyn: Unless spice uses GL. ;)
<infinity> hallyn: Well, spice would be its own package too, I'm guessing, a second build of x86?
<infinity> hallyn: Or is Debian just building it in?
<infinity> Hrm, guessing spice is just built in to x86.
 * infinity looks at how that pans out.
<hallyn> yeah i guess we should b eable to tell by looking at the debian-experimental packages
<infinity> Which I just did.
<infinity> And I guess it's not a big deal.
<infinity> I was going to bitch about how spice would pull in all those useless X11 deps.  But qemu-system does that ANYWAY.
<hallyn> right, qemu-kvm shoudl always have done that too, bc it built in sdl
<infinity> Because it's such a wonderfully modular design, so well-suited to masquerading as a lightweight hypervisor.
<infinity> </sarcasm>
<hallyn> and sdl never works right anyway
<hallyn> maybe we can add a qemu-kvm-barebones
<hallyn> infinity: ok, so spice in debian doesn't add libGL?
<hallyn> infinity: (bc it is a big deal due to bug 1118407)
<ubottu> bug 1118407 in qemu (Ubuntu Raring) "qemu-kvm/system has a large number of dependencies" [High,Triaged] https://launchpad.net/bugs/1118407
<infinity> Isn't what qemu-kvm *was* before we decided to just use system?
<hallyn> rephrase?
<infinity> Oh, no, kvm built with sdl too.
<infinity> Nevermind.
<hallyn> right
<hallyn> gah.  biab
<infinity> So, yeah.  It would be nice to have something targetted at servers.
<infinity> It would be so much better if it had a modular/plugin system. :/
<infinity> So you could have the base installed and then say "actually, I'd like some X graphics with that, too... Or spicy acceleration... Or sound... Or whatever)
<infinity> Though, I guess all anyone really needs is the "nothing but barebones kvm/paravirt with no GUI and sound stuff" and "the kitchen sink".
<infinity> hallyn: Oh, speaking of qemu, IS needs a patch in your next upload.
<infinity> hallyn: https://launchpadlibrarian.net/93501920/qemu-linaro-921078.patch got dropped when the great merge happened.
<infinity> hallyn: Given that 2.6.32 is the baseline for experimental's glibc as well, it may pay to just push this to Debian.  Or we can carry it locally.  Whichever.
<infinity> hallyn: So, when that patch got dropped and they rolled out a new backport, all the ARM PPAs broke.  Well done.
<RAOF> Hm. Library versioning question: if liba takes some symbols and puts them in liba-private, with liba depending on liba-private (so the the union of symbols in the new liba + liba-private is a strict superset of the symbols in the previous liba), does this break ABI? My guess is yes, but it seems empirically to not break ABI.
<infinity> RAOF: Nope.
<infinity> RAOF: Not on GNU/Linux anyway.  It all resolves sanely and it's like nothing happened.
<infinity> RAOF: Of course, that also means liba-private isn't private.
<infinity> RAOF: If its symbols are exported and accessible through linking liba.
<infinity> win 301
<RAOF> Yeah. A better name for it could be "liba-minus-the-glib-bits"
<infinity> Heh.
<RAOF> infinity: Ta. The obvious case is "it works", but I wasn't sure if there were some funky dlopen options you could wrangle to only see symbols directly from the library you're dlopening.
<infinity> But if liba depends on liba-glib-bits, why bother with the split?
<infinity> If you dlopen() liba and it links liba-whatever, you'll get whatever with it.
<RAOF> Because other things can depend on liba-minus-glib-bits, I think.
<infinity> Note that I said dlopen() intentionally there.  There are non-dlopen dlopen-alike implementations that screw this up.  But glibc doesn't.
<infinity> (be wary of ctypes)
<infinity> Anything using glibc's linkers (dlopen() or ld.so via direct linking) will be fine.
<infinity> And anyone else is doing it wrong.
<infinity> QED.
<RAOF> Eh. This has an accompanying gir; I don't think anyone sane will be ctypesing it.
<hallyn> infinity: oh, never heard of that patch.  oh i see it wasn't in qemu-kvm...
<hallyn> infinity: should that only be for arm targets?
<infinity> hallyn: The same misfeature applies to all qemu-user-static builds, it's hard an ARM issue.
<infinity> hallyn: Without declaring a uname at build time, it just passes through the system's uname.
<hallyn> oh. i see.  which'll be 2.6.23 or something for hardy :)
<infinity> hallyn: Which is a blatant lie (the syscall emulation doesn't relate at all to the system kernel), and is also rather problematic in some cases.
<infinity> 2.6.24
<hallyn> i was close!
<infinity> But same problem in the other direction.  The syscall emulation isn't ever up to date with linux mainline, so 3.8.0 is just as much a lie.
<infinity> And 3.8.0 is what my raring system will say running uname under qemu-user-whatever.
<hallyn> ok, i'm getting clsoe to pushing, lemme toss taht patch backin tehre realy quick
<hallyn> trying to tell if that flag is safe for system builds
<hallyn> Daviey: jamespage: infinity: mjt: ok, the qemu built from https://github.com/hallyn/qemu/tree/de.jan28.ubuntu2.nixdoc seems to do all the right things for me.  In the morning i'll try a quantal->raring upgrade with it, then probably push it to raring.
<hallyn> (should fix the two bugs jamespage filed today)
 * hallyn out
 * shuduo is away: auto-away
 * shuduo is back (gone 00:07:21)
<pitti> Good morning
<pitti> vibhav: awesome!
 * shuduo is away: auto-away
<LantzR> Hiya
 * shuduo is back (gone 00:17:53)
<dholbach> good morning
<dholbach> highvoltage, happy birthday! :)
<highvoltage> thanks, dholbach!
<dholbach> :)
<mitya57> highvoltage: happy birthday and congrats with becoming a gnome-panel maintainer! :)
<seb128> dholbach, hey, udd question ... will those uploads you did lead to the udd merge request to autoclose if you just dput and didn't bzr merge & push? or should they be set to merged manually?
<dholbach> I think they won't close
<dholbach> I was just waiting for them to be merged
<seb128> dholbach, ok, works for me, I usually set them as merged when I dput so I don't forget but I was wondering if I was overlooking some autoclosing magic on the udd side ;-)
<dholbach> ok
<seb128> dholbach, when is Logan's application going to be reviewed for MOTU btw? ;-)
<dholbach> seb128, according to https://lists.ubuntu.com/archives/devel-permissions/2013-February/000445.html it's on 25 Feb
<seb128> great
<seb128> dholbach, danke!
<dholbach> I feel good now, I just translated a page on https://translations.launchpad.net/ubuntu-packaging-guide/trunk and reviewed 2 pages of translations suggestions
<vibhav> pitti: ping
<pitti> hey vibhav
<vibhav> After compilation, how do I run Xvfb and the test together?
<pitti> vibhav: xvfb-run yourtestprogram
<vibhav> Can xvfb run in the background?
<pitti> xvfb-run does all that for you
<vibhav> pitti: What about the parameters to Xvfb?
<pitti> you don't usually need parameters
<vibhav> Perfect
<vibhav> So screen is :0 , right
<pitti> vibhav: no, xvfb-run will use :99 by default
<pitti> but it sets $DISPLAY
<pitti> so you can do "xvfb-run xeyes" and everything will work
<vibhav> Ah
<lifeless> Just Work in fact
<vibhav> Good
<vibhav> So I refine it and then request a merge
<vibhav> I will*
<Gwaihir> hello, got a question about a Python bug, https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1119195 fixed upstream, what is the process to get it included in 12.04?
<ubottu> Ubuntu bug 1119195 in python2.7 (Ubuntu) "_DummyThread' object has no attribute '_Thread__block" [Undecided,New]
<vibhav> !sru | Gwaihir
<ubottu> Gwaihir: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<Gwaihir> thanks vibhav
<vibhav> No problems
<jrp> Hi, Im compiling some software and Im curious. Why arent ubuntu packages compiled with -fPIC?
<jrp> examples include: libssl.a, libc.a, and libz.a
<mjt> because you've libssl.so, libc.so, libz.so etc
<mjt> if you compile your prog dynamically, use these. if you compile it statically, use libz.a etc but in this case you don't need -fPIC.
<jrp> Im trying to create a shared lib thats statically linked if that makes sense, in which case I do need -fPIC
<mjt> static lib compiled with -fPIC makes sence if you include that static libs into shared libs
<mjt> heh
<jrp> yeeeep.
<mjt> as i said, do not do it, use real shared libs.
<xnox> jrp: that's not supported on debian/ubuntu.
<xnox> jrp: you can recompile libraries in question and then you can do it.
<xnox> aka in a ppa.
<jrp> is there anyway I can create a staticly linked library out of shared libraries?
<jrp> xnox: yeah, im recompiling glibc now :\
<mjt> static libs are already very questionable things, but it really is sometimes necessary to build static apps sometimes.
<xnox> jrp: do not use it, unless all the test-suites pass.
<cjwatson> statically linking glibc is very unwise.
<mjt> but embedding a static lib (especially such common ones like glibc(!!) and libz) is really insane.
<cjwatson> and we went to serious effort to hunt-and-destroy instances of static linking of libz a security vulnerability or two ago.
<jrp> Im very far down a rabit hole, I really just need a shared library with statically linked libcurl
<mjt> hahaha
<mjt> http://curl.haxx.se/docs/adv_20130206.html -- fresh curl security hole for you
<jrp> i saw
<jrp> would it improve things at all if i said it was a research project PoC and not for a production system? I understand why statically linking things is such a horrible idea from a security perspective
<mjt> it is really a bad taste to help to do such a bad thing.
<cjwatson> jrp: it's not going to persuade us to offer the facility widely, I'm afraid, because it's just too tempting to misuse
<mjt> and it always starts from research/PoC thing, and spreads from there...
<cjwatson> jrp: that said, you'll find some -pic variants of libraries, which exist for special purposes - for example libc6-pic
<mjt> cjwatson: what purposes are these?
<jrp> cjwatson: thats incredibly helpful
<cjwatson> mjt: installer
<mjt> ubuntu uses its own installer?
<cjwatson> scary library reduction thing which really ought to be replaced now that we have sane udeb shlibdeps, but ...
<cjwatson> mjt: no, d-di
<cjwatson> *d-i
<cjwatson> mjt: libc6-pic is in Debian too
<mjt> yeah, d-i and reduction. i remember now.
<jrp> I mean, if youd like Id happily explain my project briefly and if theses a better way to do it Ill happily switch to it. Im very much stumbling through things as I go
<cjwatson> we wouldn't have introduced it ourselves
<mjt> d-i is an evil thing anyway :)
<cjwatson> nah, it's lovely and fluffy
<cjwatson> admittedly there is a core of complex evil
 * mjt , being one of the d-i team, hides and runs away
<cjwatson> well, likewise :)
<mjt> but i don't do much there, only busybox
<mjt> (maybe it's time to stop caring about lib size reduction, -- we use DVDs with much larger size and alot more packages these days, so the difference in size between reduced and regular libc.so makes no sence at all)
<jrp> well, thank you guys very much for the help, i appreciate it
<cjwatson> jrp: In general the better way is just to use ordinary dynamic linking and have dependencies to ensure that the proper shared libraries are present ...
<jrp> cjwatson: Im building something which will be executed through LD_PRELOAD (which I know is also evil)
<cjwatson> I wasn't aware that LD_PRELOAD disregarded indirect linkage?
<mjt> wow. linking libc statically into LD_PRELOADed object may have... interesting effects.
<mjt> ;)
<cjwatson> Quite, you'll probably end up with a sea of symbol conflicts and consequent segfaults
<jrp> ok, backing up some more. Im hooking connect() using LD_PRELOAD, then trying to use libcurl to send data off
<cjwatson> http://stackoverflow.com/questions/4385155/setting-my-lib-for-ld-preload-makes-some-processes-produce-loader-errors implies that dynamically-linking a preloaded library works fine
<jrp> Im concerned that libcurl will see my not-real-connect, as opposed to real connect
<jrp> does that make any sense?
<cjwatson> I think what you want is to build a shared libcurl without -Bsymbolic-functions
<mjt> you'll have to implement all read/recvfrom/etc stuff too
<cjwatson> Let me check what our curl is built with
<mjt> (or just fork a child process linked with curl, and return a real socket fd from socketpair)
<mjt> that might be a ton easier and safer
<jrp> Im trying to avoid forking, I have it working now in a fashion via fork/exec
<cjwatson> Yeah, our curl's linked with -Bsymbolic-functions, so you'd need to undo that in order to be able to override symbols therein using LD_PRELOAD.  Or mjt's solution would work too.
<jrp> but id like to avoi the process overhead
<cjwatson> A bit of a hassle but almost certainly less painful than static linking.
<jrp> Uh, so Im sure were on the same page. I -want- curl to use the system's connect()
<cjwatson> Oh, ISWYM
<jrp> so Im trying to statically link curl so it -wont- hit my connect/getaddrinfo/gethostbyname
<cjwatson> Ah, no, -Bsymbolic-functions doesn't apply because connect isn't within the library
<cjwatson> jrp: Sounds like sledgehammer and nut ...
<jrp> cjwatson: As I said, Im stumbling through it, down a rabit hole. Im 100% open to smaller hammers
<mjt> write a small daemon that does your curl work and connect to it from ld_preload
<mjt> to avoid forking overhead
<jrp> hm, thats a very good idea
<mjt> tons of possibilities, embedding stuff into ld_preload seems like one of the worst solutions
<jrp> when all you have is a hammer... I dont know why I didnt think of a daemon
 * cjwatson tries to remember details of symbol resolution rules
<jrp> it makes me feel marginally better that all this isnt super obvious
<cjwatson> jrp: Here's another possibility (probably at the very least glibc-specific and possibly Linux-specific): http://paste.ubuntu.com/1623988/
<cjwatson> jrp: (Actually, make the "int (*connect_real)" line "static int ..." instead for efficiency, I missed that bit)
<jrp> ...wow. seriously, thank you so much.
<cjwatson> bar.c here is of course a stub taking the place of libcurl
<jrp> yeah
<pitti> tjaalton: could you please have a quick look at https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-gtk-/129/artifact/gtk+.log ? that's a very recent failure, does that ring a bell?
<pitti> tjaalton: it still worked on Feb 6, failed on Feb 7
<pitti> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-mutter/101/artifact/mutter.log fails in the same way
<pitti> error: conflicting types for 'BarrierEventID'
<tjaalton> pitti: needs a rebuild, I've uploaded a new libxi last night
<pitti> tjaalton: oh, is that  2:1.6.99.1-0ubuntu2
<tjaalton> yes
<pitti> tjaalton: thanks, sorry for the noise
<tjaalton> sorry for pushing the original one to raring and not the staging ppa ;)
<pitti> can't escape Jenkins :)
<tjaalton> :)
<cjwatson> jrp: ... and no problem, it was an excuse to try to remember this stuff
<jrp> cjwatson: is theres a source youd recommend for understanding what -Bsymbolic-functions does?
<cjwatson>      When creating a shared library, bind references to global function
<cjwatson>      symbols to the definition within the shared library, if any.
<cjwatson> is what 'info ld' says
<cjwatson> In other words: normally something earlier in the link (the main program, a library loaded earlier, or an LD_PRELOAD) gets to override symbols in any libraries linked later
<cjwatson> So if you have a "malloc" symbol in your program then that also overrides malloc for any libraries it loads
<cjwatson> Actually, sorry, that's misleading
<cjwatson> Let's say you have a curl_getenv symbol in your main program - that would ordinarily override the one in libcurl
<cjwatson> But if libcurl is linked with -Bsymbolic-functions, the linker looks for any internal function calls within the library (that is, calls from one function in the library to another) and rather than leaving those symbols to be resolved when the whole program is loaded, it resolves them all in advance in libcurl.so
<cjwatson> This has the downside that you can't then override those symbols with LD_PRELOAD (so we don't use -Bsymbolic-functions for libraries like libc where you commonly want to preload their symbols), but it has the advantage that the dynamic linker has to do many fewer relocations when loading a program, so it makes program execution more efficient, especially for programs involving many libraries such as you find on the desktop
<cjwatson> Does that help?
<jrp> yes, very much
<jrp> ok, Im trying to make sure I understand this. main calls connect, which gets sent off to libfoo.so. libfoo passes it to inner connect in libbar, which actually sends it back to libfoo. But because the inner val is different, we now execute real connect, flip inner back, and return
<cjwatson> Right, and because inner is static its value is saved across invocations
<jrp> yep
<Gwaihir> hi, can anybody give an update on this bug? https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1077153 there's a comment for precise, but I cannot find an updated package with that fix...
<cjwatson> So the preloaded connect gets to communicate with recursive calls to itself
<ubottu> Ubuntu bug 1077153 in python2.7 (Ubuntu Precise) "Backport request: http://bugs.python.org/issue14308" [Undecided,Triaged]
<cjwatson> The RTLD_NEXT trick is the glibc-specific bit, I believe
<jrp> yeah, it is
<cjwatson> Hence #define _GNU_SOURCE
<jrp> yep
<jrp> if youre going to do that btw
<jrp> well, i gues you couldnt matke it static then
<cjwatson> make which static?
<jrp> but typeof(connect) connect_real
<cjwatson> oh, yeah
<jrp> makes the function pointer syntax less obnoxious
<cjwatson> I figured it didn't really matter since we already need to know the type for the wrapper function
<jrp> yeah
<cjwatson> But feel free to polish further :)
<jrp> ok, so Im still missing something here I think
<jrp> lets say bar.c is our program which uses libcurl. wont it still hit connect in libfoo?
<cjwatson> Is libcurl being used in the main program as well as in the preloaded wrapper?
<jrp> possibly
<jrp> well, yes, it will be
<jrp> in some cases
<cjwatson> You'll have to figure out when you want your wrapper to take effect and when you don't
<cjwatson> But you should have enough flexibility this way to vary the policy
<cjwatson> If all else fails you could wrap curl functions just for the purpose of noticing that you'd entered them ...
<cjwatson> (You'd need a file-scope static variable then)
<jrp> yeah, ok
<jrp> that makes sense
<jrp> heh, christ what a PITA :)
<xnox> Gwaihir: well precise has 2.7.3 not sure which patchlevel. Do you have a link to the commit on 2.7 branch handy? There should be 2.7.4 soon, is that patch included?
<Gwaihir> xnox, upstream commit link is this one: http://hg.python.org/cpython/rev/ab9d6c4907e7
<Gwaihir> xnox, as far as I know it should be in upstream 2.7.4, but is 2.7.4 going to be available in precise too?
<jrp> cjwatson: hm, I think the easiest way is just going to be to wrap the curl_execute functions with something like your inner var
<jrp> cjwatson: because all my functions call their real versions
<pitti> vibhav: meh, https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-ncurses/1/ARCH=i386,label=adt/ fails
<jrp> cjwatson: and return the same results, they just perform some db operations along the way
<pitti> vibhav: that may be because the test doesn't actually have a stdout/stderr?
<xnox> Gwaihir: well we are currently packaging the tip of 2.7 branch in raring. And I don't see past history of uploading python micro-releases. But since 2.7 is the last one.....
<xnox> Gwaihir: i think it's safer to cherry pick that one patch as an SRU. Please follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template on the bug report. with pointers upstream and then we can SRU that.
<cjwatson> jrp: *nod* makes sense
<Gwaihir> xnox, ack
<xnox> pitti: did any body write UDisks2 template for dbus-mock yet?
<pitti> xnox: not that I know of
<xnox> pitti: ok. I ported usb-creator to UDisks2, but I don't trust it. Looked into porting the test-suite and it seems like dbus-mock would be more extensive and easier to use. Considering that I also want to test our own (usbcreator) helper as well.
<pitti> xnox: yeah, and might be useful for other tests, too
<pitti> xnox: "trust" in which sense? fails in tests? or just a gut feeling?
<pitti> (fails in manual test, I mean)
<xnox> pitti: it now doesn't fail in manual tests, but I did have round-trips of "i fix here, now it's broken there again where I just fixed it"
<xnox> I guess my pitfall was being inconsistent in passing sometimes dbus object path '/org/freedesktop/UDisks2/block_devices/sdb1' and sometimes device file names '/dev/sdb1'
<xnox> manual tests are ok, apart from failure conditions not that well tested (what if it's unplugged at various points of progress)
<jrp> cjwatson: thanks again, its past time for me to pass out. i owe you a sixpack
<jrp> cjwatson: feel free to collect if youre ever in Oregon
<Gwaihir> xnox, will something like this https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1119195 work for an SRU?
<ubottu> Ubuntu bug 1119195 in python2.7 (Ubuntu) "_DummyThread' object has no attribute '_Thread__block" [Undecided,New]
<tjaalton> grr, could someone remove xserver-xorg-video-s3 and -qxl from raring-proposed?
<tjaalton> mistakenly uploaded there
<tjaalton> someone as in archive admin..
<Laney> tjaalton: they shouldn't be there at all or you're going to fix in a subsequent upload?
<tjaalton> Laney: not at all, should be in canonical-x/x-staging
<Laney> seb128: didrocks: ^^^
<tjaalton> nothing critical there, it's basically just a rebuild
<tjaalton> but would save yet-another upload :)
<xnox> Gwaihir: looks good. I'm confused why you filed it as a new bug, instead of updating the existing one =)
<didrocks> Laney: hum, I think you need more than an archive admin to change something in the published repo :) (or I've never done that more exactly and https://wiki.ubuntu.com/ArchiveAdministration doesn't mention it)
<didrocks> tjaalton: ^
<Gwaihir> xnox, the old one was marked as Fix Released...
<seb128> didrocks, I think you can just delete from proposed (as you would delete a source from the archive), but I never tried
<xnox> Gwaihir: bugs can have tasks. Precise task was not "Fix Released"
<xnox> Gwaihir: e.g. we track bugs per-series =)
<tjaalton> right, it's still pending, so should be doable
<didrocks> seb128: same, I think that the manual removals enable that, but I prefer people knowing to do it first :)
<Gwaihir> xnox, yep... right... my bad, I can update the other one
<xnox> Gwaihir: don't worry. Let me sort it out.
<Gwaihir> xnox, thanks
<xnox> Gwaihir: now, that's better. Note that it will have to wait until after 12.04.2 is released.
<xnox> bug 1077153
<ubottu> bug 1077153 in python2.7 (Ubuntu Precise) "_DummyThread' object has no attribute '_Thread__block" [Medium,Triaged] https://launchpad.net/bugs/1077153
<seb128> tjaalton, Laney, didrocks: trying "./remove-package -m "uploaded by error" -s raring-proposed xserver-xorg-video-s3"
<Gwaihir> xnox, ok, thanks again
<xnox> Gwaihir: in the mean time you can just catch and ignore that attribute error ;-)
<tjaalton> seb128: same for -qxl?
<seb128> trying
<tjaalton> thanks :)
<tjaalton> lp shows it as published in the proposed pocket now
<tjaalton> *them
<Laney> let me block them to be safe
<seb128> yeah, command doesn't work for atm
<seb128>     items = gnomekeyring.find_network_password_sync(username, service)
<seb128> gnomekeyring.IOError
<Laney> hoho
<Laney> you might want https://rbtcollins.wordpress.com/2013/01/24/launchpadlib-without-gnome-keyring/
<seb128> didrocks, does "./remove-package -m "uploaded by error" -s raring-proposed xserver-xorg-video-s3" work for you?
<didrocks> let me try
<seb128> my session is screwed, compiz froze again
<seb128> and I didn't want to restart
<seb128> I ran it from a vt, which restored UI but broken env
<Gwaihir> xnox, wish I could do that, I would have to patch another library not under my control, anyway, is that targeted for 12.04.2 or .3?
<didrocks> seb128: Laney: tjaalton: flushed
<seb128> didrocks, same for qlx please ;-)
<Laney> qcl
<Laney> qxl
<seb128> ups
<didrocks> yep, looking first at what's happening in launchpad for -s3
<seb128> I need to report that compiz issue
<tjaalton> didrocks, seb128, Laney: great, thanks!
<seb128> it's frozen every second time I come from a guest session since I started using a second monitor
<didrocks> ok, seems that -raring still have a package :)
<seb128> didrocks, that command is what https://wiki.ubuntu.com/ArchiveAdministration recommends to remove buggy SRUs
<Laney> seems like it worked
<tjaalton> didrocks: do the same for -qxl too
<seb128> didrocks, so I figured it would be similars ;-)
<didrocks> -qxl done :)
<tjaalton> ah, echo
<tjaalton> :)
<Laney> so be aware that you can't reuse that version next time
<tjaalton> oh
<didrocks> seb128: yeah, I feel more confortable when seeing it's what is done for SRUs ;)
<tjaalton> well this was a useless excercise then :)
<didrocks> tjaalton: tsss tsss, let's say it was for exercising our fingers at least!
<didrocks> not completely useless ;)
<tjaalton> heh, ok
<didrocks> tjaalton: thanks for checking my health :)
 * didrocks hugs tjaalton
<tjaalton> didrocks: :)
<xnox> Gwaihir: .3, we are frozen for .2
<ogra_> xnox, cjwatson, i'll roll back ac100-tarball-installer so we have installable images over the weekend (and i have a little more time to find some fixrtc like workaround)
<xnox> ogra_: all the way to using -m or simply without warning stanza?
<ogra_> all the way to the last known working setup
 * xnox ponders if all the default no-warning should be listed as well on the command line.
<ogra_> i dont want to block QA so we need a quick fix for now
<ogra_> since we dont have milestone images anymore we could point people to for a last known good install ...
<ogra_> and uploaded ...
 * ogra_ will trigger a manual image build later, once the cron build is done
<xnox> infinity: anything else I have missed? http://paste.ubuntu.com/1624731/
<xnox> ogra_: i wonder if it's a red-herring though
<xnox> ogra_: i just did simg2img on the last nexus7 image I have -> copied the tarball. Did tar xvf on it and it reported same error
<xnox> tar: Skipping to next header
<xnox> tar: Exiting with failure status due to previous errors
<xnox> with exit code 2
<ogra_> xnox, hmm
<xnox> ogra_: the error is from zcat not from tar
<xnox> ogra_: http://paste.ubuntu.com/1624936/
<xnox> looking at logs on ~ubuntu-archive/* i can't seem to find the bit where compression was invoked to see if that had errors.
<ogra_> you need the live-build log
<ogra_> wow
<ogra_> new acii art on nusakan
<xnox> ogra_: pastebinit =) i don't have access there.
<ogra_> hmm, there isnt any tzar output in the livefs build logs either
<ogra_> *tar
<ogra_> http://paste.ubuntu.com/1624983/
<xnox> ogra_: that is very cool
<ogra_> yup
<ogra_> we regulary get new shiny login graphics :)
<ogra_> hmm, so we dont actually roll the tarball form our own function but use live-build's
<xnox> too bad they don't make it to OMGubuntu for everybody to comment how thin the stokes are and imperfect the perspective is.
<xnox> well the error is from zcat, I'd expect to see some warnings at gzip step =) if any, for example I/O fail etc...
<ogra_> right, but there arent any errors
<ogra_> P: Begin mounting /sys...
<ogra_> [2013-02-08 14:40:49] lb_binary_iso
<ogra_> [2013-02-08 14:40:49] lb_binary_netboot
<ogra_> [2013-02-08 14:40:50] lb_binary_tar
<ogra_> [2013-02-08 14:40:50] lb_binary_hdd
<ogra_> lb_binary_tar should have the errors if any
<xnox> ogra_: add a zcat | tar -t > /dev/null there and if it fails abort the build =)
<xnox> cause it's annoying to build/publish/download/flash/boot to find out there is a tarball decompress error.
<ogra_> nthe build already takes over 90min ....
<xnox> *sigh*
<ogra_> i cant really add something that takes another 30
<ogra_> we were planning to switch to xz anyway
<xnox> well there is only read IO and no write  + CPU
<ogra_> we didnt have issues before though
<xnox> true.
<xnox> gzip upgraded recently?
<ogra_> not that i know of
<ogra_> at least not on -changes ... did debian upgrade ?
 * xnox is recompressing the tarball to recreate the image and check if that fails.
<ogra_> so that we have pulled something in by accident
<xnox> nah last gzip update is from before starting nexus7 images =)
<ogra_> tar cf binary-tar.tar binary
<ogra_> gzip ${GZIP_OPTIONS} binary-tar.tar
<ogra_> thats the code in lb
<ogra_>        GZIP_OPTIONS="${GZIP_OPTIONS:---best}"
<ogra_>         if gzip --help | grep -qs "\-\-rsyncable"
<ogra_>         then
<ogra_>                 GZIP_OPTIONS="$(echo ${GZIP_OPTIONS} | sed -e 's|--rsyncable||') --rsyncable"
<ogra_>         fi
<ogra_> and that seems to be the default
<ogra_> nothing special in it (and i dont really belive it is gzip)
<xnox> make_ext4fs corrupting files? =/
<ogra_> nah, it didnt before
<ogra_> the only actual change was that we dropped -m and that infinity switched to long options
<ogra_> and i doubt the long options cause it :)
<xnox> it was working fine when -m was dropped.
<xnox> I reported that it prints "timestamp too far in the future" for every file on flashing, but it did finish flashing and booted into oem-config
<ogra_> oh
<xnox> It didn't work after --warning=no-timestamp got uploaded
<ogra_> i dont see a --best option in our gzip manpage
<xnox> (and it's ~ same image I have now)
<xnox> --best == -9
<Laney> I installed it after that warning was disabled
<Laney> s/installed/flashed/
<ogra_> xnox, yes, but its not documented
<ogra_> Laney, and it worked ?
<xnox>  -# --fast --best in man gzip
<Laney> yeah
<Laney> something borked and I had to go back to android first though
<ogra_> xnox, bah, need to train my search abilities :P
 * ogra_ scratches his head
<xnox> ogra_: technically it's the -9 that isn't documented ;-))))) -# is
<ogra_> xnox, do we log the output of fastboot when flashing with usb-creator ?
<ogra_> i wonder if there were any issues when flashing for the people seeing no installer
 * xnox wonders did people start using usb-creator suddently? (considering that it doesn't do ungzip)
<xnox> there are some logs....
<ogra_> oh, it doesnt work yet ?
<xnox> it does work, it's just the download is .img.gz & usb-creator expects .img
<stgraber> I'm mostly killing it whenever it shows up (and it does that a lot)
<xnox> one needs to decompress =)
<pitti> xnox: I used it yesterday, yes
<pitti> but for .iso
<ogra_> xnox, well, we should include the decompressing somwhow
<xnox> stgraber: yeah, sorry about that. Infinity hit it on the head.
<xnox> stgraber: http://paste.ubuntu.com/1624731/ can you think of any other times it popped up & you didn't want it to?
<ogra_> stgraber, it wants to tell you something about the priority of working on mobile i guess ;)
<stgraber> ogra_: well, considering it did that every time I wanted to test some packages for mobile, it did a pretty sucky job at motivating me to continue ;)
<ogra_> lol
<cjwatson> +[ x"$XAUTHORITY" == x"" ] && exit 0
<cjwatson> +[ x"$user" == x"lightdm" ] && exit 0
<cjwatson> xnox: those are bashisms
<cjwatson> s/==/=/
<cjwatson> $ [ "" == "" ]
<cjwatson> dash: 1: [: unexpected operator
<ogra_> well, we just need to make upstart use a full bash implementation ... see ... fixed :)
<stgraber> wow, I'm really glad we're getting upstart user sessions soon, that kind of upstart job really shouldn't exist ;)
<barry> cjwatson: that sure looks familiar
<ogra_> stgraber, ++
<xnox> shadeslayer: yes.
<ogra_> stgraber, in the beginning it actually fired on every USB plug event :)
<ogra_> it already improved a lot
<stgraber> ogra_: ah, that might have been my problem then, considering I'm working on phone support and plug/unplug USB phones every 30s or so ;)
<ogra_> but ... that doesnt fix our tar/gzip issues
 * ogra_ sighs
 * ogra_ suspects he has to do a fresh install himself to dig deeper
<stgraber> xnox: there, your new upstart job, which will only work on my laptop ;) http://paste.ubuntu.com/1625157/
 * xnox wants a shell that doesn't support bashism, yet has bash-completion & history scrollback and colors
<xnox> stgraber: I know. I can't wait for user sessions.
<xnox> with less bash now http://paste.ubuntu.com/1625172/
<ogra_> s/test/\[/
<ogra_> ?
<cjwatson> doesn't matter
<xnox> consistent with previous calls to test
<ogra_> well, i like it better :)
<ogra_> technically it doesnt matter indeed
<stgraber> hehe, was about to mention that I tend to prefer '[ ... ]' to 'test ...' but it's the same statement, so I don't really care, especially as the job will get a lot shorter pretty soon and all that will go away ;)
<ogra_> yeah
<xnox> or I can not upload this and wait for user sessions =)
<shadeslayer> xnox: whut o_o
<xnox> shadeslayer: upstart user sessions - the bit where upstart will start gnome-session and can manage long running processes for the user.
<xnox> shadeslayer: see the blueprint and massive spec on the wiki and discussions about it on ubuntu-devel & upstart-devel
<shadeslayer> no no
<stgraber> xnox: well, I think it's safe to assume we'll land user sessions before feature freeze but we still need a bit of work to get the whole logout/shutdown/restart working and the environment stuff I mentioned
<shadeslayer> <xnox> shadeslayer: yes.
<shadeslayer> what was that about? :D
<ogra_> shadeslayer, he meant stgraber ... tab completion error
<shadeslayer> ahh
<shadeslayer> should have guessed it
<mterry> seb128, your pyatspi sync is causing bug 1119426
<ubottu> bug 1119426 in pyatspi (Ubuntu) "package python3-pyatspi (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/python3/dist-packages/pyatspi/editabletext.py', which is also in package python3-pyatspi2 2.7.2+dfsg-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1119426
<seb128> mterry, oh ok, will look into it, thanks for pointing that
<jdstrand> cr3: hey, you asked about MSRs on bug #1031090. I don't know-- the description was updated for the SRU. maybe ask smb?
<ubottu> bug 1031090 in linux (Ubuntu Precise) "kvm_intel not loadable in a quantal guest" [High,Fix released] https://launchpad.net/bugs/1031090
 * smb does not see any MSR related question in that bug...
<jdstrand> smb: "Fix: Just add the required flag to the MSRs passed to guests. This change is picked from the patch that enabled the feature but does not enable anything beyond. It has been reviewed upstream and sent to upstream stable."
<jdstrand> smb: cr3 was asking about that statement yesterday
<smb> Ah ok. Well what I tried to say was that some of those contain capability flags. Which the kvm module checked to load
<cr3> jdstrand: hi there, thanks for following up! I just managed to get a quantal kvm working on precise, it must've been a problem with my script that generates the libvirt.xml file
<jdstrand> cool
<cr3> jdstrand: I was curious how unity would work under kvm but it works like a charm, cpu usage is low, all is well. now, raring ringtail!
<jdstrand> wow, that has not been my experience on quantal
<cr3> jdstrand: really, what did you observe?
<jdstrand> very slow due to llvmpipe
<jdstrand> precise and earlier could use unity-2d and that was fine
<jdstrand> cr3: mdeslaur discovered how to disable fades and animations in gsettings that made it tolerable
<jdstrand> but still slower than unity-2d
<cr3> jdstrand: I haven't used it much yet in a vm, but when it's idle the cpu usage is also quite idle
<jdstrand> yes, that isn't so bad
<jdstrand> but menu fade-ins and application launches are pretty bad
<cr3> mdeslaur: ^^^ do you have a link for your tweaks?
<jdstrand> once the application is running, it is generally ok
<jdstrand> cr3 (mdeslaur): I'm getting it
<cr3> jdstrand: exactly, I was expecting worse so I'm actually pleasantly surprised considering
<mdeslaur> http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/revision/967
<ubottu> Ubuntu bug 967 in gnomebaker (Ubuntu) "Should burn multiple CDs in a row if the first fills up" [Wishlist,Confirmed]
<mdeslaur> cr3: ^
<jdstrand> thanks ubottu - very apropos
<jdstrand> mdeslaur: actually, I forgot to try the Dash. did you see any improvement there?
<mdeslaur> well, it doesn't fade in anymore, so it's better
<jdstrand> cool
<jdstrand> oh yes, that is considerably better
<jdstrand> slow, but better
<cr3> mdeslaur: if I understand the changes you made to ubuntu-qa-tools correctly, these are all persistent; once applied, they persist across reboots. right?
<mdeslaur> yeah
<cr3> mdeslaur: all good then, thanks!
<mdeslaur> it's basically just disabling two compiz modules for the user
<infinity> xnox: That user = lightdm test seems silly, and sort of highlights to futility of trying to do this as a system job.
<infinity> xnox: (The best approximation of what you're trying to do would probably be a check if UID << 1000, so other DMs also work, but it really seems wrong to be doing it this way at all)
<infinity> xnox: Not to mention the general wrongness with assuming what you're assuming: If I'm logged in, have those packages installed, and plug in my Nexus, that means I want to re-flash it?
<xnox> infinity: and it's in fastboot mode.
<ogra_> infinity, its obsolete as soon as the upstart session stuff is there
<xnox> which it wouldn't unless you boot it with power button + volume down.
<infinity> xnox: Ahh, that helps.  I missed that bit in your revision.
<ogra_> and what xnox said, the nexus has a special ID in that mode
<xnox> infinity: fastboot devices only prints devices which are in fastboot mode & ready to cooperate with flashing =)
<xnox> it's all very consensual.
<mdeslaur> uhm, what are we talking about here? I hope we're not trying to launch stuff as a system daemon on plug events...
<ogra_> mdeslaur, well, we pop up usb-creator if a nexus7 in flash mode is attached
<ogra_> mdeslaur, the code above is not supposed to stay, it will be a user session service in the end
<xnox> mdeslaur: we are talking about launching a user app on plug event.
<mdeslaur> ogra_, xnox: it's not safe to do with with a system daemon. It needs to be done in the user's session.
<ogra_> yes, thats the plan
<ogra_> we're just waiting for the new upstart :)
<xnox> mdeslaur: ha =) so why does power-management has functions to do so? =)
<mdeslaur> using sudo in this way is likely to facilitate a root escalation via tty hijacking, etc.
<mdeslaur> xnox: huh? where?
<ogra_> mdeslaur, yeah, its ugly but its an interim
<ogra_> its not like we are pushing that into a stable release or so
<mdeslaur> ok
<kirkland> jamesh: howdy!  is it possible to fork 3 different daemons within a single upstart configuration?
<kirkland> jamesh: or would it be better to write 4 different upstart jobs (one wrapper, and one for each of the 3 daemons)?
<xnox> jodh ^
<xnox> kirkland: use instances.
<kirkland> xnox: can you point me to an existing service/example, and I can probably take it from there...
<xnox> kirkland: see for example /etc/init/network-interface.conf which is one conf file but starts/tracks each unique network interface.
<JanC> instances might not be the right solution to run *different* daemons
<xnox> one can easily use that pagadim to track e.g. N workers.
<kirkland> xnox: okay -- so I want to launch my binary 3 times, each with a different argument to listen on a different port
<kirkland> xnox: where do I iterate over those 3 ports?
<kirkland> xnox: emit a signal in the prestart?
<kirkland> xnox: that's how I'm reading that network-interface.conf
<mjt> kirkland: why, oh why you left qemu? :)
<xnox> 1 master job that does: start myfoo 146; start myfoo 147; start myfoo 148.
<kirkland> mjt: howdy :-)  it's been a *long* time since I contributed anything meaningful to #qemu :-)
<xnox> kirkland: sorry it's key-value, so one would have: start myfoo INSTANCEPORT=147 for example
<kirkland> xnox: perfect -- that'll work
<kirkland> thanks!
<xnox> kirkland: network-interface listens on unique events, but one can emit events from another job file or do explicit start from another job file.
<kirkland> ^ xnox
<mjt> kirkland: now watch all your stuff is being replaced by debian qemu, as a penalty to you! :)
 * mjt hides
<kirkland> mjt: as it should be :-)  I'm very, very supportive of hallyn's work ;-)
<mjt> actually.. so as me ;)
<kirkland> mjt: my excuse was that, at the time (2008-2010), qemu-kvm was so essential to what I was trying to do for Canonical with Ubuntu, I simply had to fork the packaging to keep up (couldn't wait on Debian) :-)
<kirkland> mjt: and I can't apologize for that :-)
<kirkland> mjt: all that said, things are so much more stable now, it's definitely time to resync back with Debian on qemu
<mjt> kirkland: thank you! ;)
<mjt> kirkland: it was actually the same thing for me when i started working with kvm :)
<xnox> ogra_: after all the chit chat we had, did you respin the nexus images after the revert?
<cjwatson> tyhicks: are you likely to get bug 1026852 sorted out today?  I have a chain of stuff blocked on it involving eglibc and arm64-cross-toolchain-base; if that could involve just retrying builds rather than new source uploads with patches it would be nice
<ubottu> bug 1026852 in audit (Ubuntu) "[MIR] audit (pulls in libprelude)" [Undecided,In progress] https://launchpad.net/bugs/1026852
<tyhicks> cjwatson: Yes, it should be sorted out today. There are tons of compiler warnings but I got a nice head start on it last night.
<cjwatson> tyhicks: if not I expect I could at least sort out the compiler warnings tonight, which the bug trail indicates should be enough to promote it to main
<cjwatson> tyhicks: ah, good
<infinity> cjwatson: Yeah, I've been working with them on it, it's all good. :)
<infinity> cjwatson: Oh, and I had all of *-cross-toolchain-base sitting here on my machine waiting to upload too.  Oh well.
<cjwatson> infinity: hah
<cjwatson> infinity: um, well, I was about to do armel and powerpc ...
<cjwatson> infinity: if you have them ready feel free, but maybe we want to keep the exact patches in sync
<infinity> cjwatson: Go ahead.  I'd only done arm64 and armhf so far. :P
<cjwatson> heh.  sorry, should've asked.  was trying to unblock wookey
<infinity> cjwatson: When I said "all", I meant "I had been working on it, which was why the latest glibc upload fixed arm64 cross".
<infinity> But yeah.  Go ahead and sync them all, now that you started. :P
<infinity> The mess builds fast enough, I wonder if maybe we should just do them all from one source package and be done with it.
<infinity> Adding proper parallel= handling to it would probably make up the difference.
<infinity> cjwatson: Oh, the ppc one needed another change to it to undo an unnecessary hack.  I'll fix.
<cjwatson> infinity: ah, thanks, I was about to look at that
<cjwatson> You can tell I got bored of test-building these locally
<infinity> Heh.  Yeah, that should be the shlibs hack that's no longer needed with my new glibc patches.  I think.  But I'll double-check and test-build.
<dobey> barry: hey. is there something specific in the new oauthlib that your changes to ubuntu-sso-client needs? do the other branches also need it?
<barry> dobey: my branches really just change the code to use the different api in oauthlib.  other than that, it shouldn't change anything functional.  when you say other branches, do you mean the u1-client and u1-storage-protocol branches?
<dobey> barry: yeah
<dobey> barry: i'm asking because on the sso branch you mentioned needing to wait for the new version of oauthlib in raring
<barry> dobey: they basically do the same thing, just updated to use the oauthlib apis
<dobey> barry: so i was wondering if there was a specific reason for it
<barry> dobey: ah, yes.  it was the ability to pass the timestamp into the ctor
<barry> that was missing, but required by the tests
<barry> so i asked upstream to add it, which they did :)
<dobey> barry: do the other branches need that as well, or just the sso one?
<barry> dobey: hmm.  not sure, but unless you're backporting, it's moot, since we have the right version in raring now
<dobey> barry: we build nightlies as far back as oneiric
<barry> (the other useful new api was better handling of unicodes by passing in an encoding parameter and letting the library encode to bytes.  so that part is probably necessary now as well)
<barry> dobey: in that case, the current oauthlib will probably be necessary, due to the new encoding api
<barry> dobey: or at least, very helpful (you can work around that part of it)
<barry> dobey: by doing the encoding in the u1 branches, which i'd originally done, but removed when oauthlib 0.3.5 was released
<dobey> also, we shop on windows and osx :)
<dobey> err, ship
<barry> dobey: is it a problem to backport the oauthlib?
<dobey> barry: hopefuilly not (i haven't tried yet)
<dobey> barry: i was just seeking clarification on it
<barry> dobey: cool.  please do let me know if you run into any problems
<barry> dobey: upstream claims support back to py26, so that should be fine
<dobey> great. hopefully it just works on win/osx too :)
 * barry nods
<dobey> but given it's not just a python lib, that might be a problem :-/
<barry> dobey: i can probably help with various flavors of osx and if i suppress the gag reflex, windows 7 too
<dobey> barry: we still support xp too (xp, 7, and 8)
<barry> dobey: sounds like fun
<dobey> oh, it is all python?
<barry> dobey: yep
<dobey> oh, probably fine then
<dobey> i thought it had C too
<barry> nope.  it does dep on pycrypto though, i guess to do the signatures
<dobey> is that not in stdlib?
<barry> nope, but reading the docs, it's just a soft dependency, to support RSA-SHA1 signatures.  i don't think u1 uses those though
<dobey> hmm
<barry> iirc, just hmac-sha1 and plaintext
<dobey> we do use hmac
<dobey> well, python-oauth doesn't support rsa-sha1 either
<barry> yeah, so you're probably fine w/o it
<dobey> yeah
<barry> dobey: yep, looking at github upstream, Crypto is only imported in sign_rsa_sha1() and verify_rsa_sha1()
<dobey> cool, thanks
<dobey> barry: ugh, looks like i have to backport python-crypto and python-nose as well, at least for our nightlies builds (as the package build runs tests and needs newer versions)
<barry> dobey: urg.  i guess you can't or don't want to disable those tests
<dobey> well i can. would prefer not to though
<dobey> tests are nice to have, when they work :)
<barry> :)
 * dobey glares at squid and glibc 2.17
#ubuntu-devel 2013-02-09
<hallyn> infinity: say, do you think there would be any objection to adding MS_SLAVE (and friends) to /usr/include/sys/mount.h in lucid?
<hallyn> infinity: (this is regarding http://www.spinics.net/lists/netdev/msg225516.html)
<infinity> In... Lucid?
<infinity> hallyn: Explain to me why we care?
<hallyn> infinity: uh, ok! :)  someone running lucid with old libc but backported kernel?
<hallyn> so they want to do ip netns <wahtever>
<infinity> hallyn: The version of iproute2 in lucid (obviously) compiles fine in lucid.  Is there some motivation to backport, other than this dude who's building new software on an old release?
<infinity> hallyn: new kernels on lucid fail in lots of subtle (and not so subtle) ways.
<infinity> hallyn: Like, uhm.  udev.
<infinity> hallyn: So, again, tell me why we care?
<hallyn> well, we care bc really it's a dumbass bug in the layout of the .h files,
<hallyn> it's not liek the define wasn't there,
<hallyn> it was just not in the right place.
<infinity> Had nothing to do with layout.
<infinity> linux private headers != libc public headers.
<hallyn> we can argue one way or the other about this particular program, but MS_SLAVE is almost as old as i am
<hallyn> right, and MS_SLAVE should have been in libc
<infinity> And they're not always in sync.  And glibc clearly wasn't at that point.
<hallyn> right :)
<infinity> But my point is that "supporting new software on old releases" isn't an SRU target.
<infinity> And that's exactly what this is, since the old version of iproute2 demonstrably works.
<hallyn> but MS_SLAVE is so old that i argue it's not for "new" software
<infinity> It's for new software.
<infinity> Nothing in the archive needed it, or someone would have noticed.
<hallyn> no, this example just happens to be new
<hallyn> well no, someone would have done what i always did
<hallyn> and done #ifndef MS_SLAVE #define MS_SLAVE
<hallyn> all right, so the answer is now :)  i just wanted to be sure before responding
<hallyn> s/now/no/
<infinity> The answer is "there's no compelling reason".
<hallyn> (i'm not exactly heavily invested in this, it's just somethign that bugged me witg glibc from oh say 2006-2010)
<infinity> If it bugged you in 2006, there was plenty of time to fix it before 2010. :P
<hallyn> #ifndef :)
<hallyn> thanks - happy friday night
<infinity> lucid's missing a lot of those flags.
<infinity> Some far more interesting.
<infinity> Like, MS_MOVE.
<infinity> So, I'm going to again go with "run precise instead".
<hallyn> (it used to miss several syscalls plus the newer CLONE_NEW* too)
<infinity> I dunno.  If there's a reason to do a more drastically interesting SRU, we could cue up some minor header syncing.
<infinity> But I'm not sure it's worth the effort.
<hallyn> no no.  i'm with you.
<infinity> And most upstreams will say the same thing, really.
<infinity> Heck, I got laughed at by benh for running an "ancient" 3.2 kernel.
<hallyn> i'm just happy things are more in sync nowadays
 * hallyn out
<infinity> tjaalton: FYI, in your next xorg-server merge from Debian, don't miss the changes from my last upload.
<tjaalton> infinity: which one was that?
<infinity> tjaalton: http://launchpadlibrarian.net/130794589/xorg-server_2%3A1.13.2-0ubuntu1_2%3A1.13.2-0ubuntu2.diff.gz
<infinity> tjaalton: Basically just a revert of our delta (hence the build-dep patch being more than one line, cause it reverts to being the same as Debian for easier merging)
<tjaalton> ah
<tjaalton> we're staging the next bump on a ppa, I'll merge that in
<infinity> tjaalton: After finishing the audit MIR, I felt the urge to go undo all our no-audit deltas, so we wouldn't forget.
<tjaalton> oh cool
<Marlinc> Hello is it possible to integrate my application into the Ubuntu online accounts system? So when a user logs in it gets added to the online accounts system and it can be managed from there
<mitya57> Marlinc: yes, see http://developer.ubuntu.com/resources/technologies/online-accounts/
<mitya57> and http://developer.ubuntu.com/api/ubuntu-12.10/python/AccountPlugin-1.0.html
<Marlinc> Okay nice I'll take a look
<Marlinc> And with Java mm.. I develop my application in Java so it can run on Ubuntu, other Linux distro's, Windows and Mac OS X
<Marlinc> Is it possible to do those things with Java or is there another good alternative to Java that can be easily used on all of those platforms?
<mitya57> no, that API is not available for Java
<mitya57> Python works on all systems :)
<mitya57> You can also try to use JavaScript, the API should be available there through GObject Introspection
<Marlinc> Well okay Python is nice it is supported on all platforms
<Marlinc> And provides Ubuntu integration
<Marlinc> Okay I just saw Jython
<Marlinc> Can I use it to access the Ubuntu API's from Java
<Marlinc> Ah jvm I think mm
<mitya57> Marlinc: I'm not sure, you can try :) AFAICT, it implements an old Python syntax (~2.6), and nobody actually builds modules for it...
<Marlinc> Ah..
<Marlinc> Well is there a more lower way of communicating with those APIs? So I can implement a basic thing in Java
<mitya57> Marlinc: I believe signond has some D-Bus API, but I don't see it documented anywhere
<Marlinc> Mm okay
<Marlinc> And how about lenses and scopes
<mitya57> The same I think. The only D-Bus API that is documented is the Launcher API (https://wiki.ubuntu.com/Unity/LauncherAPI#Low_level_DBus_API:_com.canonical.Unity.LauncherEntry), but with note "do not use it"
<Marlinc> Ah..
<mitya57> But you better ask on #ubuntu-unity about that
<mitya57> (not on weekend)
<Marlinc> Okay
<Marlinc> Well luckily it is vacation next week
 * mitya57 has to go away now
<Marlinc> In The Netherlands at least
<Marlinc> Cya
<vibhav> seb128: ping
<vibhav> Actually, Is anybody from the Nexus 7 team available?
<shar> slangasek, are you in-charge of the foundations-r-wubi-publishing specification?
<Judith> What is adult novelty?
<Judith> What is adult novelty?
<vibhav> infinity: Was autopkgtest inspired when you uploaded a broken version of dpkg?
<Gaga> Please tell me where ubuntu-core-12.10-core-armhf.tar.gz includes Kernel or it is only rootfs? I wont to run it on i.MX53 Quick start board
<panzersajt_> Hy I have seen that canonical will release ubuntu for mobiles phones and I have seen that the refernce phone is based on omap4460. I have a omap4460 based tablet. I would like to ask weather it will be possible to install ubuntu mobile on it? It has same display resolution 1280x800 so that should be a problem (with working drivers of course)
<Gaga> As I know Ubuntu Phone source is not released yet????
<panzersajt__> no it is not but it will be during the MWC at the end of this mounth
<Gaga> As I know it will mostly intended to use with development boards (such as Pandaboard ES, Beagle board ...)
<Gaga> Even if it will available for your phone it will have tons of bugs
<Gaga> Please tell me where I can download Ubuntu Core source tarball? if available
<cjwatson> vibhav: Um, infinity didn't write autopkgtest ...
<cjwatson> Gaga: You need to add your own kernel.  https://wiki.ubuntu.com/Core
<cjwatson> Gaga: The source is simply the corresponding packages in the Ubuntu archive
<cjwatson> (i.e. "apt-get source <whichever package you're interested in>")
<Gaga> cjwatson-- but it is not a package, it is olso with apt get?
<cjwatson> There's no package for ubuntu-core itself - it's just a tarball assembled from lots of other packages
<Gaga> cjwatson-- Thank you for answer, Please can you give me a direct link to single tarball?
<cjwatson> (Though it's built using the live-build package)
<Gaga> cjwatson-- Ubuntu Core X86 olso needs to add kernel?
<cjwatson> Yes
<cjwatson> Gaga: http://cdimage.ubuntu.com/ubuntu-core/releases/12.10/release/ubuntu-core-12.10-core-armhf.tar.gz
<Gaga> cjwatson-- I wont to run it on i.MX Quick Start Board R, I have kernel and rootfs patches from freescale
<cjwatson> I'm not an expert on this, but since that's ARMv7-based I don't see why that would be too problematic
<Gaga> cjwatson-- It there any additional configuration necesarry except applyng patches to original kernel from kernel.org and to this rootfs?
<cjwatson> You'll have to arrange to boot it somehow; but I'm afraid I don't know more details
<cjwatson> The wiki page I pointed you to above has some general guidance
<Gaga> cjwatson-- Building linux image for Freescale board first time was big trouble for me, I seen there is a few image builders like Buildroot and ELDK but they are too complex and work using them is not much easier than without them.
<Gaga> cjwatson-- I am planning to launch new open source project like that
<BadDesign> Where is the documentation for writing applications in GJS for Gnome 3?
<Gaga> https://live.gnome.org/Gjs
<Gaga> You have seen this page?
<BadDesign> Gaga: yeah, but where is the documentation for JavaScript? I don't want to read the C docs to use GObject
<infinity> vibhav: What Colin said.  I had nothing to do with autopkgtest.  Also, I'd never upload a broken dpkg!  *whistles innocently*
<cjwelborn> nobody is talking about ubuntu development?
#ubuntu-devel 2013-02-10
<penguin42> it tends to be rather quiet at the weekend, especially late in European times
<cjwelborn> ah, i see. okay then, see you later.
<philwyett> Hi, Are there any notes on upgrading to the LTS quantal stack being made available when 12.04.2 is released?
<ogra_> philwyett, just make sure to have all updates installed, you will be automatically on 12.04.2
<ogra_> (check with lsb_release -a)
<philwyett> ogra_: That is not the case is it. On an already installed system, the move to the new stack is optional?
<ogra_> the move to a different kernel and xserver is ... but you are automatically getting to 12.04.2
<ogra_> (these are unrelated things)
<philwyett> ogra_: Normal updates are fine. It is the move to the complete new stack I am wanting to know if an guidance docs will be provided.
<philwyett> s/an/any
<ogra_> ah, k, that i dont know
<ogra_> but i'd guess so ;)
<philwyett> I'd hope so. ;-)
<philwyett> I have just installed the feb 10 alternate image in a VM. While it is installing the LTS quantal 3.5. kernel. It is still installing mesa 8.0.4.
<melodie> hello
<melodie> I would like some help on a little thing
<melodie> trying to make a custom versions, I would like in a Openbox one and in Lubuntu to have icons on the desktop (two icons). I have got them with a script in the casper directories, : it works in the live, but does not follow after install once the name "Desktop" is changed to the one used in the language. any thoughts on that ?
<Bluefoxicy> okay why the heck am I getting corruption.
<penguin42> what type of corruption, where?
<infinity> penguin42: He's being led down the path of temptation and sin toward a decadent life filled with glazed donuts and Brazilian barbecues.  Obviously.
<infinity> Great, I just made myself hungry.
<penguin42> hmm donuts
<Bluefoxicy> Are there docs on how Debian and Ubuntu infrastructure work?
<Bluefoxicy> I have no clue where to start building a build server, and google is unhelpful.  All I know is folks submit debs and they wind up in the repositories, and there's some automated magic between and somebody manually accepts the deb.
<penguin42> Bluefoxicy: On the ubuntu side isn't most of it driven via lp or something connected to it - i.e. can you follow the source?
<Bluefoxicy> penguin42:  nod.  On Debian it seems to be buildd and such--which I had quite a bit of trouble discovering via google but :|
<penguin42> Bluefoxicy: To ask a silly question; but wth are you setting up a buildd?
<infinity> Bluefoxicy: Debian is dak/wanna-build/buildd/sbuild, Ubuntu is launchpad/launchpad-buildd.  You probably don't want to use either for a small local archive.
<Bluefoxicy> Eh.  I don't understand how either works.  It gives me the willies.
<Bluefoxicy> I hate relying on magic blue smoke
<penguin42> Bluefoxicy: Well it's fine if you don't let it out
<cjwatson> sbuild itself is all packaged and such and pretty easy to get to work for single source packages, at least
<Bluefoxicy> nod.
#ubuntu-devel 2014-02-03
<mwhudson> i am now trying not to sign up for my isp's 130/10 package
 * RAOF will (hopefully) be shortly signing up for Internode's 100/40 package. And resisting the temptation to go for the 1000/400 package.
<spec4d> I successfully managed to patch an USC bug, and test it on my local machine but I have no idea how to submit it......
<steveire> Who knows how this bug needs to be re-sectioned? https://bugs.launchpad.net/ubuntu/+bug/1275506
<darkxst> steveire, ubuntu-website project, however I am not sure that is a valid bug, codenames are used after release pretty much everywhere
<pitti> Good morning
<steveire> darkxst: Thanks. How do I change it?
<steveire> I think I got it.
* pratchett.freenode.net 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:
<cyphermox_> ev: what thinkpad model do you have? is it a X230?
<ev> cyphermox_: x61
<ev> 2007
<cyphermox_> ok, so totally not the same device I have
<cyphermox_> I can't reproduce the issue here; could you bring your laptop over tomorrow so we can look at it?
<cjwatson> tseliot1: Thanks for the fglrx/nvidia verifications.  I've promoted everything now, with the exception of nvidia-settings-experimental-{304,310} which I believe are obsolete (bug 1076414) and nvidia-graphics-drivers-319-updates which has a v-failed bug according to http://people.canonical.com/~ubuntu-archive/pending-sru.html (bug 1222670, which looks familiar ...).  Let me know if I still need to do anything here before 12.04.4.
<tseliot1> cjwatson: that's correct, as we now use nvidia-settings for all the drivers. Thanks!
<cjwatson> tseliot1: Which is correct - you mean that those packages don't need to be moved to -updates for 12.04.4
<cjwatson> ?
<cjwatson> (Just trying to be clear as we're running out of time.)
<tseliot1> cjwatson: what I meant to say is that nvidia-settings-experimental-$VER have been replaced by the nvidia-settings package (i.e. they should be transitional packages now)
<cjwatson> tseliot1: Right.  nvidia-graphics-drivers-319-updates was the other part of my comment
<tseliot1> cjwatson: same as above. nvidia-319-updates is also a transitional package for nvidia-331-updates
<cjwatson> OK
 * cjwatson scratches off another set of blockers
<kirkland> hmm, I'm trying 'sudo do-release-upgrade -d' on 13.10, and getting:
<kirkland> Checking for a new Ubuntu release
<kirkland> No new release found
<dholbach> didrocks, salut mon ami - comment Ã§a va? in the last comment of https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1237045 it says "Package build configuration needs to be changed to use trunk." - do you know who could do that?
<ubottu> Launchpad bug 1237045 in Ubuntu UI Toolkit "Ubuntu UI Toolkit no longer builds on precise, quantal and raring" [Critical,Confirmed]
<robert_ancell_> seiflotfy__, is anyone maintaining lp:activity-log-manager?
<robert_ancell_> ev, ^ you perhaps? I have some MPs
<seb128> @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: seb128
<didrocks> dholbach: hey! it's just abot releasing ubuntu-ui-toolkit trunk, that upstream needs to request, test and so onâ¦
<dholbach> didrocks, cjohnston said that he'd chase it from the CI side
<didrocks> dholbach: yeah, it's really up to upstream to ask for a release and drive this
<ev> robert_ancell__: it's been a very long time since I've looked at it
<ev> I'd volunteer to review, but with the sprint last week and being on holiday tomorrow, I'm afraid I just don't have time
<robert_ancell__> ev, np. I think it's mostly abandoned so I'll look at getting permissions and updating it directly
 * ev nods
<pitti> dobey: does the weird failure in https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntuone-storage-protocol/11/ARCH=i386,label=adt/console tell anything to you?
<pitti> dobey: "ImportError: cannot import name _net_proto2___python" from trying to import "from google.protobuf.internal import _net_proto2___python"
<dobey> pitti: was there a new google protobuf upload?
<pitti> dobey: that looks like our protobuf might have gotten broken?
<dobey> pitti: yes
<pitti> dobey: yes, https://launchpad.net/ubuntu/+source/protobuf/2.5.0-5ubuntu1
<pitti> dobey: it's still stuck in -proposed
<dobey> pitti: ah, well it least it didn't get magically promoted despite the failure :)
<dobey> like twisted did
<dobey> pitti: so, looks like a regression in protobuf
<pitti> yeah, the new version makes a ton of packages uninstallable (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
<pitti> dobey: ack, so this failure looks legit; thanks
<pitti> run-adt-test -sU ubuntuone-storage-protocol
<pitti> that still succeeds (that's not using -proposed)
<dobey> pitti: it seems to just be the cpp implementation that broke though
<pitti> slangasek: ^ FYI
<dobey> pitti: we run the tests with the cpp protobuf python module as well, as we use that on the server side.
<dobey> pitti: the python tests passed, and then the attempt to run them with the cpp module failed
<pitti> dobey: ah, so perhaps this merely needs a rebuild against the new version, like https://launchpad.net/ubuntu/+source/protobuf-c/0.15-1build1
<dobey> pitti: what needs a rebuild?
<pitti> ah no, python-ubuntuone-storageprotocol is arch: all
<dobey> right
<pitti> I thought you meant that there were some compiled protobufs in there
<dobey> no, the protobufs get rebuilt every time with protobuf-compiler, but protobuf has multiple ways of using protobuf in python
<dobey> you can use the pure python modules, or the cpp module which is supposed to be faster
<dobey> it looks like something broke the cpp module compatibility
<dobey> internally in protobuf
<slangasek> pitti, dobey: "the cpp module" - that seems to have been dropped upstream in favor of the pure python one?
<dobey> slangasek: then the python-protobuf package is a bit busted, as it keeps the cpp_messgage.py but doesn't modify that to maintain compatibility by simply using the pure python version instead
<dobey> and it should if that is the intent
<dobey> and probably issue a DeprecationWarning
<slangasek> dobey: ok, can you file a bug about this and assign it to me for follow-up?
<dobey> slangasek: i'm curious, did you get an e-mail about ubuntuone-storage-protocol autopilot failing due to your protobuf upload?
<pitti> no, our jenkins machinery isn't that clever yet
<pitti> it sends it to the last uploader of the package that fails
<dobey> oh
<dobey> very non-clever
<pitti> and to me and jibel, so ATM we poke/ask people on failures like that
<seiflotfy__> hi robert_ancell__
<seiflotfy__> currently no one is maintaining activity log manager
<robert_ancell__> seiflotfy__, ok
<seiflotfy__> robert_ancell__: i can give you access rights if you want
<robert_ancell__> seiflotfy__, awesome, thanks
<seiflotfy__> you can take over and merge your stuff
<seiflotfy__> I am releasing the new zeitgeist later today btw :D
<robert_ancell__> nice
<dobey> slangasek: https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1275826
<ubottu> Launchpad bug 1275826 in protobuf (Ubuntu) "Version 2.5.0-5ubuntu1 breaks python code using the cpp module" [Undecided,New]
 * dinh_nguyen 
<ScottK> Does anyone know what #define __NR_fanotify_init    and #define __NR_fanotify_mark values should be for arm64? https://launchpadlibrarian.net/164564783/buildlog_ubuntu-trusty-arm64.clamav_0.98.1%2Bdfsg-1ubuntu2_FAILEDTOBUILD.txt.gz Upstream only provides x86 values.  In Debian we added values for the Debian archs, but arm64 isn't currently one of them.
<slangasek> ScottK: why do you need to shadow these definitions at all? these should come from standard kernel headers
<ScottK> I'm not sure why upstream started using them.  It's in a file that's new this release.
<slangasek> ScottK: so syscall number definitions should all come from the kernel headers
<stgraber> slangasek: that's a nice theory which unfortunately isn't always true... we had to do the same kind of trick (ifdef __NR_... + arch-specific defines) in LXC because of some RedHat based distros and Android where some of the newer syscalls are misisng the __NR_ defines...
<ScottK> clamav-0.98.1+dfsg/clamd/fan-syscalllib.h is where the code lives.
<ScottK> (trusty-proposed ATM)
<slangasek> stgraber: it's fine for an upstream to provide compat definitions for building on older releases, but our kernel headers are right and the upstream should only worry about defining it if not already defined
<ScottK> I also didn't find them defined in the Ubuntu arm64 kernel.
<slangasek> ScottK: I find them defined in /usr/include/asm-generic/unistd.h from linux-libc-dev on arm64
<slangasek> #define __NR_fanotify_init 262
<slangasek> #define __NR_fanotify_mark 263
<ScottK> OK.  Thanks.
<ScottK> I must have looked the wrong place in git.
<stgraber> that's odd, because the upstream .h is including unistd.h so they should have been defined then...
<ScottK> So the bug is they don't check if it was already defined.
<stgraber> oh, doh, misread the upstream code, yeah, they should ifdef the __NR_ then if not defined, ifdef the architecture and define them
<stgraber> s/ifdef the architecture/check the architecture/
<ScottK> I think I can fix that.  Thanks.
<Laney> hey you guys, cross building is pretty good
<seb128> Riddell, hey, do you have any news about the calligra trusty build?
<seb128> Riddell, if that's still blocked, what do you think about removing the current proposed version, upload a no change rebuild of the old one to complete the poppler transition?
<pitti> adam_g`: did you notice that your recent python-troveclient is still stuck in -proposed? its autopkgtest fails as the new version doesn't have an /usr/bin/trove-cli any more
<pitti> adam_g`: just /usr/bin/trove now; is that the "new" -cli, or something else?
<pitti> adam_g`: ah sorry, that was zul
<Riddell> seb128: fosdem got in the way, tomorrow I promise
<seb128> Riddell, thanks
<asac> any IRC OP around?
<asac> ubuntu-touch gets spammed
<asac> cjwatson: slangasek: ?
<xnox> asac: #ubuntu-irc for irc ops.
<cjwatson> ops are channel-specific
<cjwatson> /msg chanserv access #ubuntu-touch list
<asac> kk
<asac> the guy just wanted attention it seems
<seb128> @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:
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<slangasek> cjwatson: hmm, so grub-install has been rewritten in C?
<slangasek> cjwatson: fwiw grub-install --uefi-secure-boot seems to not be working right for me in 2.02~beta2... switched my disk to UEFI when installing in my new laptop (yay), but shim isn't getting installed
<dobey> has anyone else noticed that Xorg is leaking memory like crazy in trusty?
<slangasek> dobey: not here
<dobey> slangasek: what video driver?
<dobey> i'm on intel here
<dobey> maybe it's a bug in the driver.
<slangasek> dobey: intel
<dobey> hmm
<dobey>  4210 root      20   0 1580884 1.042g 281312 S   0.7  7.1  48:59.29 Xorg
<dobey> slangasek: do you use firefox, or chromium?
<slangasek> dobey: firefox
<dobey> slangasek: does it sometimes go crazy and use up 300% of your cpu and refuse to exit, too?
<slangasek> dobey: no
<slangasek> rather, I've seen something like that in the past, but I think that was during the saucy dev cycle
<dobey> it's been happening quite a lot for me on trusty :(
<beuno> dobey, I'm getting constant freezes in FF
<beuno> it blames gmail's gtalk javascript
<dobey> and i'm not sure how to describe the issues exactly in a bug report, since i don't know how to force the problem to happen
<beuno> not sure if that's cause or symptom
<beuno> need to restart FF several times a day
<beuno> (has only started happening this last week)
<dobey> beuno: probably a symptom. at least, i don't actually use the gmail web interface, so i'm pretty sure that's not causing the problem for me, at least
<dobey> beuno: i've been having this since i upgraded to trusty. i have to pkill -9 firefox every time i quit it, or sometimes it'll stick around, eat up all my cpu, and complain it's already running when i try to run it again
<dobey> maybe compacting all the sqlite in the profile will helpâ¦
<slangasek> dobey: protobuf 2.5.0-5ubuntu2 uploaded.  Does ubuntuone-storageprotocol need any other changes to adapt, or just a retry?
<dobey> slangasek: if it makes the cpp_message.py just use the pure python, i'd think it just needs a retry, which the new upload should trigger.
<slangasek> dobey: hum, rather I dropped the cpp_message.py ... since the filename implied it was specific to the cpp module
<dobey> slangasek: oh :(
<dobey> slangasek: i suspect a lot of packages will need changes then, as pitti said the protobuf upload was causing a lot of build failures
<dobey> although the list in the proposed-migration output is a bit weird
<dobey> and ironically, ubuntuone-storage-protocol isn't even in that list
<slangasek> dobey: no, pitti said that the protobuf causes uninstallability issues in trusty - because it's an in-progress transition
<slangasek> dobey: and ubuntuone-storage-protocol isn't in the list because python-protobuf's package name hasn't changed.  If you like, I can have python-protobuf declare a versioned Breaks: on the old ubuntuone-storage-protocol
<dobey> slangasek: are we certain that nothing else in the archive is using the cpp module?
<slangasek> dobey: the only revdeps of the package in the archive are python-protobuf.socketrpc and python-ubuntuone-storageprotocol
<dobey> slangasek: i'll remove the usage in u1 and do an upload for it
<slangasek> dobey: sounds good, thanks
<dobey> oh maybe i won't have to
<dobey> it handles ImportError already where it tries to import cpp_message
<dobey> so it should just work with the new upload
<infinity> kees, pitti, slangasek, stgraber: TB?
<jtaylor> hm should I be worried that I picked up a linux 3.11.0-17.30 during upgrades but it doesn't show up in launchpad?
<sarnold> jtaylor: did you subscribe to this ppa? https://launchpad.net/~canonical-kernel-team/+archive/ppa
<jtaylor> no
<jtaylor> I upgraded to that linux on two machines I use
<jtaylor> just noticed because I wanted to run perf but linux-tools for 17 doesn'T exist
<jtaylor> no ppas that provide kernels activated, but I do have proposed on
<sarnold> ah
<sarnold> an emergency kernel update last week superceeded a kernel from -proposed, I believe it was deleted to simplify matters
<jtaylor> hm ok, so I better remove the 17 version?
<sarnold> jtaylor: see e.g. http://www.ubuntu.com/usn/usn-2096-1/ -- you may wish to install that kernel manually to patch the hole
<sarnold> jtaylor: yeah
<slangasek> dobey: do you want a Breaks: from python-protobuf?  Otherwise, I'm going to work on getting mir rebuilt and the library transition done
<dobey> slangasek: no, i don't think it is necessary
<slangasek> dobey: ok
<dobey> slangasek: and it looks like the autopkgtest just finished and passed, for ubuntuone-storage-protocol
<slangasek> dobey: awesomesauce
<dobey> and compacting the sqlite didn't help firefox :(
<slangasek> so that should get us the new protobuf in, just as soon as we manage to find the publisher again
<roaksoax> slangasek: howdy! are you on archive admin duty today?
<roaksoax> slangasek: can you please process crochet and maas-test from the trusty NEW queue, if you  are?
<slangasek> roaksoax: ah, we've more or less stopped having archive days, but I can have a look
<slangasek> roaksoax: (basically, you can ping any AA if you need NEW help)
<roaksoax> slangasek: I see! Cool! And thank you!
<slangasek> roaksoax: maas-test doesn't include the text of the license; for AGPL-3 you have to include the whole license text, it's not one of the licenses in common-licenses
<roaksoax> slangasek: ok, thanks for pointing that out. I'll get that fix!
<slangasek> roaksoax: also, please use compat level 9, not the (ancient) 7
<slangasek> (with corresponding fix to the versioned build-dep0
<slangasek> )
<slangasek> roaksoax: if this is all new code, why is it python2 instead of python3?
<roaksoax> slangasek: so copyright should include all this document? http://www.gnu.org/licenses/agpl-3.0.txt
<roaksoax> slangasek: cause MAAS is still python2 and this is only to test MAAS
<roaksoax> slangasek: it will support python3 once MAAS does too
<slangasek> ah, it imports apiclient, ok
<slangasek> roaksoax: and yeah, that's the correct license to be included
<roaksoax> slangasek: ok uploaded a new maas-test package
<slangasek> hrm, why is someone changing the moderator password for the techboard list?
<sarnold> slangasek: mistake, see #is
<slangasek> ah, k
<slangasek> roaksoax: minor bug, not a blocker for new, crochet debian/copyright lists a wrong copyright; Gavin wouldn't be a copyright holder here, certainly not with an @canonical.com contact address :)
<roaksoax> slangasek: ok :). Thanks for taking care of it though! :)
<hallyn> hm, i have a cgmanager.8, and debian/cgmanager.manpages contains "cgmanager.8".  So why does it get installed as cgmanager.1?
<infinity> hallyn: What does the header in the manpage itself say?
<stgraber> hallyn: pass -s 8 to help2man
<hallyn> infinity: oh heh, thanks
<hallyn> stgraber: yup, thanks.
<shadeslayer> Could somene look at the arm64 and ppc64el errors on https://launchpad.net/ubuntu/+source/gcl/2.6.10-1
#ubuntu-devel 2014-02-04
<infinity> shadeslayer: It's a compiler, it needs porting/bootstrapping.
<pitti> Good morning
<pitti> Good morning
<RAOF> pitti: Good morning.
<pitti> hey RAOF, how are you?
<RAOF> pitti: Is there any particular reason why umockdev_testbed_add_from_{string,file}() don't return the sysfs path like umockdev_testbed_add_device does?
<RAOF> pitti: I'm pretty rad.
<pitti> RAOF: well, *which* sysfs string?
<pitti> a file usually contains a lot of devices
<RAOF> Oh, yeah. Multiple devices in there.
<RAOF> Question answered!
<pitti> I thought about that, but if you only have a single device then add_from_* isn't really more useful than a simple add_device()
<RAOF_> pitti: What do you think of adding the device node used to record the ioctls to the umockdev ioctl dump? Then your dump could create the device and populate the ioctls without manual futzing.
<pitti> RAOF_: so, like a merged .umockdev and .ioctl format?
<RAOF_> pitti: Either that or enough info in the .ioctl that it can be matched up with the umockdev on load.
<pitti> RAOF_: I'd like to at least keep the possibility of separate formats as that's useful (you may want to change device properties or the device names, but keep the ioctls; or load different ioctls/scripts for the same devices, etc.)
<pitti> and their formats are quite different
<pitti> RAOF: so asked the other way around, how should that look like in pseudo-code from your POV?
<RAOF> From the API point of view, or internal?
<pitti> from API, i. e. for you as a user
<pitti> right now, you load the devices from .umockdev
<pitti> and then assign a script or an ioctl dump to a particular device
<pitti> (or several)
<RAOF> umockdev_testbed_add_from_file(foo.umockdev); umockdev_testbed_load_ioctl(foo.ioctl); where foo.ioctl was generated at the same time as foo.umockdev
<pitti> ah, so keep the files separate
<pitti> RAOF: so with load_ioctl(foo.ioctl, NULL) it could look up the original file
<RAOF> Yah.
<pitti> or with (foo.ioctl, "/dev/bus/usb/...") an arbitrary one
<RAOF> Yeah.
<pitti> RAOF: ok, so the script and ioctl formats have room for this kind of extension, and that wouldn't break API/ABI
 * RAOF isn't entirely sure why you'd want to play the ioctl from an arbitrary devnode, but you probably have a better grasp of the usecases.
<pitti> RAOF: well, in my tests (shotwell etc.) I usually don't want to change the test device nodes when I refresh or change the ioctl dump
<pitti> RAOF: but when I re-do ioctls, the device numbers are usually entirely different than at the time of the previous recording
<RAOF> Ah, ok. See! Usecase :)
<pitti> and often tests use devices like /dev/bus/usb/my_cam
<pitti> which are easier to follow in  logs, etc.
<RAOF> Yeah, that seems reasonable.
<pitti> RAOF: so yes, I think a NULL argument seems possible at first sight; mind filing an issue for this?
<RAOF> pitti: Sure
<RAOF> pitti: Enjoy: https://github.com/martinpitt/umockdev/issues/33
<pitti> RAOF: heh, thanks
<comander> hello there
<comander> i want help regarding Qt i want get the output of a process that i evoked via my Qt app
<comander> via QProcess and want to get output  either in QtextEdit widget or something else that could do same
<zyga> Hi. My package got MIR-ed into main but now it is back in universe. Can anyone help me figure out why did that happen? https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1265754/comments/4
<ubottu> Launchpad bug 1265754 in plainbox (Ubuntu) "[MIR] plainbox" [Undecided,Fix released]
<pitti> zyga: there's nothing to hold it in main
<pitti> zyga: you need to add it as a dependency of something in main, or seed it
<pitti> zyga: otherwise it'll be in component-mismatches and re-demoted quickly
<mlankhorst> do I need to file a MIR for some xorg-server 1.15 dependencies too?
<zyga> pitti: thanks for confirming that, it was our suspiction all along
<jpds> Surely you should file a MIR for mir?
<zyga> pitti: will it be automatically re-promoted once that dependency shows up?
<zyga> pitti: (it will shortly)
<pitti> zyga: yes; please set back the MIR bug to "Fix committed", so that the archive admins can find it
<zyga> pitti: thanks
<Unit193> jpds: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207
<ubottu> Launchpad bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,Fix released]
<zyga> MIR MIR MIR ;)
<cjwatson> slangasek: yes, grub-install was rewritten upstream - it was getting beyond the bounds of what was sane to do in shell.  I thought I'd seen reports suggested that shim was being installed OK though.  The output of "grub-install -v" may be helpful - it should provide a reasonable trace of what grub-install is doing
<smoser> xnox, around >
<smoser> ?
<xnox> smoser: yeah, what's up?
<smoser> i'm looking at overlayroot and interaction with cryptsetup
<smoser> i'd *like* cryptsetup to always get the modules it needs.
<smoser> but faliing that, what can I / should I do
<xnox> set $CRYPTSETUP=y
<xnox> smoser: in /etc/initramfs-tools/initramfs.conf or otherwise when cryptroot-hook is executed.
<smoser> xnox, but i can't really update that.
<smoser> from one package, updating another package config.
<xnox> smoser: true.
<xnox> smoser: or i'll upload "CRYPTSETUP=y in cryptsetup package if e.g. a cloud-initramfs hook exists.
<smoser> xnox, ?
<xnox> smoser:  where is overlayroot hook?
<smoser> theres an overlayroot hook
<smoser> cloud-intiramfs-tools
<smoser> but if you can change the default (which you previously un-set) is good with me.
<xnox> ev: Unable to locate package cloud-intiramfs-tools
<xnox> ev: Unable to find a source package for cloud-intiramfs-tools
<xnox> is it in trusty?
<smoser> cloud-initramfs-tools
<smoser> no package
<smoser> overlayroot is the package
<smoser> cloud-initramfs-tools is source
<xnox> got it.
<smoser> xnox, so you're just going to turn CRYPTSETUP=y on ?
<xnox> smoser: yes, but only for overlayroot, not by default everywhere.
<smoser> how?
<smoser> i dont follow.
<smoser> i dont know how you'd do that
<xnox> smoser: i'm experimenting atm.
<smoser> k. feel free to quote bug 1267225
<ubottu> bug 1267225 in cryptsetup (Ubuntu) "initramfs in cloud-images does not contain crypt modules" [High,Confirmed] https://launchpad.net/bugs/1267225
<smoser> (ie, in the change log as the fix)
<xnox> smoser: /usr/share/initramfs-tools/conf-hooks.d/ is exactly where we should be able to set CRYPTSETUP=y, but when testing locally cryptroot is not executed / sourced at all so modules are not getting added.
<xnox> smoser: testing wubi at the moment, and will test this in a pristine machine next.
<smoser> xnox, i dont think it works like that
<smoser> all hooks don't work in a global environment
<smoser> that just wouldnt work.
<xnox> smoser: that's exactly how cryptsetup pulls in busybox & framebuffer (plymouth)
<smoser> thta just seems like a namespace nightmare
<soren> smoser: Actually, hooks are sourced, not executed.
<soren> smoser: So they do share environment namespace.
<ogra_> does cloud-initramfs-tools provide its own hook ? if so, just adding cryptsetup to the PREREQ var should work
<ogra_> (though that will indeed always pull it in)
<xnox> ogra_: true! thanks.
<mlankhorst> any MIR member on?
<jodh>  /go touch
<ogra_> yeah, there are some go apps on touch :)
<jodh> ogra_: :)
<smoser> xnox, did you test ogra_'s suggestion?
<bcurtiswx> mthaddon, did you want to work on the site issues at all today?
<mthaddon> bcurtiswx: I've spoken to the web team and they've suggested how I might be able to update the theme (needs a bit of manual work though) so I'll try to get to that today or tomorrow and let you know how I get on
<bcurtiswx> mthaddon, great, much thanks. If you want me at all i'll idle in our loco channel.
<mthaddon> thx muchly
<dobey> kenvandine_, robru: friends plug-ins are still all python right?
<kenvandine_> dobey, yup
<robru> dobey, yessir!
<dobey> kenvandine_, robru: is there a good example for doing read-only?
<robru> dobey, flickr / foursquare I think are simpler ones
<robru> dobey, probably flickr. it's slightly bitrotted at the moment, but the principles are sound
<dobey> ok
<robru> dobey, (like, it bitrotted against flickr's api. it demonstrates friends plugin api just fine)
<dobey> right
<mpt> cyphermox_, <https://wiki.ubuntu.com/Networking#captive-portal> and <https://wiki.ubuntu.com/Networking#settings-connections>
<roadmr> dholbach: hello! hey brendand was asking you some things about checkbox. To be more specific, checkbox (the source package) would sprout two new binaries, and one of the old ones (checkbox-qt) would likely turn into a dummy, transitional package. Is this allowed?
<dholbach> roadmr, yes
<roadmr> dholbach: awesome! \o/ thanks. One of the binaries is just moving some python modules off into a new package to make them reusable, so there's no huge change in size or functionality
<dholbach> roadmr, excellent
<roadmr> dholbach: thanks so much :)
<caribou> infinity: remember the makedumpfile merge, I may not be able to get the mods pushed into Debian before the debian sync freeze
<infinity> caribou: Was it just packaging changes you needed to push, or also a new upstream?
<infinity> caribou: And why not?  I can sponsor it for you, as I said.
<caribou> infinity: it's closing the delta b/w debian & ubuntu so they are the same
<caribou> infinity: I still need my sponsor to merge the changes into our master branch
<caribou> infinity: if not, we can merge the current code, it's minimal
<caribou> infinity: the difference is only the Arch in debian/control
<infinity> caribou: Alright, well.  I can merge with Debian for now, and then any packaging changes you make in Debian later, we can easily sync back.
<caribou> infinity: oh, I did the merge work, I'll only need sponsorship for the upload
<infinity> caribou: Or that.  Sure.
<infinity> caribou: You have a pointer to the source package?
<caribou> infinity: ok, I'll ping you for that once I'm done with the merge bug with the debdiff
<seb128> Riddell, hey, any news from calligra?
<seb128> Riddell, if not, can we just go with a no change rebuild from the previous version?
<seb128> that's blocking libreoffice 4.2 and other stuff to migrate (poppler transition)
<Riddell> seb128: just finishing up now
<seb128> Riddell, thanks
<Laney> \o/
<robert_ancell> seiflotfy__, can you add ps-jenkins to ~activity-log-manager so we can add CI?
<hallyn> hi - i'm trying to get a single source for debian+ubuntu qemu.  i need a different series file in the ubuntu case.  is there a decent way in 3.0 (quilt) to handle this?  (I'm told I can no longer manipulate this at patch: or build-stamp: time)
<Riddell> seb128: uploaded, fingers crossed
<seb128> Riddell, thanks
<ogra_> whee, thanks xnox for thinking of touch !
<ogra_> (saw ubuntu-touch-session)
<xnox> ogra_: remember, we test things before uploading ;-)
<ogra_> some actually do :)
<seb128> mardy_, hey, do you know what e-d-s files from /usr/lib/evolution-data-server/registry-modules are needed for uoa support?
<hallyn> infinity: hi, looks like seabios (1.7.4-1) has autosynced and is in trusty-propsoed.  can we, uh, kill it with fire for now?
<hallyn> infinity: the debian maintainer warns it'll break xen fro us
<smb> (because of xen xl using standard qemu which uses seabios)
<infinity> hallyn: It was FTBFS anyway, how much more killing with fire does it need?
<smb> infinity, disintegrate
<infinity> Oh, it wouldn't be FTBFS if someone retried it, looks like.
<infinity> So, we can file a bug to prevent it from migrating for now.
<hallyn> infinity: where/how do we file that?
<infinity> Is there a Debian bug reference for this?
<infinity> Or an Ubuntu one?
<smb> infinity, We could not think of how. Basically remove it from archive existence and prevent it from ever auto-merging for now
<hallyn> not yet
<hallyn> smb: where 'fro now' is until after 14.04
<hallyn> oh, bugs.debian.org/707454
<cjwatson> hallyn: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-October/001068.html
<infinity> hallyn: So, file a bug detailing *why* it's broken, and add the tag "block-proposed" to it.
<infinity> cjwatson: Oh, you beat me to it while I was finding the tag. :P
<infinity> hallyn: Erm, the way I read that bug, it's iasl that's the problem, not seabios.
<infinity> hallyn: As in, a rebuild of seabios (even in the "okay" version) would break.  That's unacceptable.
<infinity> hallyn: So, we should roll back iasl, probably.
<infinity> hallyn: Unless something else needs the newer version.  Then we should fix seabios.
<infinity> hallyn: Having the current combination of broken iasl and seabios that will break if rebuilt is a ticking time-bomb.
<smb> infinity, http://paste.ubuntu.com/6874200/
<smb> hallyn, Saving you the repeat...
<cjwatson> xnox: I think I've fixed guile-1.8, in case that's been on your list
<cjwatson> just test-building on ppc64el now to double-check
<infinity> smb: Oh, hrm, that doesn't seem to relate to the bug hallyn pointed out.
<infinity> 17:41 < mjt> only new qemu (from git) will try to load the 256kb version
<infinity> hallyn: ^-- Can't we pull that patch into our qemu?
<infinity> hallyn: That seems more future-proof than shipping an LTS that can't load the bigger BIOS files.
<hallyn> infinity: I'm nto sure the patch exists yet (checking)
<smb> infinity, I think he said later that qemu-2.0 will not be ready until April
<hallyn> i don't see a patch in qemu to address this
<hallyn> anyway if it is prefereable to let seabios continue to autosync and fix qemu if/when seabios builds and breaks xen-qemu, then i'm ok with that
<smb> infinity, Also it may add some "interesting times" for people migrating guests from older to newer guests... if that is possible ...
<hallyn> smb: an alternative would be to once again split off a xen-qemu :)
<hallyn> right
<smb> hallyn, bah
<infinity> smb: If that's true, it'll be true some day anyway, no point putting it off.
<smb> infinity, Yeah, thats a point
<infinity> Anyhow, I'd imagine the qemu fix to allow fatter BIOSes will be small, targetted, and easy to cherry-pick, once someone finds it.
<hallyn> optimist
<infinity> It makes little sense, to me, to hold off on that migration until post-LTS, and ship an LTS that can't load bigger BIOSes (which people developing ON Ubuntu might want to do).
<hallyn> ok, wont' file that bug then - thanks :)
<infinity> That said, this seems entirely unrelated to the iasl/seabios FTBFS bug that hallyn pointed at, which would need to be addressed before you have a big BIOS to worry about anyway. :P
<infinity> (And should be addressed regardless, since unbuildable packages in the archive are bad)
 * smb will be expecting the sky to fall down any day then :-P
<hallyn> infinity: yeah it looks like that's being worked
<Noskcaj> Could someone please review lp:~noskcaj/+junk/gnome-weather ? This package needs to be added for ubuntu-gnome
<Noskcaj> It cannot be uploaded via debian due to use of the CC-BY-2.0 license
<wget> Hi guys. On Ubuntu and derivatives, I noticed that the symbols defined at /proc/kallsyms are all zeroed when read as a standard user, but are the right location when read from root. Do you have applied a patch for that.
<wget> I checked with distributions and even compiled a kernel by myself and noticed all the symbols (or most of them) are readable by a standard user on these distributions.
<wget> You have thus enabled some extra to hide these symbols, noh?
<mwhudson> is there anyone around who is prepared to admit to understanding the libv8 packaging?
<dobey> wget: #ubuntu-kernel would be the place to ask that i think
<wget> dobey: :-( ok thanks, think I'm lost these days...
<xnox> mwhudson: i don't think anyone will admit that =) but what's your actual question about it? =)
<dobey> kenvandine: does friends-service integrate with messaging indicator, or is friends-app required for that?
<kenvandine> dobey, it doesn't
<kenvandine> either could
<dobey> kenvandine: ah, it would be great if it did. i'm writing a github plug-in. it would be great if the messages indicator could show counts for comments/pull requests/etcâ¦
<kenvandine> dobey, it would be great :)
<dobey> kenvandine: also, do you know if it's possible to tweak the display name for an online account after logging in with oauth2, in the gtk+ UI? the google qml plug-in has code that sets it, but that isn't used in the gtk+ ui. the vala google accounts plug-in doesn't do the same thing though
<kenvandine> i thought it did in the gtk one
<dobey> not that i can see from looking at the code
<kenvandine> dobey, maybe that was something magically done with signon-ui... i don't recall
<mwhudson> xnox: i'd like to build a libv8 package from a much newer upstream
<mwhudson> i think
<dobey> kenvandine: yeah i don't know. i don't want to add a google account either, because it does a million things i don't want and screws with evolution and such :)
<xnox> mwhudson: and the one in the archive is not using gyp yet, yet new upstream only support gyp based buildsystem?
<mwhudson> xnox: no, the one in the archive uses gyp i think
<mwhudson> xnox: i guess i don't understand git-buildpackage, maybe
<xnox> mwhudson: well, take new source code, copy across debian/ do "./debian/rules build"
<xnox> does that work?
<mwhudson> let's find out, i guess
<mwhudson> well that's going to build a libv8-3.14.5 that contains libv8 3.24.whatever
<mwhudson> which doesn't seem ideal
<Noskcaj> infinity, PING
<Noskcaj> I've just merged the new cogl release, could you test build it on ppc64el since the patch might be fixed. https://code.launchpad.net/~noskcaj/ubuntu/trusty/cogl/1.16.2/+merge/204787
<Noskcaj> powerpcel is now in the libtool.m4 and the patch doesn't apply
<mwhudson> uh, all this machinery does not appear to support building a libv8-3.24.31 package
<infinity> mwhudson: Renaming some files and munging debian/control isn't enough?
<mwhudson> infinity: well sure, but i had gotten the impression that the control munging was automated
<mwhudson> seems not though
<infinity> Automated control munging is usually not a sane idea, to be fair.
<infinity> Noskcaj: If the new upstream contains the bits from my patch, there's no need to test it.
<mwhudson> oh huh, the only difference between debian/control.in and debian/control is build-depends
<Noskcaj> infinity, It only says powerpcle rather than powerpc64el, plus i'd rather be sure
<infinity> Noskcaj: Erm.  Look closer?
<infinity> Noskcaj: Pretty much exactly this should show up in the new upstream: http://launchpadlibrarian.net/160371627/cogl_1.14.0-3_1.14.0-3ubuntu1.diff.gz
<infinity> Noskcaj: Where's the new upstream tarball?  Looking at the your MP diff is pretty close to useless.
<Noskcaj> https://download.gnome.org/sources/cogl/1.16/cogl-1.16.2.tar.xz
<mhall119> cjwatson: slangasek: so we've all more of less decided on naming SDK releases after ubuntu releases, so the next one won't be SDK 2.0, it'll be SDK Ubuntu 14.04
<mhall119> does that sound reasonable to you both?
<eagles0513875> hey guys I have a question is the arm port of 14.04 also supporting 32bit arm procs?
<infinity> eagles0513875: Yes.  "armhf" is 32-bit (armv7, hard-float)
<eagles0513875> infinity: ok :) thanks for the info :) need to do some research into this for a project of mine :)
#ubuntu-devel 2014-02-05
<RAOF> apachelogger: Yo!
<RAOF> apachelogger: Would you kindly re-upload muon to saucy-proposed, with both changelog entries in the .changes file? Thanks.
<infinity> cjwatson: Okay, seed shuffling done to remove kernel ABIs.
<infinity> cjwatson: In the end, the diff between old and new looks like so: http://paste.ubuntu.com/6876424/
<infinity> cjwatson: That will put two tiny < 1k packages on the CD, I suppose, but otherwise, looks harmless and generally correct, so I'm happy with it.
<infinity> cjwatson: (To be clear, that's a diff of germinate output, not the seeds)
<dupingping> how to contigure window reponse timeout?
<infinity> dupingping: This isn't a support channel, you want #ubuntu
<dupingping> yes
<YokoZar> infinity: I intended wine-mono to be multiverse alongside wine-gecko
<YokoZar> cjwatson: and I believe that note is already there
<YokoZar> The debian equivalent would be contrib (free software with a nonfree build dependency/build step, in this case the step on windows)
<infinity> YokoZar: Kay.  I'll re-review with that in mind, then.
<infinity> YokoZar: (would have helped if you had multiverse or non-free in debian/control, so the queue would have sent it there instead of universe by default, but I'll override)
<YokoZar> I didn't know the control file could contain that metadata
<YokoZar> sorry about that
<infinity> YokoZar: "Section: non-free/otherosfs" would be the Debian way (and out queue automatically does s/non-free/multiverse/) or, of course, "Section: multiverse/otherosfs" if it's just for Ubuntu.
<infinity> s/out/our/
<infinity> But no big deal for me to override it.  Would have just been nice to have the hint of intent. :)
<infinity> YokoZar: Do I want to know why the debian directories in these are almost as large as the orig?
<infinity> YokoZar: Or is that where the prebuild .msi lives?
<infinity> s/build/built/
 * infinity is still downloading... Having bandwidth issues tonight.
<StevenK> infinity: Did you move back to Australia and not notice?
<infinity> StevenK: I sure hope not.
<YokoZar> infinity: unless I accidently left stale files around again...
<YokoZar> infinity: but yes the prebuilt .msi file is in the debian changes
<infinity> YokoZar: Kay, that accounts for the hugeness, thanks.
<cjwatson> mhall119: I never understood the sense behind doing anything else in the first place :-)
<mhall119> thanks cjwatson
<cjwatson> infinity: yay, cute
<pitti> Good morning
<apachelogger> RAOF: muon with both entries uploiad to saucy-proposed
<pitti> Searching for GRUB installation directory ... found: /boot/grub
<pitti> /etc/default/grub: line 1: syntax error near unexpected token `('
<pitti> run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited with return code 2
<pitti> cjwatson: ^ is that known?
<pitti> that happens on our i386 trusty VMs since yesterday, and breaks a number of tests
<pitti> e. g. https://jenkins.qa.ubuntu.com/job/trusty-adt-ubiquity/164/ARCH=i386,label=adt/console
<cjwatson> not known
<cjwatson> what's in that file?
<cjwatson> also grub2 hasn't changed for about a week
<pitti> ok, if you didn't see it yet then this might be local to our VMs/cloud-init; I'll check
<cjwatson> certainly possible
<cjwatson> that seems like an unlikely kind of general problem
<pitti> /etc/default/grub is binary garbage in that VM
<pitti> ok, that certainly looks like a weird qemu/sun rays/whatever issue
 * pitti rebuilds that VM
<pitti> cjwatson: ok, sorry for the noise
<cjwatson> no problem
<asac> cjwatson: hi ... slangaseks protobuf upload broke the ABI accidentially i think
<asac> cjwatson: http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/dialer-app-autopilot/735638/
<asac> cjwatson: see once.h change here: https://launchpadlibrarian.net/164839352/protobuf_2.5.0-5ubuntu2_2.5.0-7ubuntu1.diff.gz
<asac> seems a sneaky ConstructorImpl through inline function exposure
<asac> oversight
<cjwatson> asac: I saw the scrollback in #ubuntu-ci-eng, but I kind of ought to be focusing on 12.04.4 today, so I'm not sure I have the bandwidth to come up to speed on a C++ library
<smoser> xnox, were you able to get anything functional for overlayroot
<cjwatson> perhaps somebody else could be found?
<asac> cjwatson: yeah. just looking for someone to confirm that this was a SONAME bump oversight and help to back it out :)
<asac> so we can refactor this or bump SONAME
<cjwatson> backing out will be very complex as it had to go in together with a bunch of other things
<cjwatson> at least I think that was that upload
<asac> cjwatson: hmm. whatelse?
<cjwatson> don't remember
<cjwatson> give me a few minutes
<asac> thanks. just check if there is a quick way out... otherwise let me know who I could ask :)
<cjwatson> oh, 2.4.1-3ubuntu4 -> 2.5.0-5ubuntu2 was the complex soname-bumping one
<cjwatson> we shouldn't bump soname without careful thought as this is used by rather more than just touch
<smoser> xnox, this is what i tried, but didn't seem to work: http://paste.ubuntu.com/6877895/
<cjwatson> asac: so now would be a great time for the suggestion I made of having a PPA used by touch which is allowed to be deliberately behind the primary archive for short periods of time, so we could copy the old version into it to get touch moving again while we diagnose the issue in the primary archive
<cjwatson> asac: which I don't suppose anyone's implemented :)
<cjwatson> it ought to be possible to stitch some kind of compatibility arrangement back in while still respecting the intent of the changes made for Debian #736801 (and maybe make sure symbols files cope with this, while we're there), but my C++ really isn't up to it
<ubottu> Debian bug 736801 in libprotobuf-dev "[libprotobuf-dev] __ATOMIC_RELAXED on ia64, sparc" [Normal,Fixed] http://bugs.debian.org/736801
<cjwatson> perhaps xnox might have time to take a look?
<cjwatson> or we could sort out a touch-specific reverting PPA real quick and punt the problem to the Debian maintainer
<asac> xnox: like some C++ magic hackery in the morning? :)
<cjwatson> since we should have such a thing anyway
<asac> we can talk about that in todays meeting
<cjwatson> I don't think I can make today's, I got three hours of sleep and I still have a bunch of stuff to do for 12.04.4
<cjwatson> also we've talked about it in previous meetings.  why more meetings?
<asac> cjwatson: are we sure that this problem is really touch confined? i sense we might have breakage all over the archive now
<asac> just that we see it here clearly
<cjwatson> I'm upgrading to see if mumble is affected, since it's a reverse-dep
<cjwatson> ah yeah, mumble fails to start
<asac> dont worry about the meeting. and dont worry about this problem if you are doing allnighters...
<cjwatson> as does ccsm
<asac> i just think the backout is the problem we should solve :) ... e.g. figure a way to find whatelse got uploaded alongside so we can just get all that car wreck off the autobahn while we investigate how to fix the protobuf patch
<cjwatson> ok, let me see if I can just back this out with a reupload; it wasn't a new upstream or anything
<cjwatson> there was nothing else alongside, that was my mistaken memory
<asac> right
<asac> i think it wasnt a SONAME bumop
<asac> so only what was built after or alongside could be affected
<cjwatson> indeed not
<cjwatson> xnox: (stand down, I'll deal with this until slangasek gets back)
<asac> we have invested heavily in getting folks out of ppas... its very hard for me to get a ppa back and then figure reasonable black and white rules that will ensure we use this ppa only exactly for the right cases
<cjwatson> you didn't raise that point in the last meeting when we talked about this :-(
<cjwatson> "may only be used to copy old versions from the primary archive pending better fixes" seems pretty clear
<asac> yeah sorry. not sure when we last talkeda bout it though
<cjwatson> couple of months ago I think
<asac> cjwatson: that sounds better. let me think about that
<cjwatson> after saucy, at least
<xnox> smoser: was busy uploading message-less shutdown, will look into overlayroot more today.
 * xnox read the rest of scrollback.
<cjwatson> the change in nm -C -D output (with the addresses removed) is http://paste.ubuntu.com/6877972/
<cjwatson> so I don't think we risk converse breakage by backing out the change
<asac> cjwatson: we should check all reverse build deps that got uploaded afterwards i guess
<asac> but beyond that it looks safe to me (but then i am very out of this)
<asac> wonder why we have a + AND -
<cjwatson> asac: well, if there are no new symbols (other than weak copies of libc stuff) we aren't going to break things by going back
<cjwatson> and that appears to be the case
<cjwatson> s/weak copies of/references to/
<cjwatson> the only + is a reference to pthread_once - that's not something libprotobuf *exports*, it's something it *imports*
<asac> yeah you are right
<asac> guess not bumping with - is generally scary as seen through the inline header leakage here ... this protobuf should really hide symbols that are Impl/Internal :)
<cjwatson> yeah, no doubt, too late now for this soname though
<cjwatson> ha, there's already a 2.5.0-8 in experimental which I think backs this out
<cjwatson> bacon sandwich then I'll check that
<asac> cjwatson: can we backout anyway? believe its better if steve can look at that with fresh eyes? :)
<xnox> cjwatson: i wonder if protobuf breakage transitively leaked into libmirprotobuf0 as well.
<asac> but your call
<asac> cjwatson: was that uploaded after?
<asac> err
<xnox> cjwatson: which is not easy to check, since mir is not using .symbol files =(
<asac> xnox: ^^
<asac> xnox: i can have someone try
<asac> :)
<asac> see if tests still pass etc. after downgrading
<asac> i think tvoss was on that task
<xnox> right.
<cjwatson> asac: 2.5.0-8 *is* the backout, might as well just mereg it
<cjwatson> *merge
<asac> cjwatson: righty
<cjwatson> http://paste.ubuntu.com/6877999/
<cjwatson> xnox: I'll poke it with nm in a bit
<asac> ok if the rest of the changes are safe (which we dont know)
<asac> but whatever is good :)
<cjwatson> they're safe.  our gcc is already 4.8
<asac> so yeah
<cjwatson> I bet the dialer-app tests don't work usefully in the emulator or on grouper
<cjwatson> xnox: mir was uploaded before the latest protobuf, so it should be fine
<pitti> (FTR, I tested the dialer-app tests on mako and in a trusty amd64 live environment, they ought to work)
<xnox> ack.
<asac> cjwatson: all other AP tests also fail
<asac> except the unity8 one
<asac> cjwatson: http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/
<asac> cjwatson: pick whatever works on emulatoor
<asac> xnox: ?
<xnox> cjwatson: weather_app is known to have been fully passing on the emulator.
<didrocks> asac: http://people.canonical.com/~ogra/touch-image-stats/20140205.changes
<asac> xnox: gallary?
<asac> http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/gallery-app-autopilot/
<didrocks> I don't know if location-service is getting worse than in 163
<asac> didrocks: saw my mail?
<didrocks> asac: yeah
<didrocks> but it's not protobuf, I guess, is it?
<asac> didrocks: tvoss is having a one line fix to get rid of the systemsettle part
<didrocks> ok
<asac> didrocks: thats in a mail from yesterday
<asac> didrocks: we just didnt know how to allocate a silo fo rhim
<ogra_> hmm
<asac> didrocks: ping him
<didrocks> asac: tvoos isn't around
<didrocks> tvoss*
<asac> didrocks: he is ... guess he dropped off freenode
<didrocks> ah
<didrocks> ok
<asac> err
<asac> he is indeed gone :)
<asac> talked to him a minute ago
<asac> no he is online
<asac> on canoni
<didrocks> yeah, I didn't see him on chans when joining
<ogra_> curious, the first protobuf update worked fine
<didrocks> pinged him
<didrocks> ogra_: right, what I answered
<asac> ogra_: protobuf broke abi
<asac> ogra_: withotu SONAME bump
<didrocks> but what's the diff between 163 and 64?
<didrocks> 164*
<asac> ogra_: is a sneaky symbol leak through inline header
<didrocks> we know location-service broke 163
<didrocks> not sure what broke 164 even more
<asac> didrocks: protobuf broke all the stuff
<ogra_> asac, protobuf bumped its api on monday
<asac> didrocks: http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/gallery-app-autopilot/735187/
<cjwatson> ogra_: different
<asac> didrocks: /usr/bin/gallery-app: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libmirprotobuf.so.0: undefined symbol:
<asac> _ZN6google8protobuf18GoogleOnceInitImplEPiPNS0_7ClosureE
<ogra_> cjwatson, k
<didrocks> asac: ok, not at that level yet
<didrocks> hum
<knome> seb128, hey, you around? what's up with xubuntu-docs; apparently 12.04.1 is not uploaded to precise? :/
<didrocks> so something built against the new protobuf
<cjwatson> can we stop talking about protobuf now?
<asac> didrocks: no..
<ogra_> there was a new Mir
<asac> didrocks: the new protobuf dropped symbols by accident
<ogra_> and new xorg
<cjwatson> I'm working on it and it's distracting to have to try to follow everyone catching up
<asac> right
<ogra_> (see backlog in -relkease)
<asac> didrocks: leave it to cjwats :)
<didrocks> ok ok
<ogra_> i dont get why i see neither of them on -changes
<didrocks> looking at location-service
<asac> didrocks: you might want to wade through the other failures that dont have the same symbol error in log
<asac> didrocks: and help tvoss land location-service
<asac> so tvoss confirmed that the AP test for addressbook at least starts if going back on protobuf
<didrocks> asac: wait, I'm trying to get back people on shape first
<didrocks> I can't do all analysis
<asac> didrocks: sure, read the backlog on irclogs to catch up if you want. otherwise we are working on the parts that we understand
<asac> (which probably is all)
 * ogra_ still wonders where the new mir went
<asac> didrocks: so i am going through all the failed tests... so far all bail out on this symbol
<didrocks> asac: thanks
<asac> didrocks: location is breaking systemsettle only (we saw that last night)
<asac> 163 has only ss
<didrocks> ogra_: don't even start on that one, another discussionâ¦ :p
<asac> lol
<ogra_> didrocks, well who would have guessed that xorg just gets updated in the middle of the landing
<seb128> knome, https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=xubuntu-docs
<didrocks> ogra_: I did, I pinged people to coordinate
<seb128> knome, somebody from the SRU team needs to approve it
<didrocks> ogra_: *before the landing*
<ogra_> didrocks, on the day the landing happened ... this should have been planned weeks ahead on both sides
<didrocks> ogra_: yeah, but it was read apparently and ignored
<ogra_> we lack a communication path for such things it seems
<didrocks> and lack of willness to fix things it seems, but anyway, I tried, I passed the messages between both parties
<ogra_> well, by the looks of it it all went fine in the end
<didrocks> anyway, moving on, we "just" loose a day for Mir
<ogra_> but sadly the packages didnt actually make it into the archive
<knome> cjwatson, any way you could approve the xubuntu-docs SRU?
<didrocks> ogra_: no, Mir is still not published
<ogra_> didrocks, right
<asac> didrocks: so i discussed this yesterday... what we need is communicating transitions in prep so folks know and can either wait or join the silo
<ogra_> is there still a MIR missing for some xorg deps ?
<asac> didrocks: and of course improve tools to auto bump stuff we pulled into silo for a transition
<asac> but that invalidates testing
<asac> so best coordinate/communicate
<tjaalton> ogra_: no, but all the drivers need to be rebuilt
<cjwatson> knome: for 12.04.4?
<knome> cjwatson, yes, i know it's late...
<cjwatson> knome: does it need to be on your images?
<ogra_> tjaalton, ugh, why didnt that happen in a PPA
<cjwatson> rather, is that package on your images?
<ogra_> so you can release the whole chunk
<knome> cjwatson, the .1 release is a regression fix for .0 SRU
<knome> cjwatson, yep
<cjwatson> knome: let me finish this protobuf thing first, then I'll look at it.  I guess you'll want a respin then
<tjaalton> ogra_: it did, but with version numbers not fit for the archive
<didrocks> asac: we can't autobump
<asac> so weather test failure doenst show this symbol thing http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/ubuntu-weather-app-autopilot/
<didrocks> asac: or we will revert the work done in distro
<asac> didrocks: I think we can ... lets talk about that later though :)
<didrocks> asac: the check is there on purpose
<knome> cjwatson, sure, thanks
<asac> remind me when we talk next time; i think i know what to do to be able to do that
<seb128> didrocks, asac, cjwatson: btw that protobuf issue is making compiz fails to start in trusty
<cjwatson> seb128: I'm dealing with it
<seb128> cjwatson, thanks
<asac> guess defcon 4 :)
<ogra_> unity8 still starts fine ... time that desktop switches :P
<cjwatson> War Games has rendered me irrevocably confused about which order defcon levels go in
<ogra_> cjwatson, asac uses the real numbering, not the movie one
<asac> i think 5 is nuclear war :)
<cjwatson> right, but knowing about the movie confusion means I can't remember which is which :)
<ogra_> (i still wonder why they reversed it ... obstruction by confusion ? )
<asac> yeah me too
<asac> http://en.wikipedia.org/wiki/DEFCON
<asac> so i was wrong
<asac> 1 is nuclear war
<ogra_> lol
<ogra_> "Movies and popular culture often misuse the DEFCON system by "going to DEFCON 5" when a nuclear war is imminent."
<ogra_> hmm, but nobody says *why*
<asac> so war games might have teached us wrongly?
<jpds> ogra_: Do you need an excuse?
<ogra_> jpds, well, i would love to know why that seems to be done in *all* movies and tv series this way
<ogra_> (seems thats the case)
<ogra_> i.e. if some authority ordered it like that to confuse the enemy or some such :)
<jpds> Well, noone used the old British one: https://en.wikipedia.org/wiki/BIKINI_state
 * ogra_ bets there is a funny story behind it that just never leaked
<doko> zyga, brendand: you seem to be checkboxuploaders ... there are at least 7 MIR's missing
<doko> you guys really need to better prepare such uploads
<brendand> doko, i guess this might relate to the branch roadmr prepared
<brendand> doko, is there a branch/bug specifically you're talking about?
<doko> brendand, before you start guessing, have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg ;p
<brendand> doko, oh i see
<brendand> doko, yes one of our binary packages depends on some sdk packages
<spineau> doko: Not sure if it's related but I filled two MIR for checkbox future deps, #1276164 and #1276183
<brendand> doko, i don't think we actually need to depend on cordova-ubuntu if that's the issue
<brendand> doko, we can look to remove that dependency
<doko> bug 1276164, bug 1276183
<ubottu> bug 1276164 in checkbox-support (Ubuntu) "[MIR] checkbox-support" [Undecided,New] https://launchpad.net/bugs/1276164
<ubottu> bug 1276183 in plainbox-provider-resource-generic (Ubuntu) "[MIR] plainbox-provider-resource-generic" [Undecided,New] https://launchpad.net/bugs/1276183
<doko> brendand, sure, that's an option
<brendand> doko, but can you help us with which source branch is being used which is generating those errors?
<brendand> doko, is it lp:ubuntu/checkbox?
<doko> brendand, spineau: is checkbox running with python3?
<pitti> seb128: speaking of MIR, could indicator-datetime stop recommending indicator-applet?
<brendand> doko, yeah
<seb128> pitti, it doesn't
<pitti> Recommends: indicator-applet | indicator-renderer
<doko> brendand, no branch, it is the package which was uploaded to the archive
<pitti> seb128: it does :)
<seb128> pitti, indicators recommend and indicator-renderer, with unity being our default option
<brendand> doko, yeah roadmr probably did that from lp:ubuntu/checkbox
<pitti> seb128: ah, so perhaps this should either become just "indicator-renderer" or "unity | indicator-applet | indicator-renderer"?
<seb128> pitti, unity provides indicator-renderer so it should be fine
<seb128> pitti, only a virtual is wrong, unity | would be right
<seb128> pitti, the issue atm if you look at component-mismatch is that unity didn't build yet on ppc64el
<seb128> pitti, so it resolves to indicator-applet
<pitti> seb128: ah, I understand
<pitti> seb128: thanks for pointin gout
<seb128> pitti, yw
<doko> spineau, looks like these two MIRs are just about code re-organization. so shouldn't be an issue
<tsdgeos> hmmm, something weird is happening with all qt4 bsed programs since today
<tsdgeos> i get
<doko> brendand, spineau: please make sure that checkbox runs with python3.4 , and that the tests pass
<tsdgeos> Compiled for arch: ::Vc::AVXImpl
<tsdgeos> Features supported:
<tsdgeos>          "SSE2"         ---      yes
<tsdgeos>          "SSSE3"        ---      yes
<tsdgeos>          "SSE4.1"       ---      yes
<tsdgeos>          "AVX "         ---      yes
<tsdgeos> any idea?
<tsdgeos> what is bringing that to my shell?
<brendand> doko, we were actually wondering that - thanks
<spineau> doko: ok, thanks. but after looking at the svg map the problem is elsewhere. we'll check what to do with this cordova package
<cjwatson> /wg 39
<cjwatson> sorry
<robert_ancell> bdmurray, hi, do you plan on doing a mass "wont fix" marking of bugs on https://bugs.launchpad.net/ubuntu/raring? Laney / seb128 suggested you'd do that
<zyga> doko: thanks, we'll look into this
<zyga> doko: I think we had a misunderstanding about how MIRs work and we dind't propose MIRs for recommends at all
<zyga> doko: we are working on those now
<brendand> zyga, well the problem packages are not ours
<brendand> zyga, they're sdk packages
<brendand> zyga, anyway we don't need to depend on it
<zyga> brendand: that's our problem if we're MIRing something that needs them
<zyga> brendand: we just need to figoure out what we need to depend on and what needs to be in main
<mitya57> tsdgeos: *All* Qt programs? That looks like calligra output.
<tsdgeos> mitya57: yes, even bzr qlog does output that
<mlankhorst> how often is the check running when doing dput uploads to ubuntu?
<cjwatson> every minute
<cjwatson> but LP was just doing a master database switch in preparation for a machine upgrade, so it might be slow just now
<mlankhorst> ah
<mitya57> tsdgeos: Hm, for some reason I still think it's caused by yesterday's Calligra update
<tsdgeos> may be
<mlankhorst> ok xorg 1.15 transition should be complete then when it switches over
<mlankhorst> if the tegra drivers are still in the archive they should probably be deleted, I haven't had much luck with getting my tegra working on saucy, let alone trusty..
<doko> rbasak, jamespage: with your server/puppet hat on, could you have a look at the ~200 php build failures in the test rebuild? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
<mitya57> tsdgeos: indeed, http://sources.debian.net/src/calligra/1:2.7.5-1/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp?hl=98#L98
<mitya57> I think you should poke Riddell about the bug
<tsdgeos> ohh qdebugs in code
<tsdgeos> sigh
<tsdgeos> and i wonder why is that getting everywhere
<mitya57> Note that the code above is older version.
<Sweet5hark> Heeere's Jooohny!
<mlankhorst> well it's building but still acting funny, stuck on 'uploading build' for a lot of packages ,even though the builder is obviously building something else now. :P
<xnox> mlankhorst: it takes a long time to upload a build, sometimes. Was it big?
<cjwatson> which suggests that alphecca's cron jobs might not be running
<cjwatson> mlankhorst: package name?
<mlankhorst> cjwatson: xserver-xorg-video-ati
<Riddell> tsdgeos: question is why a calligra lib causes debug output on starting e.g. dolphin
<tsdgeos> Riddell: that is a good question
<cjwatson> mlankhorst: looks like it's catching up now.  #launchpad-ops thinks it's because of backlog + temporarily on slow master db
<mlankhorst> ah
<mlankhorst> yeah
<mlankhorst> it's between 26 minutes and 13 minutes behind now O:-)
<mlankhorst> 19 minutes
<wgrant> mlankhorst: It's caught up now.
<mlankhorst> yeah :)
<mlankhorst> s
<mlankhorst> oops
<mlankhorst> ogra_: ping
<ogra_> yo
<mlankhorst> can we drop nvidia-graphics-drivers-tegra(,3) from the archive?
<ogra_> dunno, havent done anything with it in 1.5 years
<ogra_> you could mail the ac100 ML ... they are the main consumers of it
<mlankhorst> it's blocking the xorg 1.15 update, and I haven't had any luck getting saucy to work on mine
<Sweet5hark> ricotz: around?
<ogra_> (or ask in the #ac100 channel)
<mlankhorst> k
 * apw suspects compiz is borked in trusty, no longer connected to the x display and no windows displayed
<ogra_> apw, it is
<ricotz> Sweet5hark, yes
<ogra_> apw, new libprotobuf should hit the archive soon (it is in proposed)
<apw> DQAW
<ricotz> Sweet5hark, did you receive my messages?
<Sweet5hark> ricotz: unlikely, Im travelling right now.
<ricotz> Sweet5hark, regarding the missing translation files
<Sweet5hark> ricotz: The l10n package is broken, a fix is currently building ...
<ricotz> Sweet5hark, all translations ..., alright
<ricotz> Sweet5hark, precise users already complained :\
<Sweet5hark> ricotz: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging/+builds?build_state=building
<ricotz> Sweet5hark, http://people.ubuntu.com/~ricotz/libreoffice/4.2-l10n.diff
<Sweet5hark> ricotz: someone zipped l10n files after the beta release, this broke the l10n packaging (upstream, but only us are using it right now)
<Sweet5hark> ricotz: I also got private mails about it, but no bug reports on launchpad or fdo. When will people ever learn ...
<ricotz> Sweet5hark, alright, i hope this fixes it ;)
<ricotz> Sweet5hark, be aware you need to change the version while you changed the tarball content
<Sweet5hark> ricotz: huh, I did not regenerate the tarballs yet, so they dont need a new version?
<ricotz> this can't be uploaded
<ricotz> hmm, the diff indicate a lot of zips changed
<ricotz> Sweet5hark, you had two different tarball versions!
<Sweet5hark> ricotz: Ill do a 4.2.0 final for trusty archive anyway ...
<ricotz> the prerelease ones and the archive ones
<ricotz> ok
<ogra_> Mirv, so i got some new scripts for rootstock that actually allow to build proper system-image images from ppas ... not 100% done yet, but i should be able to give you something tonight
<ricotz> Sweet5hark, btw what is the reason not using sytem's libcmis?
<ricotz> Sweet5hark, ah forgot about 0.4.1-3
<Sweet5hark> ricotz: getting to the list of non-system libs just now. first getting out a release at all was priority.
<ricotz> Sweet5hark, right
<ricotz> Sweet5hark, not sure if things can get automatically demoted to universe again ;)
<ricotz> if there are no consumers in main
<ricotz> Sweet5hark, you might want to create a 4-2 ppa soon
<Sweet5hark> ricotz: right
<cjwatson> knome: xubuntu-docs is ready for a quick test now
<davmor2> tseliot: :(  this morning lp tells me I got hit by bug #1231689
<ubottu> bug 1231689 in xorg-server (Ubuntu) "Xorg assert failure: X: ../../dix/dispatch.c:3937: DetachUnboundGPU: Assertion `slave->isGPU' failed." [Medium,Expired] https://launchpad.net/bugs/1231689
<davmor2> tseliot: purging nvidia-331 and nvidia-prime have me at a working lightdm but no unity :(
<tseliot> davmor2: in trusty?
<davmor2> tseliot: yeap
<tseliot> davmor2: also, what does "no unity" mean?
<cjwatson> davmor2: the protobuf ABI regression took out compiz, hence no unity.  fix in -proposed now, in trusty shortly
<davmor2> tseliot: I log into lightdm I get the desktop background but no unity.  So I can hit ctrl+alt+t and then get a terminal but no shell
<davmor2> ah cjwatson awesome
<davmor2> tseliot: could the nvidia issue be based on that too then?
<cjwatson> hmm, ubuntuone-storage-protocol autopkgtest failure
<cjwatson> looks like that may have already been forced somehow though
<tseliot> davmor2: I have no idea about the protobuf ABI regression cjwatson mentioned, but usually when I get stuck and only get the background and no unity, I type "dconf reset -f /org/compiz/" and restart lightdm, and things work.
<cjwatson> ok, this ubuntuone-storage-protocol autopkgtest failure seems to indicate a real bug
<davmor2> tseliot: well I'll wait for the fix to land and keep an eye on things and let you know
<cjwatson> though one that was also in 2.5.0-7ubuntu1
<cjwatson> so I think given that this is critical I should force it through anyway, but I'll try to fix it
<tseliot> davmor2: ok
<asac> will gcc 4.7 be "supported" in trusty? or do we only support 4.8?
<asac> doko: ?
<doko> asac, I assume so, but it is for the android stack only. xnox should know better
<cjwatson> it's still there at least until such time as nothing we ship requires it to build
<cjwatson> and I haven't yet switched our default boot loader to 4.8 ...
<cjwatson> I bet there are various other odds and ends too
<asac> doko: seems we have some troubles with libstdc++ compatibilty bewteen 4.7 and 4.8 or something ...
<asac> doko: can you check with tvoss about his troubles there?
<asac> hi tvoss :)
<tvoss> asac, o/
<asac> 13:38 < asac> doko: seems we have some troubles with libstdc++ compatibilty bewteen 4.7 and 4.8 or something ...
<asac> 13:38 < asac> doko: can you check with tvoss about his troubles there?
<doko> asac, he should not mix ...
<tvoss> doko, that's what I'm working on right now
<asac> doko: its not really clear how to not mix i think... e.g. where do we draw the line
<asac> tvoss: do we have a clear line?
<tvoss> asac, don't mix in c++ world
<tvoss> asac, C is fine (mostly)
<asac> tvoss: so do we have a layer that protects us? is that platform api? e.g. everything below is 4.7, everything above is 4.8?
<cjwatson> ubuntuone-storage-protocol> oh, never mind, it's explicitly running tests under PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
<cjwatson> so not really a protobuf regression in the sense I was thinking
<tvoss> asac, yup
<tvoss> asac, although we should really pull platform api to gcc 4.8
<asac> tvoss: so should we systematically go to 4.7 for everything below platform API that is C++ what about MIR? isnt that below and above?
 * asac scared that we infect the world :)
<cjwatson> dobey: would it make sense to drop the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp run from ubuntuone-storage-protocol/run-tests?  looks like protobuf doesn't support that any more
<asac> tvoss: whats the prob with platform api and 4.8?
<asac> just not building?
<tvoss> asac, there are two things as far as I understand it: make sure that toolchains across the libc boundary match, and then make sure that the floating point conversion works/is not required anymore by transporting floats in structs
<asac> tvoss: thats what blocks platapi on 4.8? or thats what causing 4.7/4.8 mixing havoc?
<asac> anyway, do what you need to do :)
<tvoss> asac, that's what blocks papi on 4.8
<tvoss> @havoc: still figuring that out
<udevbot> Error: "havoc:" is not a valid command.
<knome> seb128, the image files are still not updated, even if they are marked as changed in the debdiff. how can we fix this?
<seb128> knome, I don't know
<knome> seb128, is that a known problem of debdiffs?
<cjwatson> debdiffs don't represent binary files
<seb128> knome, binary changes can't go in diff
<seb128> if that's what you are asking
<knome> seb128, no, i understand that
<cjwatson> knome: does this pertain to xubuntu-docs/precise-proposed?
<seb128> if images are svg that's text formatted and can go in diffs
<knome> how do we propose a SRU that changes binary files?
<knome> cjwatson, yep; the looks is now fine, but image files are still not there
<cjwatson> attach the actual source files not a debdiff
<cjwatson> .dsc and .tar.gz in this case
<cjwatson> also, you had eight days to check this in the queue :-(
<knome> yes, i'm very sorry
<knome> it's not a huge catastrophe if the SRU goes as it is now
<knome> but i'd of course rather fix the images as well
<knome> and yes, i know we had time, i'm very sorry
<knome> hmm, i said that already. well i am sorry! :)
<cjwatson> let's push it round again, we just about have time
<knome> sure, i'll try to catch the right people ASAP
<knome> cjwatson, added the files to the bug report; unfortunately, the version is 12.04.0 as this is how i got the files from somebody who knows better than me; i will not touch them to not break anything :)
<knome> cjwatson, i'll be around to verify that it works, just ping me
<eLpm> Hello, is there someone in here?
<eLpm> I would like some help with lp #1276562
<ubottu> Launchpad bug 1276562 in ubuntu-meta (Ubuntu) "Xserver removed after upgrade (2014-02-04)" [Undecided,New] https://launchpad.net/bugs/1276562
<cjwatson> knome: ok, ideally it'd be some sponsor other than me so that I can legitimately do the SRU shuffling
<mlankhorst> eLpm: erm did you have -proposed enabled by any chance?
<eLpm> The bug is not necessarily about the meta package (sorry if this is the wrong channel)
<eLpm> Yes :D
<eLpm> mlankhorst, Yes
<mlankhorst> well there you go
<eLpm> XD
<mlankhorst> it broke and now you get to keep the pieces :-)
<eLpm> And do you know the possible causes already?
<cjwatson> of course the compiz failure was probably due to protobuf which was in trusty
<cjwatson> we're publishing a fix for that at the moment
<ogra_> eLpm, never ever enable -proposed on a devel release ... it isnt what you might think it is
<eLpm> cjwatson, Awesome I'll wait patiently :-)
<eLpm> ogra_, It's OK I wanted to help testing. I am dual booting currently, so no problem.
<cjwatson> please don't enable -proposed to help testing
<cjwatson> it doesn't help
<cjwatson> (in the development release, that is)
<ogra_> eLpm, -proposed is not for testing in dev treleases
<ogra_> -t
<cjwatson> it actively hinders us by creating noise from people running into problems that machines would have caught
<cjwatson> I understand you mean well, but please disable it, it will be better for us
<eLpm> Oh, I didn't know. I'll disable it then.
<ogra_> in dev releases -proposed is part of the automated infrastructure ...
<eLpm> And thanks.
<ogra_> in actual releases you can use it for testing possibly broken packages
<eLpm> ogra_, OK :-)
<cjwatson> at some point maybe it'll be worth creating a separate pocket for it, it's just that new pockets are painful to create
<cjwatson> they're all very very hardcoded
<Laney> We should make it NotAutomatic :P
<cjwatson> using -proposed meant that I could make the system work in days rather than weeks or months
<mlankhorst> well -proposed was always used for that, even before the automatation was put in place :P
<cjwatson> not very much
<cjwatson> the odd hack around release time
<knome> seb128, would you do yet another favor to get the docs SRU in as it should?
<seb128> knome, is the bug updated?
<knome> seb128, yep, i attached .dsc and .tar.gz files (with the same shortcoming as the last time; the version is .0)
<seb128> knome, ok, can do once launchpad is back to working
<seb128> it's oopsing
<knome> seb128, yeah, was for me too :/ but thanks again, and my humble sorrys for bothering you with this constantly
<seb128> knome, no worry, mistakes happen
 * knome makes sure it's people who understand packaging/related stuff do the work next time... grumble :)
<mpt> Is anyone familiar with âSection: oldlibsâ, so they can answer my last questions in bug 1166230? Thanks.
<ubottu> bug 1166230 in update-manager (Ubuntu) "Updater lists many transitional dummy packages" [Medium,Confirmed] https://launchpad.net/bugs/1166230
<knome> cjwatson, i assume the .2 version should land in -proposed any minute now, right? or do you still need to push a button?
<cjwatson> I already did
<knome> as i imagined, thanks
<cjwatson> it should publish once the cron jobs are re-enabled following the LP database server switch
<cjwatson> in the meantime I'm having lunch :)
<knome> bon appetit!
<dobey> cjwatson: did it fail again? it ran fine for the last protobuf build from slangasek
<davmor2> tseliot: with protobuf fix in place nvidia && prime seem to be behaving again \o/ cjwatson I now have unity again too so the fix worked :)
<cjwatson> dobey: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-ubuntuone-storage-protocol/ARCH=amd64,label=adt/14/console - seems fairly expected given what it's running
<cjwatson> davmor2: cool
<tseliot> davmor2: excellent. What package/version is that?
<cjwatson> dobey: I mean, run-tests is explicitly asking for the cpp backend, which protobuf no longer ships
<dobey> cjwatson: that's a bug in protobuf (the _pb2.py are generated by protobuf-compiler)
<davmor2> tseliot: for what sorry? Nvidia or the protobuf?
<tseliot> davmor2: protobuf
<cjwatson> dobey: how is it a bug in protobuf that ubuntuone-storage-protocol explicitly runs PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp u1trial tests ?
<davmor2> tseliot: 1 second
<dobey> cjwatson: it's a bug in protobuf because the protobuf generated code is trying to import something that is no longer there because slangasek removed the module from the package
<cjwatson> dobey: and AFAICT the correct answer is not to attempt to run the tests with PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp any more, because that implementation is no longer available
<dobey> cjwatson: running the tests with that environment variable set shouldn't cause a failure, especially if there is no cpp support
<cjwatson> well, I guess slangasek can adjudicate, I was only doing a drive-by anyway *shrug*
<dobey> cjwatson: i think we should run it, because it exposes bugs in protobuf that are a result of upstream removing a feature half-assedly :)
<davmor2> tseliot: libprotobuf7 == 2.4.1-3ubuntu4 libprotobut8 == 2.5.0-8ubuntu1 python-protobuf == 2.5.0-8ubuntu1
<tseliot> davmor2: ok, thanks
<shadeslayer> pitti: ping ping
<shadeslayer> pitti: can you map kcm-driver-manager.pot to the kubuntu-driver-manager package?
<pitti> hey shadeslayer, how are you?
<shadeslayer> or atleast that's what https://wiki.kubuntu.org/Kubuntu/l10n asks me to do
<shadeslayer> pitti: recovering from FOSDEM ;)
<pitti> shadeslayer: err, I can't do that kind of mapping -- the source should just build such a .pot file
<shadeslayer> oh ... hm, documentation needs updating then
<pitti> (the mapping is built in LP translations on import)
<shadeslayer> I see
<pitti> shadeslayer: oh, actually it seems I ca
<pitti> n
<shadeslayer> heh :D
<pitti> shadeslayer: but that's really a workaround in LP; doesn't the package build a .pot?
<shadeslayer> pitti: it does
<shadeslayer> so if I just build a pot, it'll all work?
<pitti> I thought that workaround was for the LP bug that exports don't contain universe
<pitti> shadeslayer: do you see it in translations.lp.net?
<pitti> bug 1048556
<ubottu> bug 1048556 in Ubuntu Translations "Language pack translations export needs to add universe packages to domain map" [High,Triaged] https://launchpad.net/bugs/1048556
 * shadeslayer is looking
<pitti> that's why I have a locally patched hack on macquarie (the langpack building host)
 * pitti taps foot, that bug is slow to load..
<shadeslayer> all of launchpad is slow today :)
<pitti> but it supposedly got fixed in LP, so it shouldn't be necessary any more
<shadeslayer> pitti: so basically, I just upload my package to the archive, it'll have the pot, and then then Launchpad does the translation work and stuffs it into the package?
<pitti> https://launchpad.net/ubuntu/trusty/+source/kubuntu-driver-manager
<pitti> shadeslayer: it seems that doesn't even exist yet?
<pitti> shadeslayer: yes, that's the usual workflow
<shadeslayer> pitti: yep, I'm about to upload it
<shadeslayer> last checks
<pitti> ah
<pitti> it should then appear on https://translations.launchpad.net/ubuntu/trusty/+source/kubuntu-driver-manager
<pitti> (might take a few days, AFAIK new templates still need to be manually approved in LP)
<shadeslayer> okay
<shadeslayer> thanks for explaining that ;)
<pitti> shadeslayer: yw
<jdstrand> tkamppeter: hey, I just filed bug #1276630
<ubottu> bug 1276630 in cups-filters (Ubuntu) "cups-browsed upstart job does not load the apparmor profile for cups-browsed" [High,New] https://launchpad.net/bugs/1276630
<jdstrand> tkamppeter: I attached a patch. I'm happy to upload the fix if you want
<roadmr> doko: hello! hey, sorry about the screwup with checkbox's build-deps :( I'm adding brendand's fix now
<roadmr> doko: a question though, since this applies only to ubuntu-specific packaging, would it be reasonable to version this as 0.17.4ubuntu1? (the bad version was 0.17.4)
<cjwatson> knome: publisher's taking annoyingly long, very cold caches I think
<knome> cjwatson, no problem, i have time :)
<cjwatson> knome: mind you I think for this purpose I'd be fine with you just fishing it out of LP.  Let me score up the build so that it actually happens ...
<cjwatson> competing with KDE it seems
<knome> cjwatson, i can fish it out of LP as well and test
<cjwatson> it's just building now
<knome> okay, that works as well ;)
<xnox> jdstrand: doing it old-school, or is the "apparmor load usr.sbin.cups-browsed" not good enough?
<xnox> jdstrand: i guess precise's upstart will reject that job and a reboot would be required... so i'll schedule switching away from profile-load post-trusty?
<jdstrand> xnox: precise' upstart does not know about the apparmor stanza
<jdstrand> xnox: so if it is important to have the backwards compatibility in the upstart job, then should do it old school
<xnox> jdstrand: right. ok.
<cjwatson> knome: https://launchpad.net/ubuntu/+source/xubuntu-docs/12.04.2/+build/5556954 built
<knome> getting.
<knome> cjwatson, works for me. shall i mark the bug verification-done?
<doko> roadmr, sure, you can do this
<knome> cjwatson, also, will there be a respin for other things anyway before the release?
<roadmr> doko: cool, perfect! ok, so I'll upload the fixed version. Again, sorry for the mess-up
<slangasek> dobey: I don't think you should be running with PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp when that implementation is no longer included; as far as I can see that's an XFAIL
<cjwatson> knome: yes please; hadn't planned anything else but I'm OK with respinning just for this, esp since you folks are well ahead of everyone else on testing
<knome> cjwatson, okay, thanks again
<dobey> slangasek: and i don't think protobuf should be shipping internally broken code, either
<knome> cjwatson, marked as verification-done.
<cjwatson> thanks
<dobey> slangasek: transitions shouldn't generally break things like that by having internal regressions
<knome> cjwatson, will you request the respin when it's landed on the archive?
<cjwatson> yes, well, I'll *do* the respin
<cjwatson> but either way
<knome> heh, yeah, ta :)
<cjwatson> though I guess I should use the shiny webby tools
<knome> mhm, always!
<knome> you can even ping me once again when the respin is done and i'll make sure somebody other than me looks at the respun image as well
<tkamppeter> jdstrand, thank you very much. As Debian is also using AppArmor now, I asked the Debian maintainer to upload it so that it gets into our synced package.
<pitti> tkamppeter: oh, it does? nice!
<cjwatson> hmm, kubuntu alternate is busted
<cjwatson> amd64 anyway
<Riddell> cjwatson: for 12.04?
<cjwatson> yeah, complaining about lack of kernel modules
<cjwatson> chasing now
<cjwatson> it's just an out-of-date abi for some reason
<Riddell> thanks for chasing, I'm starting on testing the live images now
<cjwatson> Xubuntu alternate broken in the same way, not that it's on the tracker
<cjwatson> which is odd given that we released it with 12.04.3
<cjwatson> oh, bah, I see, more seeds than I remembered
<knome> cjwatson, probably just a mistake that.
<cjwatson> no, it was necessary due
<cjwatson> to the enablement stack differences
<cjwatson> pretty sure I perpetrated it
<knome> okay
<cjwatson> knome: oh, wait, you mean it not being on the tracker?
<knome> yep, that
<cjwatson> yeah, I'll look into it once I've fixed the seeds
<knome> oki
<cjwatson> ok, hopefully that's Xubuntu alternate * active again
<knome> cjwatson, in terms of the tracker or something else?
<cjwatson> rebuilding Kubuntu and Xubuntu alternate
<cjwatson> the tracker
<denisw> is there a vUDS scheduled for this month? if there is one every 3 months as originally announced, it would be time again, but haven't found anything about it when Googling
<cjwatson> (actually I may need to do Xubuntu alternate a second time, forgot to wait for -docs)
<knome> cjwatson, i can't see alternate enabled
<cjwatson> it's active, there just aren't builds filed for it yet
<knome> ah, right, that makes it invisible. magic!
<hallyn> ok, so guidance on when -sa needs to be passed to debuild.  is that only when the .orig.tar.gz changes?
<davmor2> tseliot: hmm suspend works great, resume not so much :D
<tseliot> davmor2: you might want to file a bug report and to debug it a bit to see what's going on
<cjwatson> hallyn: if the .orig.tar.gz changes but the top and second-from-top changelog entry have the same upstream version
<hallyn> ok - so never if .orig.tar.gz doesn't change
<cjwatson> typically happens when merging
<cjwatson> right
<davmor2> tseliot: sure ubuntu-bug xorg or something more specific?
<hallyn> got it, thanks
<tseliot> davmor2: maybe ubuntu-bug nvidia-331 or nvidia-331-updates if you're running the nvidia driver
<davmor2> tseliot: will do
<tseliot> good
<cjwatson> knome: ok, that's in, respinning all the xubuntu images now
<cjwatson> knome: (I'm not going to be extra-strict about testing given that it's just this change, but a quick smoke-test of each one would be good)
<davmor2> tseliot: bug #1276674  I'll grab an image and attach it now if I can.
<ubottu> bug 1276674 in nvidia-graphics-drivers-331 (Ubuntu) "Suspend works flawlessly however resume leads to a checker board screen rather that lightdm" [Undecided,New] https://launchpad.net/bugs/1276674
<davmor2> tseliot: oh interesting logging in via tty has enabled me to get logged in again however the desktop is now checkerboard
<marga> slangasek, I'd like to discuss a network manager bug with you, could you let me know when you are around?
<tseliot> davmor2: did resume use to work with nvidia?
<tseliot> also grr at ubuntu-bug for not attaching useful data...
<davmor2> tseliot: no idea a friend pointed me at it, I don't normally suspend on or off for me :)  It does work on intel though
<tseliot> davmor2: can you reproduce the problem and generate an nvidia-bug-report file please?
<davmor2> tseliot: yeap give me 5 minutes
<tseliot> davmor2: sure
<cjwatson> knome: argh, sorry, that respin didn't work because the mirror was locked, I'll retry in a bit
<davmor2> tseliot: that should be added now
<davmor2> along with an image
<knome> cjwatson, okay
<tedg> stgraber, Is there a way that I could run "make test" in a cgroup that had like a tenth of a CPU to emulate running on Jenkins?
<jdstrand> tkamppeter: cool, thanks!
<stgraber> tedg: yes, create a new cpu cgroup, echo your shell's PID in it, set cpu.shares to whatever value you want and run your test
<stgraber> tedg: you'd have to go read the documentation for the cpu cgroup though as I'm not entirely sure of what happens on a system that's not under heavy load (as in, does the kernel grant you extra resources or not)
<tedg> stgraber, I read that as "you need to play more counter-strike at work"  ;-)
<tedg> stgraber, Thanks for the pointers
<tseliot> davmor2: it's actually the intel kernel module that fails when suspending
<davmor2> tseliot: Yay
<tseliot> davmor2: so a kernel issue. Let me update the bug report.
<davmor2> tseliot: thanks dude
<davmor2> tseliot: hmm I also wonder if it is because I changed the mode in nvidia-settings to powersaving  I'll try it on performance and see if I get the same result
<davmor2> I'm assuming I will
<tseliot> ok
<cjwatson> knome: ok, I think I've finished rebuilding now
<cjwatson> cdimage@nusakan:~$ zgrep xubuntu-docs cdimage/www/full/xubuntu/precise/*/current/*.{list,manifest}
<cjwatson> cdimage/www/full/xubuntu/precise/daily/current/precise-alternate-amd64.list:/pool/universe/x/xubuntu-docs/xubuntu-docs_12.04.2_all.deb
<cjwatson> cdimage/www/full/xubuntu/precise/daily/current/precise-alternate-i386.list:/pool/universe/x/xubuntu-docs/xubuntu-docs_12.04.2_all.deb
<cjwatson> cdimage/www/full/xubuntu/precise/daily-live/current/precise-desktop-amd64.manifest:xubuntu-docs 12.04.2
<cjwatson> cdimage/www/full/xubuntu/precise/daily-live/current/precise-desktop-i386.manifest:xubuntu-docs  12.04.2
<knome> cjwatson, yep, already confirmed the images are fine
<cjwatson> just need to wait for the public mirrors to catch up with that
<davmor2> tseliot: yeap it's the same :)
<tseliot> davmor2: did you get a second nvidia-bug-report file?
<davmor2> tseliot: no but I can easily enough
<tseliot> davmor2: please do, and explain what you changed when you attach it
<davmor2> tseliot: done
<psusi> we didn't decide to support upgrading directly from 12.10 to 13.10 since 13.04 went eol first did we?
<tseliot> davmor2: both reports seem to suggest that you were using the discrete card. I see no evidence of intel being used
<pitti> psusi: that should work now; update-manager etc. have been updated recently for that
<infinity> psusi: We did, yes.
<davmor2> tseliot: hmmm let me try again then on intel
<psusi> oh boy....
<infinity> psusi: In theory, it should all go perfectly, since we have to support 12.04->14.04, so all the right upgrade code is in place already.  Right?  Right?  *cough*
<davmor2> tseliot: it could just be the nvidia settings app lying ;)
<tseliot> davmor2: I was referring to both dmesg and the X log, which usually don't lie ;)
<davmor2> tseliot: hence saying that maybe the nvidia-setting app was :)
<tseliot> davmor2: ah, to you then :). But did you log out to switch between cards?
<davmor2> tseliot: ah now it seems to be on intel correctly and isn't doing the checkerboard effect
<psusi> sigh... I was looking at bug #1276669 and wondering why it was skipping a release in the upgrade.. unfortunately there doesn't seem to be a damn thing in the logs that gives any indication *why* the upgrade failed
<ubottu> bug 1276669 in grub2 (Ubuntu) "package memtest86+ 4.20-1.1ubuntu5 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1276669
<davmor2> tseliot: is it worth grabbing another nvidia-bug-report.sh?
<tseliot> davmor2: after reproducing the problem, yes
<davmor2> tseliot: I've gone through the steps but the problem isn't happening now
<tseliot> davmor2: then you can only reproduce it when the discrete card is enabled. You might want to update the bug report about this
<infinity> psusi: Could be update-grub losing its mind?
<infinity> psusi: Not that that's terribly helpful as to why...
<xnox> psusi: infinity: i'd say that /boot is full.
<xnox> psusi: infinity: given the earliear:
<xnox> Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.11.0-15-generic.postinst line 1010.
<xnox> dpkg: error processing linux-image-3.11.0-15-generic (--configure):
<infinity> xnox: kernel/postinst.d also calls update-grub ...
<davmor2> tseliot: thanks for the help and the bug is updated
<tseliot> davmor2: thanks
<infinity> Setting up grub-pc (2.00-7ubuntu11) ...
<infinity> Installing new version of config file /etc/kernel/postinst.d/zz-update-grub ...
<infinity> Installing new version of config file /etc/kernel/postrm.d/zz-update-grub ...
<infinity> Installation finished. No error reported.
<infinity> Generating grub.cfg ...
<infinity> dpkg: error processing grub-pc (--configure):
<infinity> xnox, psusi: It's pretty clearly update-grub failing on that machine.  But, like I said, that doesn't answer why.
<Nafallo> hrm. is click supposed to be running constantly on trusty desktop?
<Nafallo> with running I mean being in cpustate running.
<doko> mterry, https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+build/5512647 (you touched it last)
<mterry> doko, curious.  Can put it on my todo
<doko> thanks
<psusi> infinity, xnox, right, but there is no output logged from update grub to indicate why...
<xnox> psusi: yeah, a syslog would be helpful. (e.g. if it was out of disk space)
<psusi> xnox: or just the output from running update-grub
<psusi> I wonder why that isn't logged in the aptterminallog
<Riddell> cjwatson: meh kubuntu still broken for encrypted install http://people.ubuntu.com/~jr/tmp/d-i.png
<Riddell> unencrypted is fine
<seb128> infinity, cjwatson: Laney would like to join ~ubuntu-archive to help there, should he email the team list for that or...?
<doko> roaksoax, any progress on bug #1268915 ?
<ubottu> bug 1268915 in python-dns (Ubuntu) "[MIR] pycountry and python-dns, b-d's of python-formencode" [Undecided,Incomplete] https://launchpad.net/bugs/1268915
<doko> jamespage, zul: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg tells me that paste recommends mochikit
<zul> doko: ill have a look
<doko> zul, and please bug #1270831 too
<ubottu> bug 1270831 in ntdb (Ubuntu Trusty) "[MIR] ntdb, build dependency of samba" [High,Incomplete] https://launchpad.net/bugs/1270831
<zul> yeah ill probably get to it tonight
<stgraber> @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: stgraber
<Noskcaj> stgraber, Could you look at lp:~noskcaj/+junk/gnome-weather ? It needs uploading for ubuntu-gnome
<Noskcaj> Can't be uploaded to debian due to use of the CC-BY-2.0 license
<Logan_> ahem
<Noskcaj> ?
<Logan_> one moment
 * Noskcaj leaves to get food
<roaksoax> doko: i'll take care of it right now! Thank you! but if you are reviewing MIR's, crochet is there waiting for review :)
<stgraber> Noskcaj: well, for starters this branch contains a copy of libgd which I wouldn't be happy at all to let enter the archive when we already have a packaged version of it, you also forgot to mention said library in debian/copyright
<Logan_> Noskcaj: uscan warning: In /tmp/tmpkKu6RI no matching hrefs for version 3.10.1 in watch line
<Logan_>   http://download.gnome.org/sources/gnome-weather/([0-9.]+)/gnome-weather-([0-9.]+)\.tar\.xz
<Logan_> also 3.11.5 is available upstream
<Logan_> stgraber: yeah, that should probably be stripped from the tar ball
<Logan_> tarball
<Noskcaj> ok
<Noskcaj> Logan_, bzr pull then debian/rules get-orig-source
<Logan_> there's no get-prig-source target
<Logan_> orig
<Noskcaj> I just pushed the fix, bzr might not have processed it yet
<Noskcaj> now to try and remove libgd
<doko> chrisccoulson, https://launchpadlibrarian.net/165084902/buildlog_ubuntu-trusty-amd64.icedtea-web_1.4.2-1ubuntu1_FAILEDTOBUILD.txt.gz issue with a firefox header?
<Noskcaj> stgraber, I've deleted the libgd/ directory, still builds fine. Do i need to add a README.source or something?
<stgraber> Noskcaj: so if it's entirely unused, it's probably not a big problem keeping it in the orig tarball, I don't think it's worth repacking the upstream tarball for that. However a note in README.source or similar that libgd/ isn't used at all is a good idea, so it doesn't freak out archive admins and security people.
<roaksoax> doko: bug #1268915 is done!
<ubottu> bug 1268915 in python-dns (Ubuntu) "[MIR] pycountry and python-dns, b-d's of python-formencode" [Undecided,New] https://launchpad.net/bugs/1268915
<roaksoax> Noskcaj: what is it that you wanted me to take care from testdrive?
<Noskcaj> stgraber, ok.
<Noskcaj> roaksoax, release 3.25, gtk3 port, python3 port
<roaksoax> Noskcaj: are these merged?
<roaksoax> Noskcaj: 3.26 is released
<Noskcaj> ok
<Noskcaj> roaksoax, danchapman and i have both tryed to do the gtk3 port, both of us failed.
<Noskcaj> and python3 needs the gtk3 port i think
<roaksoax> Noskcaj: there's a port to gtk3 that needs improvement already: https://code.launchpad.net/~jbicha/testdrive/port-to-gtk3/+merge/72369
<Noskcaj> yeah, so there's three of them then
<Noskcaj> lp:~noskcaj/testdrive/gtk3 should have all the python side of things done, i just couldn't get glade to work
<roaksoax> Noskcaj: ok, i;ll try to take a look at it later today
<Noskcaj> thanks
<Noskcaj> stgraber, Should be all fixed. I think a libgd-dev bdep is enough
<doko> jtaylor, pycxx tests still don't succeed :-/ what did I do wrong?
<jtaylor> doko: looks fine? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-pycxx/
<doko> ohh
<doko> ok, maybe I did look too early
<ari-tczew> stgraber: got time to sponsor?
<cjwatson> Riddell: it would help to get the installer syslog in such cases, especially with limited time left to reproduce anything ...
<cjwatson> Nafallo: no, it's not, it's meant to run briefly to run any necessary hooks and then go away
<cjwatson> Riddell: (I have to go to bed soon before I just fall over)
<stgraber> @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-02-06
<Riddell> cjwatson: meh I can't work out how to get the log off a virtual machine and need to wait until I'm home tomorrow morning before I can try it on a spare test machine
<Riddell> cjwatson: yay got it
<Riddell> http://people.ubuntu.com/~jr/tmp/syslog
<Riddell> device-mapper: reload ioctl failed: No such file or directory
<Riddell> bug 1276739
<ubottu> bug 1276739 in debian-installer (Ubuntu) "kubuntu encrypted lvm install fails" [Undecided,New] https://launchpad.net/bugs/1276739
 * Riddell snoozes
<hallyn> infinity: stgaber: around?
<infinity> hallyn: Ish.  What's up?
<hallyn> inifinty: my qemu uplaod to trusty may have badly messed up
<hallyn> i'm going to retry in a new vm;  it's possible something else messed me up, but given the severity here - it messed up binfmts entirely so i can't run dpkg/ls/etc
<infinity> hallyn: The one with ~ppa in the version? :P
<hallyn> yeah that one
<infinity> When you say "can't run dpkg/ls/etc", do you mean "in an ARM chroot", or "at all"?
<hallyn> at all
<hallyn> -bash: /usr/lib/command-not-found: /usr/bin/python3: bad interpreter: Too many levels of symbolic links
<infinity> Yeahp, you sure broke it.
<hallyn> i haven't yet found where
<infinity> I'd look, but I stupidly broke my machine checking.
<infinity> Cause I used a chroot.
<Logan_> the archive should reject uploads with a ~ppa suffix
<infinity> So, let me reboot and then have a poke.
<infinity> Logan_: He would have just reuploaded with a proper version and still broken the world. :P
<infinity> hallyn: I'll delete the binary from the archive after I reboot and can, like, run stuff.
<hallyn> infinity: thanks.
<hallyn> that's why it passed all my tests.  apparmor kept me from hosing myself.
<infinity> hallyn: So, comparing old and new debs, it looks like you're now shipping binfmts for the native arch.
<infinity> hallyn: As in, I get binfmts for x86_64 and i386 on amd64 which I didn't before, so qemu is being tripped for native binaries.
<hallyn> i'm not yet seeing *why* that's happening.  first ithought my wrong use of dpkg-verison in postinst was to blame, but nope
<infinity> hallyn: No, it's actual shipped filed that differ.
<infinity> http://paste.ubuntu.com/6883091/
<infinity> Why that is, however, I'm not seeing immediately.
<hallyn> infinty: right, that makes perfect sense,given the symptoms;  was just saying it wasn't what i originally expected to be the probelm
<infinity> So, filter_binfmts is failing somehow, I guess?
<stgraber> yeah, that's what the buildlogs indicate
<stgraber> but I'm failing to see how
<infinity> hallyn: Oh, possibly because you went and added a make conditional in the middle of a shell continuation.
<infinity> hallyn: You can't do that.
<infinity> hallyn: You need to write that bit as shell too, if it's in the middle of shell.
<hallyn> i see
<infinity> Oh well.  Gives you a chance to fix the version number on the next upload. :P
<infinity> There's no reason to have the Ubuntu conditional in there anyway, is there?
<hallyn> since we're not fully merging the qemu trees i'm going to pull all incidences of the dpkg-vendor for nwo anyway, but <arg>
<infinity> The arm64 bit is just a no-op when not building on arm64...
<hallyn> true
<hallyn> so how long does it take before ppl are no longer exposed to that?
<hallyn> (testing a new version...  wont' be pushing too soon)
<infinity> hallyn: It's already gone from ftpmaster, just needs mirror pulses.
<stgraber> hallyn: we probably want a fix uploaded soonish since until then, none of the binaries infinity removed exist at all (so nobody can install any version of those, which leads to other packages breaking and so on)
<infinity> stgraber: To be fair, qemu-user-static has nearly 0 rdeps.
<stgraber> my guess is that just dropping the ifdef in the middle of that block of shell is the safest bet to have something that builds, that you have already tested and which fixes our immediate problem
<infinity> But yeah, a fix would be nice.  Dropping those two lines would fix it.
<hallyn> stgraber: there's another snafu (using dpkg-version in postinst but not depending on devscripts);
<infinity> Eww.
<infinity> You mean dpkg-vendor.
<hallyn> so yeah i'ts just http://paste.ubuntu.com/6883177/
<hallyn> yes
<infinity> But yeah, that should be subsituted in during build.
<infinity> As in: if [ "@@VENDOR@@" = "ubuntu" ]
<infinity> And then sed that in at build time when turning postinst.in into postinst.
<stgraber> that diff looks safe enough and the real fix for a common source with Debian is indeed to add a new variable that's substituted from debian/rules (as you already seem to be using quite a bit ;))
<infinity> hallyn: But go ahead and upload you current diff (looks good), and sort out the sed magic later, if you really care about the conditionals.
<infinity> hallyn: Also, that should be 1.7.0+dfsg-3ubuntu1
<hallyn> ok then, pushing.  thanks for removing those!
<hallyn> oh,
<hallyn> oh heh, right.
<stgraber> I guess qemu could do with an autopkgtest to try and catch this kind of stuff next time around, can't hurt to have autopkgtest try to run a binary of each arch that are supported.
<infinity> stgraber: You mean try to run a native binary to make sure the world isn't broken?
<infinity> stgraber: Trying to run foreign binaries means having some available, which is a bit harder to sort out.
<hallyn> yup, as i need to hack on adt anyway i was going to write a script for that at least locally
<stgraber> infinity: well, I'd go with a simple test which grabs the supported core tarballs and try to chroot into them, which would incidently check that the host arch still works as otherwise you'd get an error when calling chroot :)
<hallyn> i was just gonna go with each of the templates which lxc-download supports...
<infinity> stgraber: Can the adt infra download from cdimage?
<stgraber> infinity: I'm not aware of any location it can't download from. The LXC adt tests use gpg from outside servers and then grab stuff from external servers and those passed fine in adt, so it looks like they have unfiltered access to the outside.
<stgraber> infinity: oh actually, no, it does seem to be restricted, I guess it was the test adt box I was using somewhere which wasn't... last run of lxc adt had two failures for things using our pre-built images...
<hallyn> german mirror still offering me the broken version.  wonder how long that'll go :(
<infinity> hallyn: Don't have much (any) control over third-party mirrors. :/
<pitti> Good morning
<tjaalton> fstrim cron spams when the ssd is not intel or samsung
<pitti> tjaalton: oh, oops; can you please file a bug against util-linux with the mail and assign it to me?
<tjaalton> yes, on it already
 * zyga wonders if unity startup failure is that protobuf symbol he read about yesterday
<tjaalton> hmm actually the spam is from a hdd
<tjaalton> i've a raid mirror which it complains about
<zyga> ara: hey
<zyga> ara: are you on 14.04?
<ara> zyga, yes
<zyga> hmm
 * zyga wonders why unity crashes and looks at logs
<ara> zyga, I didn't update yesterday, though
<ara> zyga, look at this thread: https://lists.ubuntu.com/archives/ubuntu-desktop/2014-February/004425.html
<ara> zyga, might be related?
 * zyga tries to recall how to copy paste in screen
<zyga> yay
<zyga> hmm, my protobuf is still 2.4.1, no 2.5 in sight
<zyga> and seb isn't around yet
<zyga> ara: yeah, that is what I suspected, wonder how to fix it now
<ara> zyga, it seems that updating should be enough
<zyga> ara: nope, the 2.5 version isn't out yet
 * zyga adds proposed and checks
<ara> zyga, did you apt-get update? protobuf is on 2.5 in trusty
 * zyga is depressed by the whole release stuff
<zyga> ara: yes, just a second ago
<zyga> ara: not for me? which package did you check
<zyga> (and it obviously didn't work which is another thing)
<ara> protobuf
<ara> https://launchpad.net/ubuntu/+source/protobuf/2.5.0-8ubuntu1
<zyga> I checked libprotobuf7 it is 2.4.1, libprotobuf8 is at 2.5 (and I have it installed) but it still doesn't work
<zyga> and it wasn't updated just now so I already had 2.5 when booting this morning
<zyga> (not ubuntu release)
<tjaalton> did we move from dmraid to mdadm?
<tjaalton> according to the blueprint; not yet
<fsvend`> i'm creating a ubuntu based distro and have issues due to udev not creating device nodes in /dev, which is because devtmpfs is not mounted. now, there's devtmpfs entry in /lib/init/fstab, and it works when mounting it manually via mount -a, but mountall doesn't mount it. anyone?
<fsvend`> now i see the same behaviour on raring ringtail, ie. there's no devtmpsfs mounted on /dev.. so i guess you have created the device nodes manually? is that the case for raring?
<tjaalton> udev on /dev type devtmpfs (rw,mode=0755)
<tjaalton> looks fine here
<fsvend`> tjaalton: on raring?
<fsvend`> tjaalton: whats your udevd version?
<tjaalton> no trusty
<tjaalton> raring is EOL
<fsvend`> tjaalton: i'm targeting saucy (for now) on my target (udevd version 204), but i see the same problem on raring (on host, udev version 175)
<tjaalton> doing something wrong then
<fsvend`> tjaalton: mountall --verbose just seem to ignore the devtmpfs entry
<fsvend`> tjaalton: well, on my target, possibly yes.. but the raring version is as you made it
<tjaalton> same thing on precise and quantal here, so yes it's wrong on your end
<fsvend`> tjaalton: that's useful info.. btw, i got a quantal server here, and the output from mount doesn't mention devtmpfs. how do you retrieve that info?
<tjaalton> mount
<fsvend`> tjaalton: sorry. bad mad. grep helped me spot it :)
<fsvend`> s/bad mad/my bad/
<fsvend`> tjaalton: still no devtmpfs on target though. i have support for devtmpfs in the kernel, and it works when using mount -a
<tjaalton> still not my problem :)
<fsvend`> tjaalton: right :)
<robert_ancell> mardy, can you upload the unity-control-center changes in gnome-control-center-signon now? We've switched the seed to u-c-c (bug 1257505)
<ubottu> bug 1257505 in gnome-control-center-signon (Ubuntu) "Create Unity Control Center so can remain on old GNOME Control Center version" [Medium,In progress] https://launchpad.net/bugs/1257505
<mardy> robert_ancell: cool, will do soon
<robert_ancell> thanks
<pitti> lightdm  23418  0.0  0.0  56520 12088 ?        R    10:56   0:00 /usr/bin/python3 /usr/bin/click pkgdir com.ubuntu.clock
<pitti> does anyone know what that is?
<pitti> (on my amd64 desktop, trusty du jour)
<pitti> it's been running for a long time already, and eating CPU
<ogra_> curious
<lool> Hmm I have some issue with the lightdm session startup on my desktop
<lool> it seems racy; I get some vague g_dbus_connection_real error in the log, sometimes it comes up sometimes not
<tvoss> hmmm, interesting, I cannot connect to 5Ghz wifi access points anymore
<lool> lol
<lool> 3 different bgus
<ogra_> tvoss, ChickenCutlass had the same issue
<lool> so if I stop lightdm + statr lightdm => no luck; if I restart lightdm, it works
<ogra_> (he just pragmatically changed the channel on his AP though)
<tvoss> ogra_, weird
<tvoss> ogra_, I have got a devolo network over power thingy here :) need to see if that would work
<ogra_> tvoss, well, still someone should tell the kernel team :)
<tvoss> ogra_, I would think so
<ogra_> (or cyphermox_, if it is NMs fault)
<pitti> ah, it seems phablet-tools pulls in click now
<pitti> click keeps getting respawned with the same command line, indefinitely
<tvoss> sergiusens, ^
<ogra_> but there were no changes since the 22nd
<lool> bah and under strace it works 100% of the time of course
<ogra_> intresting that you didnt notice this before then
<lool> grmlblb
<ogra_> lool, dont you love races ? :)
<ogra_> lool, btw, restart never worked for me, i always had to stop/start (restart left a hanging lightdm around)
<sergiusens> pitti, are you referring to th upstart stuff?
<pitti> sergiusens: I don't know; I just heared my CPU fan go wild for 10 mins and checked in top that it's due to that
<ogra_> pitti, did you upgrade between the 22nd and today (apart from today)
<pitti> ogra_: certainly, I upgrade every day
<sergiusens> pitti, it might be upstart jobs and rerunning apparmor and checking for clicks
<ogra_> well, then it cant be phablet-tools itself i'd say
<ogra_> there was an apparmor-click change tonight
<pitti> ogra_: no, that's just what pulls in upstart-app-launch, click, etc.
<ogra_> pitti, right, but since the 22nd already
<pitti> I purged click and its rdepends and reinstalled phablet-tools, seems it's tame now
 * sergiusens has a pending task to split the package into smaller bits
<ogra_> * apparmor/click.py: adjust to add mock_testenv and honor it to skip
<ogra_>     checking apparmor_dirs when set
<lool> so it seems it's gnome-settings-daemon not happy about something
<ogra_> pitti, might be that your PC has some mock stuff around others dont ;)
<lool> http://paste.ubuntu.com/6884348/
<lool> this is specific to failing startups:
<lool> ** (gnome-settings-daemon:30698): WARNING **: Unable to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
<pitti> hm, we don't install a .service for gnome-session as we don't dbus-activate it (and don't want to)
<pitti> lightdm is supposed to just start it; so perhaps gnome-session crashed?
<pitti> lool: do you have a .crash file for something like g-sessin?
<lool> it's possible, albeit hard to tell
<lool> no
<lool> just susres, whatever that is
<lool> ah suspend resume
<lool> old
<lool> pitti: it doesn't even start gnome-session
<seb128> pitti, your click issue should be fixed by https://launchpad.net/ubuntu/+source/indicator-datetime/13.10.0+14.04.20140205-0ubuntu1
<seb128> infinity, thanks for fixing libcmis
<lool> so what I did was replace gnome-session with a wrapper script that calls strace gnome-session.real, and this never created a strace
<lool> I did manage once to catch a strace of a failed startup of unity-greeter in the same way
<lool> it never fails if I strace -f though
<seb128> lool, what's your issue?
<seb128> lool, greeter one?
<lool> seb128: lightdm greeter not coming up
<lool> but racy
<lool> sometimes it does
<seb128> lool, when did it start?
<lool> seb128: it might have happened rarely previously; it's a new install; it started appearing a lot in the last days
<lool> yesterday was when I first realized there was something bad going on
<Unit193> seb128: Just a quick poke, mearly to make sure it hasn't fallen off the radar.
<seb128> lool, ok, because the new indicator-datetime update from yesterday/the click issue pitti described made the greeter not load for kenvandine
<lool> I did some changes to my own user session (to start an upstart job as ~lool) but that shouldn't affect greeter
<lool> seb128: aha
<seb128> lool, that's fixed in this night update (the one I Just pointed to pitti)
<seb128> lool, indicator-datetime update that is
<seb128> Unit193, what is "it"
<seb128> ?
<Unit193> indicator-sound pavucontrol alt recommend.
<lool> seb128: but I dist-upgraded already
<seb128> lool, did you restart the greeter since and still get the issue?
<lool> seb128: Yes
<pitti> seb128: ack, thanks; I got a load of new packages now, I'll reboot
<seb128> lool, try uninstlal indicator-datetime in case? or maybe you have a different issue...
<seb128> pitti, yw!
<seb128> Unit193, I pinged people about it yesterday, let me check
<Unit193> Cool, danke.
<seb128> Unit193, approved
<Unit193> Nice, thanks.
<mardy> robert_ancell: can you please create a MP for this? https://code.launchpad.net/~robert-ancell/gnome-control-center-signon/unity-control-center
<robert_ancell> mardy, syre
<robert_ancell> sure
<lool> hmmm why dont I see strings in execve but only pointers
<lool> in my strace
<robert_ancell> seb128, can you review too https://code.launchpad.net/~robert-ancell/gnome-control-center-signon/unity-control-center/+merge/205110
<lool> http://paste.ubuntu.com/6884429/ is strace -e trace=process of unity-greeter
<robert_ancell> lool, do you have lightdm.log
<lool> robert_ancell: http://paste.ubuntu.com/6884441/
<lool> sorry had to reproduce the issue
<robert_ancell> lool, you have the same problem as Ken
<lool> I have to do a roundtrip to school, brb
<lool> robert_ancell: I have latest datetime though
<lool> brb
<smb> apw, Ok, I attached a debdiff for systemd (which contains the udev rules we have to modify) to bug 1277006
<ubottu> bug 1277006 in udev (Ubuntu) "[Trusty] Need additional udev rule to avoid efi framebuffer to be primary" [High,Triaged] https://launchpad.net/bugs/1277006
<robert_ancell> fginther, did those jenkins jobs get set up OK?
<robert_ancell> seiflotfy__, are you OK with ps-jenkins being added to ~activity-log-manager?
<tseliot> cjwatson: any chances I can deliver one last fix? (apparently a regression)
<lool> robert_ancell, seb128: I replaced indicator-datetime-service with /bin/true and I was still able to trigger the race
<lool> like one time out of 4
<seb128> lool, ok, maybe a redherring then
<seb128> or another issue
<cjwatson> tseliot: !
<cjwatson> tseliot: um, I'm not sure that's realistic.  details?
<tseliot> cjwatson: apparently my last upload of fglrx-pxpress keeps on writing "y" to a log file... two users reported this to me this morning
<tseliot> cjwatson: and the log file keeps growing...
<cjwatson> fglrx-pxpress isn't on images, right?
<cjwatson> (hope not.)
<cjwatson> it doesn't seem to be.  so delivering your fix is basically independent of 12.04.4
<cjwatson> but yeah, let's get that in
<tseliot> cjwatson: no but jockey can install it if the fglrx is installed. I assume we don't install fglrx in ubiquity
<tseliot> *fglrx driver
<tseliot> ok, good
<tseliot> I'll come up with a fix soon
<xnox> tseliot: y would it do that? =) silly driver... =)))))
<tseliot> xnox: :D it's really an upstart job to handle multiple gpus that does that
<pitti> smb: please don't upload bug 1277006 just yet
<ubottu> bug 1277006 in systemd (Ubuntu) "[Trusty] Need additional udev rule to avoid efi framebuffer to be primary" [High,Triaged] https://launchpad.net/bugs/1277006
<pitti> smb: I applied it to my local git, but that has staged changes
<smb> pitti, I could not even if I wanted, but stop apw (in case he would)
<smb> Which we should have now
<pitti> smb: I'll upload it now
<smb> pitti, ok
<apw> pitti, hey .. we probabally want to include vesafb in the list of "non-primary" framebuffers while you are there
<pitti> apw: hey Andy
 * smb notes it would be called vesa-framebuffer
<pitti> apw: good timing, two seconds away from dput :)
<apw> heh :)
<apw> i was lucky
<apw> pitti, what smb said
<pitti> smb, apw: http://paste.ubuntu.com/6884698/ ?
<pitti> DRIVERS=="nouveau", GOTO="graphics_end"
<pitti> hm, is that still current?
<pitti> oh wait, fun
<pitti> we have a first rule
<pitti> DRIVERS=="nouveau", ENV{PRIMARY_DEVICE_FOR_DISPLAY}="1"
<pitti> (or set of rules, for i916 and radeon, too)
<smb> pitti, The vesa line looks good to me (DRIVER=vesa-framebuffer in one of my laptops)
<pitti> ah, so the first set is for DRM, the second set for fb
<apw> yeah that looks right to me, and smb has the kit to test it
<apw> yeah two separate things in there
<apw> to confuse the reader
<pitti> $ udevadm info --export-db|grep 'DRIVER.*-framebuf'
<pitti> E: DRIVER=efi-framebuffer
<pitti> ack, adding vesa-framebuffer then
<apw> smb, pitti, what about simple-framebuffer, wasn't that one you wanted smb ?
<smb> pitti, both
<apw> or am i getting confused
<smb> Err
<smb> wait
<pitti> *-framebuffer would be too much?
<smb> simple-framebuffer just in case we ever would have it and thats not likely for T... (except arm maybe)
<pitti> there is never the  case that X would start on such a framebuffer, even if you don't have a "better" graphics card installed?
<apw> yeah it would as we are only trying to ignore the "fallback franebuffer drivers"
<apw> pitti, so all this affects is whether it is marked "PRIMARY", and if it is splash is started much earlier to get prettyness
<pitti> so http://paste.ubuntu.com/6884708/ is the current version now
<apw> if no PRIMARY is found, we will start splah on whatever it can cope with, which wold include the "excluded" ones you are adding
<smb> pitti, ack
<pitti> smb: thanks for checking; uploading then
<apw> smb, i thought simple-framebuffer was the one at issue in your kvm spot, where it is being replaced
<smb> apw, Yes, before we flipped the config to not build it at all
<apw> oh ok
<jdstrand> ogra_, sergiusens, pitti: I don't have all the context, but... the click-apparmor change ogra mentioned doesn't actually do anything with the installed package-- ie, it will behave the same as it did before the upgrade
<ogra_> jdstrand, yeah, seems it was indicator-datetime that caused it
<jdstrand> ok
<jdstrand> cool
<Riddell> anyone know anything about mythbuntu? (I'm trying to test 12.04.4 candidates)
<ogra_> its a myth !
 * xnox feels thrilled to use: try... except... else... finally... clause in python!
<Riddell> using extern c {} can't be far away now
<tseliot> cjwatson: I've just uploaded the fix in precise-proposed -  fglrx-pxpress (0.6~hybrid0.0.2) for bug #1277058
<ubottu> bug 1277058 in fglrx-pxpress (Ubuntu Precise) "Process keeps writing to the log" [Critical,In progress] https://launchpad.net/bugs/1277058
<cjwatson> tseliot: thanks, reviewing
<pitti> jdstrand: yes, I think the latest indicator-datetime fixed that
<tseliot> cjwatson: thanks!
<TheNano> Hi dear developers, I am loking for a project in C/C++ that needs contribution, the prgraming level I look for is Embdded programming or very close to hardware programming, not necessary hardware driver but things in that style. As I can't rignt now choose a project or part of Ubuntu by my own interest I am open for suggestion and probabaly if someone feels for it a Mentor trough my start. I am a hardware/embdded M.S.c. gradua
<tomreyn> hi there
<tomreyn> is it still possible to get debian packages into 14.04?
<cjwatson> yes
<tomreyn> i thinkt he deadline is today?
<cjwatson> only for automatic operation
<ogra_> no
<tomreyn> what's "automatic operation"?
<cjwatson> manual requests will be possible without any particular justification up to feature freeze (https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule)
<ogra_> automatic imports from the debian archive
<shadeslayer> tseliot: ping
<cjwatson> up to today we automatically sync changes in Debian to packages we haven't modified in Ubuntu
<cjwatson> (end of today, I expect)
<tomreyn> so February 20th is the deadline for manual imports on request
<tomreyn> thanks
<tseliot> shadeslayer: pong
<shadeslayer> tseliot: I was wondering, is there a way we can prevent aptdaemon from being pulled into the Kubuntu ISO? I believe the reason why it's pulled in right now is due to ubuntu-drivers-common
<tseliot> shadeslayer: is it too big?
<shadeslayer> apachelogger: ^^
<apachelogger> tseliot: it is not used
<apachelogger> we have qaptworker which pretty much is a qt version of aptdaemon
<tseliot> pitti: any ideas? ^
<pitti> shadeslayer, tseliot: it's being used for mapping modaliases to driver packages
<tseliot> apachelogger: ^
<shadeslayer> pitti: I thought that was done internaly in detect.py and the pkkit functionality was only a addon
<shadeslayer> and not critical to ubuntu-drivers-common
<pitti> yes, it is
<pitti> i. e. if you don't need that functionality on the PackageKit API level, we can drop it to a suggests
<pitti> u-d itself just uses python-apt for that
<shadeslayer> pitti: yep, we don't really need the functionality on the pkkit API level
<apachelogger> (we are not using any PK API on the KDE side of things)
<apachelogger> all hard wired to qapt->libapt-pkg
<shadeslayer> ^^
<pitti> tseliot, apachelogger, shadeslayer: https://github.com/tseliot/ubuntu-drivers-common/commit/2a53800
<shadeslayer> \o/
<tseliot> pitti: great :)
<apachelogger> pitti: thank you
<pitti> how soon do you need this uploaded?
<apachelogger> pitti: can wait, it's just wasting space, as long as it lands before release we should be fine ^^
<pitti> yeah, still plenty of time
<shadeslayer> pitti: on that note, could you also have a look at 1274605
<shadeslayer> or maybe poke someone on the firefox packaging team^^
<pitti> bug 1274605
<ubottu> bug 1274605 in firefox (Ubuntu) "Please demote xul-ext-ubufox from Firefox Recommends to Suggests" [Undecided,New] https://launchpad.net/bugs/1274605
<pitti> yeah, not my area I think
<dholbach> blueyed, happy birthday! :)
<pitti> chrisccoulson: ^
<fginther> robert_ancell, yes, the jobs are deployed and ready
<robert_ancell> fginther, great, thanks!
<rbasak> What should we do for Vcs-* control fields in merges? Leave them pointing them at Debian? Pull them out?
<cjwatson> prepend XS-Debian-
<shadeslayer> I believe they should be changed to : XSBC-Debian
<cjwatson> not BC
<shadeslayer> oh, ok
<cjwatson> I mean you sort of can but it's redundant, they're source information so just XS-
<shadeslayer> cjwatson: on that note, do you have a document that explains those?
<shadeslayer> google doesn't give me anything
<cjwatson> policy
<cjwatson> I think ...
<cjwatson> shadeslayer: at least it's in deb-src-control(5) under "USER-DEFINED FIELDS"
<rbasak> Understood - thanks!
<shadeslayer> cjwatson: ah, thx
<Riddell> dobey: could you take a look at https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112 ?
<dpm> Riddell, I think he mentioned you'd have to get hold of danilo to review that one. I tried to get in touch with him for this MP a while ago, but he wasn't around
 * Riddell e-mails
<dobey> you need to get danilo to re-review
<dobey> i can't change danilo's vote for him on lp
<shadeslayer> ev: ping, have a moment to talk about errors.ubuntu.com?
<josepht> shadeslayer: ev is on holidays through the 14th
<shadeslayer> oh
<shadeslayer> josepht: thanks
<shadeslayer> anyone else whom I can talk to about e.u.c ?
<shadeslayer> We have a patch in Kubuntu that has started reporting crashes to e.u.c ( for eg https://errors.ubuntu.com/oops/fe95cba8-60c0-11e3-b76d-e4115b0f8a4a ) but the top 4-5 frames of that crash are from the crash handler, which might confuse e.u.c into thinking that KCrashHandler is crashing
<shadeslayer> would daisy be need to modified so as to not think that kcrashhandler is crashing?
<shadeslayer> or is everything fine and it'll work perfectly
<shadeslayer> pitti:  tseliot: one of the other requests for ubuntu-drivers-common, drivers like nvidia-173 are super duper old and should probably have a key/value pair that says that these should be the least preferred driver
<shadeslayer> and maybe even have generic labels such as "Wireless Card" so that users don't have to see "Broadcom ABCD a/b/g/n" in the ui
<tseliot> shadeslayer: I'm going to change the packages descriptions, so that we get better descriptions in the UI
<tseliot> that's not hardcoded in u-d-c
<tseliot> it's in the single packages
<shadeslayer> tseliot: yay \o/
<shadeslayer> tseliot: I use short descriptions in my UI : http://im9.eu/picture/dz7621
<robert_ancell> seiflotfy__, around?
<tseliot> shadeslayer: I see. I'll take care of that as soon as I'm done with some more work in ubuntu-drivers-common
<shadeslayer> cool
<shadeslayer> tseliot: anything exciting coming up in ubuntu-drivers-common?
<tseliot> shadeslayer: a program which handles multiple gpus or configuration changes on boot
<tseliot> e.g. you unplug a graphics card, or add one card
<shadeslayer> ah cool, I'll keep an eye out for those
<tseliot> :)
<shadeslayer> tseliot: something that came up during the development of the KDE Frontend, my ui is all C++ and I'm using a python script to export data over dbus
<robert_ancell> ricotz, I'm trying to find someone who can add ps-jenkins to ~activity-log-manager. I think you could do that right?
<shadeslayer> might be useful to have a dbus interface by default?
<tseliot> shadeslayer: this is something you might want to discuss with pitti
<shadeslayer> ack
<seiflotfy__> robert_ancell: go crazy
<ricotz> robert_ancell, yeah, can do, if seiflotfy__ doesnt beat me to it
<robert_ancell> it's a race :)
<robert_ancell> the prize is.... a beer at the next physical meetup
<robert_ancell> or alternative drink
<ricotz> done ;)
<seiflotfy__> ricotz: won
<robert_ancell> ricotz, ta!
<shadeslayer> Anyone have a clue how firefox knows how to handle apt:// urls?
<jussi> yeah, theres an ubuntu apt settings or some such package
<jussi> shadeslayer: ^^
<shadeslayer> jussi: I see, however it doesn't seem to work in Kubuntu
<jussi> also... http://askubuntu.com/questions/336853/how-to-install-usign-the-apt-url-on-ubuntu-12-04
<shadeslayer> jussi: yeah tried that, does not work
<robert_ancell> fginther, I don't see unity-control-center in https://jenkins.qa.ubuntu.com/view/All/
<mdeslaur> shadeslayer: the apturl-common package installs a desktop file to /usr/share/applications that contains the mime type for handling apt
<shadeslayer> it most certainly does, but that doesn't work in Firefox under Kubuntu for some reason
<shadeslayer> nor do I see the protocol registered in Firefox
<fginther> robert_ancell, nothing will show up there until a job is executed and published. You can see the 'real' job here: http://s-jenkins.ubuntu-ci:8080/job/unity-control-center-ci
<mdeslaur> shadeslayer: oh, I guess firefox doesn't have kde integration for mime types
<robert_ancell> fginther, ah, thanks
<shadeslayer> mdeslaur: yeah
<mdeslaur> shadeslayer: I'm told there used to be a firefox patch for kde integration, but it got dropped as nobody wanted to maintain it
<shadeslayer> mdeslaur: hmm, well, I do maintain patches for Firefox that do KDE integration, however I wouldn't want them in the archive
<Logan_> mr_pouit: sent you an email - quick question about the xfce4-indicator-plugin merge
<shadeslayer> hah
<shadeslayer> apt urls don't even work on Ubuntu?
<shadeslayer> this is what I see http://im9.eu/picture/vo7621
<shadeslayer> chrisccoulson: ^^
<spineau> mterry: hello, as you already approved a MIR of a future checkbox dependency, plainbox (it was bug 1265754). May I ask you to review bug 1276164 and bug 1276183? Both should be easy to do (just about code re-organization)
<ubottu> bug 1265754 in plainbox (Ubuntu) "[MIR] plainbox" [Undecided,Fix released] https://launchpad.net/bugs/1265754
<ubottu> bug 1276164 in checkbox-support (Ubuntu) "[MIR] checkbox-support" [Undecided,New] https://launchpad.net/bugs/1276164
<ubottu> bug 1276183 in plainbox-provider-resource-generic (Ubuntu) "[MIR] plainbox-provider-resource-generic" [Undecided,New] https://launchpad.net/bugs/1276183
<tomreyn> shadeslayer: i think the "apturl" package needs to be installed (i don't know whether it is by default), also you need to keep the ubuntu firefox extension enabled.
<shadeslayer> tomreyn: The apturl package is installed
<shadeslayer> that's from the ubuntu 13.10 live session
<mterry> spineau, sure, I'll try to get to them today
<spineau> mterry: thanks a lot
<shadeslayer> tomreyn: http://im9.eu/picture/vl7621
<tomreyn> shadeslayer: hmm i had expected that to work. i'm on a 13.10 installation here, using xubuntu (xfce), and clicking apt:// url spawns software center for me (which then displays info on the given package)
<mdeslaur> shadeslayer: bug 1261178
<ubottu> bug 1261178 in firefox (Ubuntu) "apturl links stopped working after firefox 16" [Undecided,New] https://launchpad.net/bugs/1261178
<shadeslayer> tomreyn: I see
<infinity> seb128: No problem.  It always bugs me when I see something in binary NEW for all but one architecture. :)
<tomreyn> shadeslayer: you could try updating the system you started from this live cd, and to restart firefox in the end of the process
<tomreyn> might help
<shadeslayer> tomreyn: downloading trusty
<shadeslayer> to check if I can reproduce it in the latest images
<seb128> infinity, hey
<seb128> infinity, since you are an u-a admin, how would we go about adding somebody to the team? ;-)
<infinity> seb128: We'd need to discuss it with the team internally, and with Laney, and then if all parties are cool with the idea, do a bit of training (if necessary), then add him.
<infinity> seb128: It's an invite-only thing, for obvious reasons, not a "you volunteer, you get in" deal, but I suspect Laney's got more or less the skill needed.  We'll talk it out on Monday with various members of the team.
<Laney> Ta
<seb128> infinity, thanks
<robert_ancell> fginther, still confused about the u-c-c Jenkins job - has it noticed https://code.launchpad.net/~larsu/unity-control-center/wrap-keyboard-label/+merge/205201?
<tseliot> cjwatson: the fix for bug #1277058 has been tested
<ubottu> bug 1277058 in fglrx-pxpress (Ubuntu Precise) "Process keeps writing to the log" [Critical,Fix committed] https://launchpad.net/bugs/1277058
<shadeslayer> so anyone else have an idea why this is not working? all the bits seem to be there
<sarnold> shadeslayer: probably just lacks someone to spend the time to debug and fix it. and refix it every so often? :)
<fginther> robert_ancell, hmm, looking
<cjwatson> tseliot: released, thanks
<tseliot> cjwatson: thanks a lot for your help
<fginther> robert_ancell, the logs indicate that ps-jenkins is not authorized to do the review
<fginther> robert_ancell, ps-jenkins is not a member of https://launchpad.net/~ubuntu-desktop
<robert_ancell> fginther, it has to be the project maintainer not just a driver?
<fginther> robert_ancell, drivers don't appear to have review/merge privilege
<robert_ancell> fginther, I'm looking at other projects wondering how they work...
<robert_ancell> fginther, e.g. for Mir - it is owned by ~pspmteam which ps-jenkins doesn't seem to be involved with and driven by ~mir-team
<fginther> robert_ancell, ps-jenkins is an indirect member of https://launchpad.net/~mir-team
<fginther> PS Jenkins bot â Canonical Product Strategy â Mir development team
<fginther> robert_ancell, the original solution for enabling jenknis was that "Canonical Product Strategy" would be a member for all projects
<robert_ancell> fginther, right, and it is a member of ~unity-control-center-team which is the equivalent
<robert_ancell> fginther, oh, the branch is in ~ubuntu-desktop - I'll move it
<fginther> doh!, didn't think to look at that
<robert_ancell> fginther, ok, fixed - do we need to re-trigger jenkins?
<robert_ancell> fginther, np, we have to move the MPs anywa
<fginther> robert_ancell, in this case it should pick it up on the next poll starting now
<infinity> cjwatson: Should binfmt-support perhaps do some hand-holding to make sure you don't install binfmts for formats the running system supports, without some angry override flag?
<infinity> cjwatson: The oops in qemu-user-static yesterday where it accidentally installed itself as a handler for x86 on x86 was... Fun.
<cjwatson> infinity: maybe; it's been a readme/todo kind of level item for me for a long time.  the trick is figuring out how to express that condition sensibly
<cjwatson> preferably without ridiculous amounts of per-arch maintenance
<infinity> cjwatson: I suspect a static arch table is going to be nearly unavoidable, unless there's a way to ask the kernel what it supports?
<infinity> (A static arch table is what qemu-user-static uses, and that's what got broken in the upload :P)
<cjwatson> infinity: really, I think the *kernel* should prevent you shooting yourself in the foot here
<cjwatson> I appreciate that's buck-passing ... but it's really very easy to commit suicide via binfmt_misc
<infinity> cjwatson: Perhaps, though there might be some esoteric reason for testing or fiddling why you might want the kernel to let you do such silly things.
<infinity> And kernel interfaces very rarely have a --no-really-i-mean-it flag.
<shadeslayer> tomreyn: I possibly have a fix
 * shadeslayer is testing in a live session to make sure
<infinity> cjwatson: I suppose /proc/sys/fs/binfmt_misc/ could grow an "unsafe" node, defaulting to 0.
<shadeslayer> ah no :(
<shadeslayer> so I do have it working, I just don't know how >.>
<dobey> anyone else on trusty with intel video having weird graphic anomolies after updating to the latest kernel/xorg?
<mdeslaur> dobey: I see some lines in windows from time to time which disappear when I click on them
<dobey> mdeslaur: yeah, i'm getting that and some other similar things that look like maybe the framebuffer didn't get updated properly, but which "fixes" itself after some interaction
<mdeslaur> dobey: do you see it on other windows than firefox and thunderbird?
<mdeslaur> I seem to notice it's only on those windows, but haven't confirmed yet
<dobey> mdeslaur: yes. am seeing it quite consistently in qt apps, and have seen it in a few gtk+ apps as well
<mdeslaur> ok
<dobey> qjackctl's buttons are always messed up when i start it now
<Sarvatt> dobey: https://bugs.freedesktop.org/show_bug.cgi?id=74327 , it should be fixed in 2.99.910 probably tomorrow
<ubottu> Freedesktop bug 74327 in Driver/intel "[snb] rendering corruption" [Normal,Resolved: fixed]
<dobey> Sarvatt: ok, thanks
<Sarvatt> dobey: https://launchpad.net/~xorg-edgers/+archive/ppa/+files/xserver-xorg-video-intel_2.99.909%2Bgit20140206.823382d2-0ubuntu0sarvatt_amd64.deb if you dont want to wait :)
<shadeslayer> pitti: btw ubuntu-drivers-common doesn't list linux-firmware-nonfree as something that can be installed
<dobey> Sarvatt: i'll wait for now, unless i am forced to log out for some reason :)
<shadeslayer> pitti: because my wireless drivers come from linux-firmware-nonfree but the ones from the Broadcom STA package don't work ( or didn't work last time I tried )
<Sarvatt> dobey: it may actually be monday, uploading it on a friday would be sketchy :)
<_nedr> WOW.. ubuntu finally gonna ditch nautilus!!!!! HALLELUJAH! DIE IN HELL NAUTILUS, OMG WTF OKTXBAI!!!
<dobey> wow, someone likes poor journalism
<shadeslayer> ^^
 * shadeslayer rages at firefox instead
<cjwatson> there we go, 12.04.4 out
<ari-tczew> \o/
<sarnold> cjwatson: woot, thanks :)
<arges> bdmurray: hi
<arges> bdmurray: how can I help you today with the sru queue?
<mdeslaur> \o/ 12.04.4!
<bdmurray> arges: I haven't looked at it at all yet.  I'd start with http://people.canonical.com/~ubuntu-archive/pending-sru.html
<Noskcaj> xfce4-weather-plugin plz
<arges> bdmurray: what would be most useful for me to look at first? should i go through the yellow bugs?
<bdmurray> arges: yeah, since there are not any that are all green
<genii> console-tools is not installable but referred to by another package, etc...
<genii> ( 14.04 )
<Ampelbein> genii: Debian bug 671342
<ubottu> Debian bug 671342 in ftp.debian.org "RM: console-tools -- ROM; No longer maintained upstream" [Normal,Open] http://bugs.debian.org/671342
<sassyn> hi all
<sassyn> I'm a new baby when it come to pbuilder
<sassyn> howerver, I have a question like this
<sassyn> I want to build a pkg from 13.10 to version 10.04
<sassyn> I manage to do so, by someing some changes to the rule/control/compact files
<sassyn> had to take 5 pkgs and compile then as well in 10.04
<sassyn> so by now I had all deps
<sassyn> pkg seems to be working with no issue
<sassyn> howerver i want now to make the same for 10.10, 11.04 etc..
<sassyn> so I used pbuilder
<sassyn> configure also a local repo
<sassyn> so far so good
<xnox> sassyn: backportpackage command part of ubuntu-dev-tools is your friend.
<sassyn> xnox, but I'm kind of lost
<sassyn> like 4 days until I got how pbuilder works
<xnox> sassyn: also #ubuntu-packaging or #ubuntu-motu are usually more appropriate for pure packaging questions.
<sassyn> ok sorry
<sassyn> will swith to it
<xnox> sassyn: read $ man backportpackage
<xnox> sassyn: no, stay, since you started here =)
<sassyn> :-)
<sassyn> thank u
<xnox> sassyn: just read $ man backportpackage
<sassyn> i did
<xnox> sassyn: it's fairly trivial to operate, and it does all the pbuilder-foo and/or upload to a ppa for you.
<xnox> sassyn: if you did changes just point backportpackage at your modified .dsc
<sassyn> not sure I got u
<sassyn> say I got ulogd2
<xnox> sassyn: backportpackage -d quantal hello_2.3-3~sassyn1.dsc
<xnox> ditto - natty, maverick, etc.
<sassyn> ok
<sassyn> checking
<xnox> sassyn: note that 10.10 & 11.04 are long end-of-life so a ppa will not build them for you, and pbuilder needs to be pointed at "old-releases.ubuntu.com" as the archive/url to bootstrap from.
<sassyn> so let me just understand
<sassyn> I install 14.04 for example
<sassyn> then I just do backportpackage -d quantal hello_2.3-3~sassyn1.dsc
<sassyn> and I get the package for quantal?
<xnox> yes.
<sassyn> just need to add the /etc/apt/source.list to point to quantal
<sassyn> repo
<xnox> sassyn: no, you don't need to modify your own /etc/apt/source.list at all.
<xnox> sassyn: why do you say that?
<sassyn> cause 14.04 need to know which pkg are in the dest version
<xnox> sassyn: it doesn't need that to start running backportpackage.
<sassyn> i will read again
<xnox> sassyn: backportpackage will first build a source package, and then invoke a quantal pbuilder => which has quantal packages only and source, and build the package in pristine quantal chroot.
<xnox> sassyn: adding a quantal to /etc/apt/source.list will not make your machine suddently a quantal-capable one =)
<sassyn> reading
<xnox> sassyn: invoke backportpackage, and read the log.
<sassyn> to better understand
<sassyn> u are so lucky to know this
<sassyn> :-)
<xnox> sassyn: then you'll understand. no need to try to comprehend this ahead of trying it out.
<sassyn> sorry I just don't get it
<sassyn> i have a foo.dsc file which some from version 13.10 and I want to port it to work with 10.04
<sassyn> come*
<sassyn> if I go with 13.10 then I can build it localy, if I create a base image using pbuilder for 10.04 then some dep are missing. so what I did is start building one by one for 10.04
<sassyn> create a local repo for 10.04 with the dep files
<sassyn> so by the end I could create the foo.sc
<sassyn> then I say there are some magic way to do it from me
<sassyn> so I can add in 10.04 point to the 13.10 repo
<sassyn> and in some magic way it download all deps
<sassyn> but then it failed
<sassyn> so I miss here something
<sassyn> what do i miss here xnox
<xnox> sassyn: backportpackage -> helps automate backporting one package at the time, if you need to backport additional debs, one would invoke it on each missing dependency and indeed create a repository with them somewhere and add it to the pbuilder used.
#ubuntu-devel 2014-02-07
<xnox> sassyn: but since 10.04 is still a support releases, you can ask a launchpad ppa to build them for you. So invoke backportpackage with a ppa argument for each and every missing dependency in 10.04
<xnox> sassyn: and in the end the package you are after would be backported into 10.04 via that ppa.
<xnox> sassyn: alternative is to modify the package you are after, to have less dependencies or not rely on version/features that are not available to make backporting easier.
<sassyn> what do u mean by that  So invoke backportpackage with a ppa argument"
<sassyn> u really helpful xnox
<sassyn> thank u
<xnox> sassyn: read $ man backportpackage, especially the three examples in the "EXAMPLES" section on the bottom, the third case is yours.
<xnox> sassyn: appart you'd be fetching things just by package name and source location as done in the second example.
<sassyn> xnox,
<sassyn> still reading
<xnox> sassyn: i need to go, experiment with backportpackage options, and if you get stuck again ask about on #Ubuntu-motu or #ubuntu-packaging.
<sassyn> xnox,
<sassyn> thank u sir!
<sassyn> have a nice weekend
<pitti> Good morning
<pitti> shadeslayer: does linux-firmware-nonfree's Modaliases: field contain your device?
<diwic> pitti, good morning, would you mind debcommit -r + upload lp:~ubuntu-audio-dev/alsa-tools/ubuntu and lp:~ubuntu-audio-dev/alsa-lib/ubuntu ?
<pitti> diwic: can do
<diwic> pitti, thanks :-)
<pitti> alsa-lib uploaded
<pitti> diwic: alsa-tools uploaded, too
 * diwic gives pitti a big bowl of SpÃ¤tzle as thank you :-)
<pitti> haha
<jagadeshanh> is the problem with the WiFi resolved?
<tvoss> pitti, good morning :)
<pitti> hey tvoss, wie gehts?
<tvoss> pitti, hey, gut soweit :) und bei Dir?
<pitti> tvoss: prima, danke
<sassyn> hi all
<sassyn> backportpackage a package failed due to unmet dependencies
<sassyn> Running a 12.04 machine
<sassyn> and trying to  backportpackage -b -s maverick -d precise -w . ulogd2_2.0.3-1ubuntu1.dsc
<Sweet5hark> Moin!
<Sweet5hark> Hi seb128, can you please review and upload http://people.canonical.com/~bjoern/trusty/libetonyek_0.0.3-0ubuntu2_source.changes ?
<seb128> Sweetshark, sure
<Sweet5hark> alrighty, Ill get a Coca-Cola for me. And a can for Will.
<seb128> Riddell, ^ wants to have a look? that's a kubuntu package it seems, Sweet5hark fixed the depends
<Riddell> seb128: Sweet5hark: looking
<Riddell> Sweet5hark: yep, good, why's it getting a MIR?
<Sweet5hark> Riddell, seb128: LibreOffice is in main, so I can either use libetonyek from main or make LibreOffice bring its own internal copy (its a hard dep). I prefer the first here.
<Riddell> good good
<seb128> Riddell, can you sponsor it if you +1? ;-)
<seb128> thanks
<Riddell> oh sure
<Riddell> Sweet5hark: uploaded
<Sweet5hark> Riddell: thanks!
<Sweet5hark> Riddell: what uses kubuntu this for btw? calligra?
<Laney> Riddell: (sorry for the ping flood) did you see the kubuntu image build failure? I guess you want to merge / sync the new synaptiks
<seb128> Riddell, thanks
<sassyn> Hi,
<sassyn> Thanks for this.
<sassyn> I followed this, but didn't manage to make it happen.
<sassyn> The problem is that the pkg I need is coming from version 14.04 and i run 12.04
<sassyn> So I dget the foo.dsc and try to build it using pbuilder, but the foo.dsc needs some other pkgs version which are no exits in the verion 12.04,
<sassyn> so it failed.
<sassyn> I started to download each required pkg (bar.dsc, zoo.dsc, etc...) that foo was depend on, but then got to a endless loop, since bar.dsc also wanted some pkg that where missing in the 12.04.
<sassyn> So I play a little with the control file of the foo pkg, and got to a point where I had only 4 pkg that need to come from version 14.04 to version 12.04.
<sassyn> I manage to build them, and also create a local repo, so the base image of pbuilder will be aware of them.
<sassyn> Then try to build the foo.dsc and failed again.
<sassyn> What am I'm doing wrong?
<sassyn> It's being a week already without any sleep - and I just can't figure it out.
<sassyn> Help will be mot welcome!
<sassyn> Thank
<sassyn> Sassy
<sassyn> oppsss
<sassyn> sorry about that :-(
<sassyn> Group,
<sassyn> I can't manage to backport my pkg
<sassyn> need some help here. kind of lost - 1 week without any sleep - and I still can't get this pbuilder, cowbuilder, cowdancer and backport
<sassyn> if someone can help it will be great!
<Riddell> Sweet5hark: yes calligra uses it
<Riddell> Laney: let's poke shadeslayer about that one :)
<Laney> okay
<Sweet5hark> Riddell: So my spidersenses were right there ... ;)
<sassyn> Anyone?
<pitti> sassyn: it would help if you'd mention what exactly fails when you build those (pastebin the build log or so)
<sassyn> pitti,
<sassyn> sure
<pitti> sassyn: but in general you can't just lower dependencies, they are usually bumped for a reason
<sassyn> pitti, but I think I get it somehow wrong and wanted to ask someone about the all process and not specific problem I have
<pitti> sassyn: if you run into many dependencies that your package doesn't have in 12.04, you usually have to backport those as well, there are no easy shortcuts in general
<pitti> it's not unlikely that your package fails to build if you lower a build dep and build it against an old library in 12.04, etc.
<sassyn> pitti, I saw some thing call PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi"
<sassyn> doesn't this should know to grub all dep?
<sassyn> if so, I just don't understand how backport is working.
<sassyn> pitti, what I did in the beining is that I install ubuntu 12.04 got the foo pkg and started to build it. then it ask for some deps that were missing, so I download them as well.
<pitti> you already mentioned that part
<pitti> but without details of what actually goes wrong (paste a build log), nobody can help you
<sassyn> so in more general way, if pkg X of version 14.04 depend on Pkg Y from version 14.04, and I want to backport pkg X to version 12.04, what is the best way of doing so?
<pitti> as you said, backport y first
<sassyn> and what if y require Z from version 14.04?
<pitti> wash, rinse, repeat
<pitti> but if you require more than, say 5 packages, it's probably a lost cause
<cjwatson> or sometimes figure out why that dependency is present and if it can be loosened; there's no general answer to this, it requires understanding and thought and sometimes creativity
<pitti> you end up backporting half the release, and you should rather just use that release then (perhaps in a chroot)
<sassyn> pitti understood
<pitti> as cjwatson says, without build logs or even package names that's all we can say
<sassyn> the pkg is ulogd2
<sassyn> from 13.10
<sassyn> which I manage to install on 10.04
<Sweet5hark> pitti: "but if you require more than, say 5 packages, it's probably a lost cause" -- except if you are ricotz and heroically backport LibreOffice ...
<pitti> heh, yes
<sassyn> just need to download 3 orig debs from version 13.10 (which were installed by dpkg -i *) and then build 5 dep pakcages which in all of them i had to change the compact to use version 7 as I wanted to keep debhelp
<sassyn> I'm lost :-(
<sassyn> I was sure ppa will do this auto
<cjwatson> PPAs only work at the level of individual source packages; they won't automatically figure out that they need to build additional things to satisfy your build-dependencies (although of course they will install any build-dependencies that are already available), and they won't automatically make any necessary modifications to your source package
<cjwatson> they're a good way to avoid having to maintain the build infrastructure yourself
<cjwatson> but they aren't artificially intelligent
<sassyn> cjwatson, please can u tell me how
<sassyn> i think i will drink some postion
<sassyn> cause I totlay lost here
<sassyn> I don't want to go manually for each verion
<sassyn> there is no magic way?
<cjwatson> backporting from 13.10 to 10.04 is bound to be very difficult; if nothing else the addition of multiarch between 10.04 and 12.04 meant a large number of changes to a large number of library packages
<cjwatson> there is no magic way
<cjwatson> if you find yourself needing to undo multiarch changes to a package, you can try reversing the steps in https://wiki.debian.org/Multiarch/Implementation
<cjwatson> but if you're not already familiar with packaging it isn't going to be straightforward
<cjwatson> if I were you I would certainly be considering whether it would be easier to upgrade to 12.04
<sassyn> so backport will only work for a pkg from a new version only if the meet the depnedecies chain
<cjwatson> right, that's inevitable
<cjwatson> either you satisfy the dependencies or figure out how to weaken them
<sassyn> or that I can backport each one of them
<cjwatson> I'm including that in "satisfy"
<cjwatson> which build-dependencies of ulogd2 aren't satisfied in lucid already?
<sassyn> debhelper for example
<cjwatson> well, debhelper (>= 9)
<sassyn> manually change this to 7
<sassyn> did work
<sassyn> but I needed to have some extra pkg as well
<cjwatson> you can probably get away with 7 without too much trouble, yes.  what are the other packages involved?
<cjwatson> (7> in this specific case, I mean, since there are no library packages here)
<sassyn>  DIST=precise ARCH=i386 pbuilder  build ulogd2_2.0.3-1ubuntu1.dsc
<sassyn>  running this
<sassyn> give me
<sassyn> dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
<sassyn> what does it mean?
<cjwatson> looks to me like the genuine missing build-deps here are dh-autoreconf, libnfnetlink-dev (lucid has 1.0.0-1 but you need >= 1.0.1), libmnl-dev, libnetfilter-acct-dev, libnetfilter-conntrack-dev (lucid has 0.0.101-1 but you need >= 1.0.2), libdbi-dev, and dh-systemd
<cjwatson> oh, you said precise, not lucid
<sassyn> my mistake
<cjwatson> why is debhelper (>= 9) a problem then?  precise has debhelper 9.20120115ubuntu3
<sassyn> i meat precise
<cjwatson> and in that case all my comments about multiarch above are irrelevant
<cjwatson> so you're just missing libnfnetlink-dev (>= 1.0.1), libnetfilter-acct-dev, libnetfilter-conntrack-dev (>= 1.0.2), and dh-systemd
<cjwatson> dh-systemd is easy - just drop that from Build-Depends and change "dh $@ --with autoreconf,systemd" in debian/rules to "dh $@ --with autoreconf"
<sassyn> OK
<sassyn> and them what? I will be still missing the libnfnetlink-dev (>= 1.0.1), libnetfilter-acct-dev, libnetfilter-conntrack-dev (>= 1.0.2)
<sassyn> so then I will need to make the same for libnfnetlink-dev etc...
<cjwatson> The build-essential:native thing above is spurious.  Either pbuilder is entirely broken for building on precise, or it's just giving you unhelpful output
<sassyn> once I will have them all
<cjwatson> I don't use pbuilder (I much prefer sbuild), so I can't help with that
<cjwatson> Right, you'll need to backport all of libnfnetlink, libnetfilter-acct, and libnetfilter-conntrack; those build-deps seem to be real
<cjwatson> libnfnetlink should be trivial
<cjwatson> Indeed so should libnetfilter-acct and libnetfilter-conntrack; all their build-deps are already satisfied
<sassyn> so once I do that, I should link my  build machine to the local repo which have libnfnetlink-dev etc.. build
<cjwatson> Right
<sassyn> so then go and try to build ulogd2
<cjwatson> Or just upload these to a PPA if you're having trouble with pbuilder
<sassyn> PPA is also new to me
<sassyn> never used it
<sassyn> will it be easy?
<cjwatson> It's pretty straightforward
<cjwatson> Start by creating a PPA for this at https://launchpad.net/~
<sassyn> so I just upload my pkg to ppa, say the libnfnetlink-dev and the ppa will "know" to link to my ppa local repo auto?
<sassyn> then go head and do the same for all the rest?
<sassyn> until ending with ulog2?
<cjwatson> Then you can do the first step with "backportpackage -u ppa:YOURLAUNCHPADUSERNAME/NAME-OF-PPA -s saucy -d precise libnfnetlink"
<cjwatson> I don't know what you mean by linking to your ppa local repo
<cjwatson> The PPA will build against the Ubuntu primary archive for the series in question (precise in this case) plus itself
<cjwatson> (Unless configured otherwise, which is possible, but you shouldn't need to here)
<sassyn> HOOO ok
<sassyn> so I just need to do it in the right order
<sassyn> running libnfnetlink before ulogd2
<cjwatson> Right, and you'll need to construct a manual source upload for ulogd2 itself because you'll need to remove the dh-systemd build-dep
<cjwatson> https://help.launchpad.net/Packaging/PPA
<cjwatson> It's certainly possible to do all this locally too, it's just more effort
<sassyn> cjwatson, u are great ! thank u !
<sassyn> cjwatson, one more thing, if the libnfnetlink will require to have some pkg as well which only exitis in  saucy
<sassyn> and I faillet's call it pkg M
<sassyn> and build package M is a problem cause I will get to endless loop of other dep
<sassyn> the way I overcome this was just download the *.deb file and install it on my local machine via dpkf -i m.deb
<sassyn> how can I over come this in ppa?
<cjwatson> sassyn: well, I already checked and that isn't the case for any of these
<cjwatson> sassyn: you can't; you have to figure out how to build it
<cjwatson> sassyn: it wouldn't actually be an endless loop anyway.  just requires creativity to figure out where to simplify things
<sassyn> cjwatson, here what I did create a based image for precise using pbuilder. download the  init-system-helpers_1.7 pkg and build it using pbuilder . this one works. now I enable a local repo so the base image will have the  init-system-helpers_1.7 pkg using apt-get. now if I will run the build for ulog2 this is what I'm getting dh clean --with autoreconf,systemd
<sassyn> dh: unable to load addon systemd: Can't locate Debian/Debhelper/Sequence/systemd.pm
<cjwatson> 11:11 <cjwatson> dh-systemd is easy - just drop that from Build-Depends and change "dh $@ --with autoreconf,systemd" in debian/rules to "dh $@ --with autoreconf"
<cjwatson> You were mistaken in attempting to resolve this by building init-system-helpers
<sassyn> understand this, but why the base image didn't install this pkg which is avlibaile
<cjwatson> Maybe it did but your backport was broken in some way
<cjwatson> I don't think it's necessarily interesting to debug that since it isn't the right approach for backporting to precise anyway, IMO
<sassyn> so what will be the right way?
<pitti> sassyn: cjwatson told you twice now, see message from 5 mins ago
<tseliot> pitti: is there documentation (or are there examples) on how to make sure that apport collects a set of files when filing a bug report against a specific package?
<pitti> tseliot: both :) /usr/share/doc/apport/package-hooks.txt.gz is the documentation, and there are plenty of existing hooks in /usr/share/apport/package-hooks/ which do that
<tseliot> pitti: great, thanks!
<tvoss> davmor2, hey there
<davmor2> tvoss|lunch: hello
<pitti> tvoss|lunch: thanks, fixed the typo
<tvoss|lunch> pitti, approved https://code.launchpad.net/~pitti/platform-api/crash-without-hw/+merge/204838
<pitti> tvoss|lunch: cheers!
<pitti> didrocks, sil2100 ^ what's the method du jour to land that now? still add to the spreadsheet?
<sil2100> pitti: hah, yes, but a different one
<sil2100> pitti: there's that CITrain spreadsheet where you should add landings - but I think you'll be trained on that next week ;)
<pitti> sil2100: there's a fix for qtubuntu-sensors on top of that, but I guess I'll ask for that separately as in that branch I'd like to bump the dep to platform-api to the one I want to land now
<sil2100> pitti: for now just poke sergiusens, he can fill in landings for that
<pitti> sil2100: ok; would you mind adding https://code.launchpad.net/~pitti/platform-api/crash-without-hw/+merge/204838 there? it's a self-contained bug fix, no other dependencies
<pitti> sil2100: thanks
<pitti> sergiusens: can you please add https://code.launchpad.net/~pitti/platform-api/crash-without-hw/+merge/204838 there? it's a self-contained bug fix, no other dependencies
<sergiusens> pitti, ack
<pitti> sergiusens: "there" -> to the landing sheet
<pitti> sergiusens: thanks
<pitti> sergiusens: shoudl I top-approve that MP, or will you?
<sergiusens> pitti, either is fine; you can do it now if you want; it won't get merged until it's in the archive
<pitti> sergiusens: ack; done so that it falls off the review queue
<pitti> sergiusens: and FTR, I tested it on mako and x86
<sergiusens> pitti, sounds good
<pete-woods> Trevinho: I'm really struggling to replicate this HUD bug
<pete-woods> I've tried sublimetext 2 and 3
<pete-woods> and opened .pl files in-case that perl action was significnt
<pete-woods> Trevinho: are there plug-ins for the program? or some options you can turn on that enable more menus?
<tvoss> sil2100, hey there
<mpt> bdmurray, ev: Does this look good to you? https://launchpadlibrarian.net/165304593/Series%20colors.png
<NikTh> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1277502
<ubottu> Launchpad bug 1277502 in firefox (Ubuntu) "Firefox package is not updated for Trusty-updates repository" [Undecided,Confirmed]
<NikTh> Is this bug accurate ? And why something like this could be happened ?
<Trevinho> pete-woods: oh, sorry missed your mentions...
<pete-woods> Trevinho: no worrie
<pete-woods> s
<Trevinho> pete-woods: no sure, I'm just using sublime-text2 with some plugins...
<Trevinho> but no one should be much relevant afaik
<pete-woods> Trevinho: I'm desperate, though!
<Trevinho> pete-woods: have you seen my bt? Is helpful in someway or do you need dbus monitoring stuffo or what?
<pete-woods> Trevinho: it's helpful, but I really need to see what causes it
<pete-woods> Trevinho: what's weird is that the stack would be stuck there, I mean, on that line it's just accessing a Qt property (i.e. get a QVariant)
<pete-woods> there shouldn't be anything that could block
<Trevinho> pete-woods: might be that it iterates over bad designed list of children/parents?
<rbasak> NikTh: I don't think the reporter of that bug understands Ubuntu development process. AFAICS, there is no bug. See http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and https://wiki.ubuntu.com/ProposedMigration.
<pete-woods> Trevinho: it has to be something along those lines
<pete-woods> but still, why would it stop on the get variant call?
<davmor2> tvoss: Hey dude so I managed to find the debs for that merge, I currently have 8 apps open on mako, all the apps are drawing correctly on dash and are all switching nicely and there is little slow down on the phone.  I'll open a few more and see if I can kill it
<pete-woods> Trevinho: like here: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.14.04/view/head:/libqtgmenu/internal/QtGMenuModel.cpp#L428
<pete-woods> could there be something massive in the variant someone?
<Trevinho> pete-woods: mh, I didn't check the actual code much (yet), I only saw it was iterating over actions... So I thought it might not handle the loop as it should
<davmor2> tvoss: drawing the thumbnails is slow is that only thing I've noticed so far
<pete-woods> *somehow
<tvoss> davmor2, thanks for looking into it
<davmor2> ogra_: how many apps could you install on mako before it started to die?
<ogra_> install ?
<davmor2> ogra_: sorry run rather than install
<ogra_> i never managed to hit the edge
<ogra_> davmor2, 6-7
<davmor2> ogra_, tvoss: I'm getting close to 20 and the system is still pretty snappy although it is slowing slightly
<ogra_> yay
<ogra_> so that part imroved
<ogra_> davmor2, could you rm /SWAP.swp, reboot and try again ?
<Trevinho> pete-woods: no idea... Mh... The only thing might happen is that basically a children is actually also a parent of a child... and so we get an infinite loop
<pete-woods> Trevinho: yes, that is possible I think, and should be accounted for, but surely that would lead to a huge stack?
<pete-woods> given we're using recursion
<Trevinho> yeah, that's true
<NikTh> rbasak: Thanks for clarifying this.
<mdeslaur> is there a retracer running for trusty bugs?
<mdeslaur> looks like it's not being run
<mdeslaur> bdmurray: any idea who I would ping about the trusty retracer?
<davmor2> ogra_, tvoss: right with 21 apps open including webapps and the camera, 3 apps in the dash layout look blank but they open fine and can be switched to with no issues. memory wise on the dash I'm at 1070 of 1871 swp is 0 I will however now rm /SWAP.swp and try that too
<tvoss> davmor2, thanks, can you take a sample of the shells memory usage?
<doko> Sweet5hark, we now require symbols files for main inclusion
<davmor2> tvoss: sorry do you mean with all that apps closed as a comparison?  If so I'll remove swap and reboot and it will be nice and clean :)
<tvoss> davmor2, nope, right now when the previews go blank
<davmor2> ogra_: rm cannot remove "/SWAP.swp"  no such file
<davmor2> tvoss: so under htop unity8 is showing at 0.7% cpu and 22.7% mem
<davmor2> tvoss: there is however several listings of unity8
<tvoss> davmor2, those are threads, try to switch to tree view in htop
<davmor2> tvoss: yeap all good so the figures stand :)  0.7 and 22.7
<tvoss> davmor2, ack and thx
<bdmurray> mpt: looks good to me, if you submit an mp I'll merge it later today
<bdmurray> mdeslaur: for the launchpad one pitti or seb128
<davmor2> tvoss: interestingly it seems to be the position rather than the apps that is blank 3 row 1 column and 4 row 1&2 column  all the rest appear correct but if I click on one of the blank app it goes to row 1 column1 and is visible and the one that is push to 3:1 is no blank
<mdeslaur> bdmurray: thanks!
<mdeslaur> seb128: any idea why the trusty retracer isn't running?
<bdmurray> mpt: ah, I see your mp now.  so I'll merge that and the milestones one
<seb128> mdeslaur, let me check
<ogra_> davmor2, hmm, try /userdata/SWAP.*
<davmor2> tvoss: http://ubuntuone.com/7my6xiriTiIEQBPxNw9O6D
<davmor2> tvoss: it's only ever those 3 that are empty
<davmor2> ogra_: rm: cannot remove '/userdata/SWAP.img': Operation not permitted
<ogra_> davmor2, hmm, you might need to swapoff
<davmor2> ogra_: that did it
<tvoss> pitti, hey there
<pitti> hello tvoss
<mpt> thanks bdmurray
<davmor2> ogra_: right htop now says swap 0/0MB  and now you want me to open apps galore again yes?
<ogra_> yeah
<ogra_> lets see how far you get
<davmor2> ogra_: on it
<davmor2> ogra_: I'm going to run out of installed apps
<ogra_> lol
<ogra_> how many do you have open
<davmor2> ogra_: let me finisgh the installed apps and I'll tell you
<davmor2> ogra_: 30 open apps, htop says 1181/1871MB on the memory line
<ogra_> oh, well, that means it would get tricky to open some mem consuming stuff indie an app i guess
<ogra_> *inside
<pitti> mdeslaur: should be running just fine
<pitti> seb128: ^
<ogra_> try playing some music now and see if the apps still persist if you flick through them
<davmor2> ogra_: and other than the draw on the thumbnails the phone is still pretty snappy :)
<ogra_> (this looks like quite a hardcode stresstest :) )
<davmor2> ogra_: just taken a bunch of photos and the memory usage has gone down, switch to dropping letters and it's lower still
<ogra_> great
<ogra_> well, Mir must have killed one or more apps that are bakgrounded
<seb128> pitti, what in the backlog?
<ogra_> you should see one that takes a bit longer to show up when you flick through
<davmor2> ogra_: I'm assuming the extra is just holding memory for the images on that dash as it redraws each time I leave and app
<sarnold> pitti: see e.g. https://bugs.launchpad.net/ubuntu/+source/vidalia/+bug/1276921 or https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1277197
<davmor2> tvoss: ^
<ubottu> Error: malone bug 1276921 not found
<ubottu> Error: malone bug 1277197 not found
<seb128> pitti, oh, trusty retracers
<seb128> pitti, did you restart them?
<seb128> or are they running?
<pitti> seb128: no, they didn't crash in the first place
<seb128> k
<seb128> mdeslaur, do you have a bug number example?
<seb128> oh what sarnold just said I guess
<pitti> these two aren't in the logs
<ogra_> davmor2, no, unity/Mir are supposed to keep the apps there but in SIGSTOP state ... if the memory pressure gets to high it starts killing them (but will start them afresh if you flick to a killed app)
<seb128> I don't have access to those
<davmor2> ogra_: with dropping letters open I'm down to 1083/1871MB
<mdeslaur> seb128: yeah, hold on there are a couple of public ones
<mdeslaur> seb128: 1275679
<ogra_> davmor2, you should actually see one or more apps take a bit longer to show the UI (because they need to start from scratch)
<davmor2> ogra_: seems to be working then :)
<pitti> ERROR: connecting to Launchpad failed: unclosed token: line 20413, column 14
<ogra_> what is important is that they still start fine ... and that the thumbnails stay around (and that the labels are correct fr the matching thumbnails)
<pitti> mdeslaur, seb128 ^ ah, that's it
<pitti> launchpadlib or LP itself going nuts
<mdeslaur> pitti: whoops :)
<ogra_> davmor2, if thats given i think we can call this test successfull
<ogra_> :)
 * pitti deletes the lplib cache
<pitti> 87G.launchpadlib/api.launchpad.net/cache/
<pitti> ouch! I guess launchpadlib doesn't have any cleanup code
<mdeslaur> ouch!
<davmor2> ogra_: so the blank ones are the shutdown apps by the look of it.  And they take an extra second to open back up when you swipe through the apps from the right
<ogra_> yeah
<ogra_> that should be fixed if click gets faster
<cjwatson> when
<cjwatson> :-)
<ogra_> :)
<ogra_> davmor2, in any case thats an awesome result !!!!
<ogra_> and way better than what i saw last time when trying the same
<cjwatson> but I have an n-way hydra madness customer bug to fix before I get back to that, and you probably want me to make some progress on the livefs/LP bug too
<cjwatson> s/bug too/support too/
<davmor2> cjwatson: and his leprechaun pot of optimism ;)
<cjwatson> (when did you last see a six-foot-tall leprechaun?)
<davmor2> tvoss: did you want me to comment on the merge?
<davmor2> cjwatson: I didn't say you were, I said you had a leprechaun pot of optimism.  Gold didn't sound right for this instance :)
<davmor2> cjwatson: also last Saint Patricks day all over the Country :D
<cjwatson> davmor2: *shudder*
<rharper> hallyn: it's been a few weeks, but I finally have an update to test-qemu.py that passes all 22 tests on: precise, quantal, raring, saucy and trusty,   there is a decent amount of churn in the script since a lot of failures were false positives with the test framework (ssh timeouts into the guest, guest image corruption, etc.)
<rharper> hallyn: lp:~raharper/qa-regression-testing/scripts-test-qemu-fixups-v2
<rharper> in some cases we still see random failure in the nic test, or one of the hotplug tests; but running them manually, or isolated, it passes just fine.  This is related to the harness, IMO, tcg on older releases likely has some issues that newer qemus have resolved, I've not seen any variance in the trusty qemu for these tests over the past month of hacking on this script
<pitti> seb128, mdeslaur: it's catching up now
<mdeslaur> thanks pitti!
<sarnold> thanks pitti
<davmor2> cjwatson: shhhh it might ruin the illusion but I think they might of been beer drinking 6ft leprechauns :)
<tvoss> davmor2, your manual testing feedback would be helpful
<davmor2> tvoss: no worries
<seb128> pitti, thanks
<davmor2> tvoss: Done
<tvoss> davidcalle, thanks
<infinity> jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1277594
<ubottu> Launchpad bug 1277594 in upstart (Ubuntu) "Please make --no-sessions the default, and add a cmdline option for the inverse" [Undecided,New]
<jodh> infinity: thanks
<infinity> jodh: I imagine, other than the "document the new option" bit, it's a 2-line patch or so. :)
<infinity> Well, and the bikeshedding over what to call the new option.  Maybe just "--sessions"?
<infinity> As that's the logical inverse of --no-sessions
<jodh> infinity: except that we also have --session just to be confusing :)
<infinity> jodh: Hah.
<infinity> jodh: I do question the choice to not prefix all of those options with --upstart or --init, too.  Extra confusing to me to sort out why bits of my kernel cmdline aren't for my kernel or initrd.
<infinity> jodh: But way too late to go back and bikeshed that one. :P
<xnox> infinity: jodh: is that about chroot sessions? i thought the plan to rip that out post trusty.
<xnox> infinity: jodh: flipping the default the other way around also sounds reasonable to me.
<infinity> xnox: I don't care if the code is ripped out, I just want the default changed.  The errors thrown are remarkably surprising to people who don't know what's going on (and annoying to people who do).
<xnox> infinity: so a flag to do inverse naturally should be --no-sessions=false
<infinity> *choke*
<xnox> ;-) and the default is --no-sessions[=true]
<infinity> --maybe-sessions=surpriseme
<infinity> Oh dear, it's annual fire alarm testing day at my apartment building.  I might not be sane by EOD.
<Laney> is Conflicts/Replaces enough to make update-manager happy to remove a package?
<cjwatson> Laney: yes
<Laney> merci
<sassyn> xnox, hi
<cjwatson> doko: do you think you could look at a ruby1.9.1 merge?  you're til; looks like it's needed to stop ruby-defaults breaking the world in -proposed
<cjwatson> (well, the rubyish world)
<doko> cjwatson, ok, not today anymore. will look at it tomorrow
 * cjwatson nods
<cjwatson> thanks
 * infinity blinks at gnome-settings-daemon producing a _all.deb on i386 and _arch.deb on all the others.
<infinity> xnox: What did you DO?
<infinity> Oh, maybe it's the queue that's confused.
<infinity> Very, very confused. :P
<infinity> Or it's me.
<infinity> Nevermind.
<xnox> infinity: i had a sad day with gnome-settings-daemon, getting trolled by germans and french from desktop team did not help with concentration levels.
<xnox> infinity: it should be _fine_ now.
<xnox> infinity: i got the upstart jobs right, just nothing else.
<infinity> xnox: Yeah, it's fine. I was confused by two different versions in the NEW queue.  My poor brain thought it was all the same version and was super confused. :P
<sassyn> cjwatson,
<sassyn> hi again
<sassyn> at the end I manage to make it work
<sassyn> with pbuilder
<sassyn> the only thing I still don't understand is the dep issue.
<sassyn> I will ask again, if I want to build a package name foo that exitst in ubuntu 14.04. So I have build a base image of 10.04 using pbuilder or ppa, and start the build process. The build map the base image, and check for deps.
<sassyn> if all deps are OK, pkg build just fine. If however some dep can't be found (let's called it pkg bar), as it include only in version 14.04 - I need to download it as well, and build it under the base image.
<sassyn> if bar also requires other dep I do the same until the end of the loop.
<sassyn> I might need to build the entire system, which will be easyier to upgrade to 14.04, but let say once I download bar I'm OK.
<sassyn> so bar was build, and I put it in a local repo, where the base image of 10.04 is sync to , and now starting to build the foo pkg. and foo now was created succesffuly
<sassyn> I needed to play a little with the control and compat file since I'm using debhelp 7 and not 9 .
<sassyn> If I try to update debhelp, I ended up with bascily upgrading a lot of pkg. So i just use 7 under the contol file to make it easier.
<sassyn> and walla, I have the pkgs up in place.
<sassyn> my question if this process it the way to go, or if there is onther magic way which be simpler.
<sassyn> I was thinking that the dep process can be auto without me need to get involve
<sassyn> at least that I was thinkg the backport command is doing
<sassyn> so I will be thankfull if someone can drop me a comment here
<sassyn> thank u
<tarpman> sassyn: AFAICT you're doing it right, backportpackage only automates no-change backports, packaging changes (e.g. debhelper compat, dependency versions) have to be done manually
<tarpman> sassyn: although FWIW I have seen a couple of PPAs where dh 9 was backported to lucid... can't remember where
<hallyn> jibel: hi, I'm trying out https://wiki.ubuntu.com/QATeam/UpgradeTestingSetup on trusty, but bin/auto-upgrade-tester is python3, and python3 doesn't seem to have a distro_info package
<bdmurray> pitti: why does apport retrace sometimes fail with "E: Ignore unavailable version '0.9.8.0-1ubuntu5' of package 'network-manager-applet'"?  The version of the package does exist its just in the release pocket and not -updates.
<bdmurray> pitti: I mention -updates because that is enabled in the retracer sources.list file
<sassyn> tarpman, thank u
<Chipaca> hey all. Is there an easy way to tell dh to skip installing a file? the build builds it, but i don't want to ship it in the binary package
<Chipaca> wait. why am i specifying --fail-missing
 * Chipaca deskfaces
<Noskcaj> Can someone please test build openimageio on ppc from debian? If it builds we can sync
<psusi> so dpkg says no package owns /etc/fstab... so where does it come from?
<xnox> psusi: installer generates it.
<xnox> psusi: it's a config file, not a conffile.
<psusi> weird...
<xnox> psusi: /lib/init/fstab is owned by mountall and defines default things.
<xnox> psusi: and i majority of cases one doesn't need an fstab at all.
<psusi> xnox: sure, but one is provided and has some comments in it.. I'm looking at an old bug report that the comments are wrong and need updated... so I was wondering where the heck the file actually comes from
<tedg> xnox, So it's appearing that if an Upstart job's execution is short enough it doesn't ever emit a "started" event.  Is that expected?
<tedg> Looks like it never hits "running" â starting â security â pre-start â spawned â post-start â stopping â killed â post-stop â waiting
<infinity> Noskcaj: I'll give it a shot.
<infinity> Noskcaj: Also, that new cogl upstream you pointed me at looks like it was generated with a broken libtool.  Would be nice to hunt down where that came from and make sure that distro isn't still shipping such breakage.
<Noskcaj> infinity, thanks.
<infinity> Noskcaj: Unsurprisingly, the new openimageio still has the same issue.  I'll re-merge.
<Noskcaj> ok, thanks
<xnox> tedg: do you have a reproducible test case we can add to the test-suite?
<tedg> xnox, Working on it.  It seems to be whether the post-start job takes longer than the main job.
<tedg> Trying to verify that.
<xnox> tedg: spawned -> stopping is plausible, but then post-start shouldn't be reached. Not so long ago, we did change some state transitions around there.
<tedg> xnox, Here's what I'm getting, no running.  starting â security â pre-start â spawned â post-start â stopping â killed â post-stop â waiting
<xnox> tedg: oh and i don't think we emit started, if the goal is changed to stopping mid-way.
<xnox> (or e.g. stop on condition gets satisfied)
<tedg> Hmm, that's what I'm seeing.  Do you think that's on purpose or a bug?
<tedg> Really it did start, and run, it seems like started should have been emitted.
<xnox> tedg: i need to see a test-case and/or code logs where you see above.
<xnox> tedg: you are experiencing it, so pass on the know-how ;-)
<xnox> (preferably in a bug report, just finished watching Sochi)
<tedg> Yeah, okay.  I think I've got enough for a bug report now.
<tedg> Ah, don't tell me.  We're not allowed to know here yet until Prime Time.
<tedg> I'm curious if they could, perhaps, have fireworks.
<tedg> :-)
<xnox> tedg: i didn't get to see all of it, but it is indeed marvelous.
<tedg> xnox, Okay, logged bug 1277737
<ubottu> bug 1277737 in upstart "If the post-start job takes longer than the primary job no "started" event is emitted" [Undecided,New] https://launchpad.net/bugs/1277737
<xnox> tedg: why manual?
<tedg> Oh, I usually do that for test jobs... just in case :-)
<tedg> Works the same without.
<xnox> tedg: that's normal.
<xnox> tedg: if you really wish for started event to be emitted, it should be declared as a "task"
<xnox> tedg: since main process died, before post-start was complete. And "started" is only emitted if post-start is complete and the main process is still alive.
<tedg> xnox, Adding a "task" has the same behavior
<tedg> I guess perhaps I should be using "spawned"
<xnox> tedg: yeah, that's odd. Probably  a bug in a state transition.
<tedg> I don't really care about the pre-start script
<xnox> tedg: you shouldn't be using spawned... as that's racy =/
<tedg> xnox, racy for what?  I just want to know when there's a PID.
<xnox> tedg: the whole job is superflicious.
<xnox> tedg: it should be just a single script "script sleep 5; sleep 10; end script"
<xnox> tedg: do you have a real example where you are doing this? there is a lot of things that one can cruft, which make no sense.
<tedg> Sure, it's a demo.
<xnox> tedg: what's the real-world usecase ?
<tedg> The case I'm seeing it is in the security confinement tests.
<tedg> They test to ensure that the started applications are confined.  But they do so rather quicly.
<xnox> tedg: i agree it's a bug, but if it's not a realistic configuration / bad job file we at times don't support this.
<tedg> So they're failing.
<xnox> tedg: can you point me to them?
<tedg> xnox, https://wiki.ubuntu.com/Touch/Testing#Running_Security_tests
<xnox> tedg: it sounds like racy test-suites. You should be leaving the main process for long enough to inspect it =)
<tedg> It inspects the output as the task writes a file.
<tedg> The problem is that the application launching code is waiting until the task is started.
<xnox> tedg: one shouldn't do that, as that can be cached and not flushed....
<xnox> tedg: one should watch for _both_ started and killed. Cause a buggy app can crash on startup, and thus started will not be emitted if it fails to spawn.
<tedg> You're welcome to patch the test suite, but I want to solve this race so my code can land first :-)
<tedg> We are watching started and killed.
<tedg> The problem is that it's stopping without error.
<tedg> So we're not flagging that.
<xnox> tedg: your code land first => well let me invoke bus factor =)...........  I'm way past my EOW =))))) i'm up for trolling on irc, but i'm not up for writting code ;-)
<tedg> Heh
<xnox> tedg: i got over-trolled by desktop team today in the office, i want to pay it forward ;-)
<tedg> xnox, Teach you to go into the office ;-)
<tedg> Okay, need to do dinner.  I'll have to fix this later.
<tedg> xnox, Thanks for the pointers!
#ubuntu-devel 2014-02-08
<Fudge> hi anyone familiar with precise/ubiquity bugs unable to configure apt from cd. like bug 1041140 or screen grab http://thefudge.net/images/vinux4-daily-2014.png
<ubottu> bug 1041140 in ubiquity (Ubuntu) "Unable to install a fresh Ubuntu 12.04.1 from a live usb - /usr/share/ubiquity/plugininstall.py", line 1728, in <module>" [Undecided,Confirmed] https://launchpad.net/bugs/1041140
<shookees> Hy, anyone knows a decent documentation for libindicate?
<dxntj> hello
<Nafallo> cjwatson: ah, I guess that's what happening except the job is heavy enough on a netbook to seem constant :-P
<eduard> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<eduard> bug #1262238 fglrx does no longer support "Mobility Radeon HD 4225/4250"
<ubottu> bug 1262238 in fglrx-installer-updates (Ubuntu Precise) "[SRU] Add support for the lts-saucy stack" [Medium,Fix released] https://launchpad.net/bugs/1262238
<infinity> eduard: With binary-only drivers, we're somewhat at the mercy of what upstream ships.  This has always been the unfortunate tradeoff we've accepted for updating them to support new hardware. :(
<eduard> ok, I see
<eduard> It is just that this exception is not mentioned on the "SRU" page
<infinity> eduard: Alberto's comment on the end of the bug might at least be helpful.
<eduard> and I "lost" my laptop during a normal update
<infinity> eduard: It's not so much an exception as a sad reality.  For binary-only non-free stuff, we don't have much choice.  Shipping upstream's latest is the only way to get security fixes and hardware support, but they drop old hardware support willy-nilly. :/
<infinity> But perhaps Alberto could package up the legacy driver for precise to try to mitigate this for people on the 3.2 kernel.
<eduard> thanks for your efforts describing how I can recover
<eduard> I already know to do that on my own
<eduard> it is just that I'm hesitant to alter my installation too much
<eduard> away from the official 12.04 LTS
<eduard> since this is a "production" workstation
<eduard> I would appreciate if the legacy driver could make it into the 12.04 LTS
<psusi> so it sounds like eglibc upstream is dead... will we be switching back to glibc?
<infinity> psusi: Yes.
<infinity> psusi: I'm probably not doing it for 2.19, cause I'm on some tight deadlines for trusty, but it'll obviously happen for 2.20, because we have no choice.
<infinity> (Will be looking this weekend at doing it for 2.19, though... It might not be too painful to JFDI)
<Noskcaj> mira, scim, and smc should be syncable, i just lack the hardware to test build
<Logan_> Noskcaj: PPA
<Noskcaj> oh yeah. I think smc is too big for me to even upload though
<Logan_> I'll test build mira
<Noskcaj> thanks
<Logan_> Noskcaj: building
<Noskcaj> turns out scim has a sync bug already
<Logan_> Noskcaj: mira built fine
<Logan_> want me to sponsor a sync?
<Noskcaj> Just sync it yourself, it's not lack of sponsorship that's making me not be motu
<Logan_> then what is it?
<Noskcaj> The application system
<Logan_> I don't understand why they haven't initiated a vote yet
<Noskcaj> neither
<Logan_> maybe bump the thread?
<Noskcaj> done, many, many times
<Noskcaj> apparently someone has been on the email application longer than i and they aren't finished either
<Noskcaj> And ubuntu-gnome took up the whole irc meeting
<Logan_> Noskcaj: you owe me one :P
<Noskcaj> :)
<Logan_> I bumped the thread
<Logan_> and added my endorsement
<Noskcaj> thanks
 * Noskcaj wonders if there's a DMB member he hasn't pinged
<Logan_> synced mira
<Noskcaj> ty
<Logan_> heh, Laney just bumped another thread
<Laney> oh
<Laney> micahg said he would call for votes this weekend
<Logan_> for Noskcaj?
<Laney> yes
<Logan_> sweet
<Noskcaj> yay, thanks micahg.
<Logan_> the e-mail application system is very much broken :(
<Laney> it was never intended to be used so much
<Noskcaj> Just a suggestion, longer and better timed IRC meetings would reduce the amount of email use
<Noskcaj> I can only apply by irc in summer (daylight saving time), if i wake up at 6am
<Noskcaj> and darkxst  took the entire meeting time for this month, when three people were applying
<Noskcaj> woops, sorry for ping
<darkxst> Noskcaj, well you did get to the meeting very late!
<Noskcaj> darkxst, I know, but you did use up the whole meeting. Not your fault, just the system is semi-broken
<darkxst> Laney, thanks for updating packageset, you missed gnome-weather however
<Laney> no but I did do it slightly later
<darkxst> Laney, ok, thanks
<Laney> no problemo
<darkxst> Laney, codesearch is down again?
#ubuntu-devel 2014-02-09
<Laney> tumbleweed: dmb agenda poke
<TJ-> cjwatson: I'm trying to confirm that bug #1271141 is fixed but don't have easy access to the original system that had Win7 installed; do you know what the minimum requirement is for os-prober to believe it has found a Windows bootable file-system (so I can fake one) ?
<ubottu> bug 1271141 in grub2 (Ubuntu) "30_os-prober fails in make_timeout() when using GRUB_BUTTON_CMOS_ADDRESS" [Medium,Triaged] https://launchpad.net/bugs/1271141
<cjwatson> TJ-: the place to look would be /usr/lib/os-probes/mounted/20microsoft
<TJ-> cjohnston: yeah, been there already. Can't find (so far) where WINOSDATA is defined and a batch of tests seem to depend on it being non-empty
<TJ-> oops
<TJ-> cjwatson:  yeah, been there already. Can't find (so far) where WINOSDATA is defined and a batch of tests seem to depend on it being non-empty
<cjwatson> TJ-: you can just pretend it's always empty; that's a hook for migration-assistant IIRC
<TJ-> cjwatson: Ahhhh.... explains why I couldn't find it in os-prober or grub sources
<cjwatson> Or maybe ubiquity, I'm not sure.  It's not in the current source for anything relevant I can find, so maybe we can drop that patch soon
<cjwatson> Apart from a similar test in ubiquity/compat/os-prober
<cjwatson> Not going to track down the history just now :)
<TJ-> cjwatson: So it looks like it needs "/boot/bcd" with valid Win7 entries
<cjwatson> Sounds plausible
<cjwatson> Plus appropriate filesystem type
<TJ-> cjwatson: that's fine, I think I have enough to fake it now
<cjwatson> ok, cool
<TJ-> cjwatson: fwiw, fake only requires: "mkdir -p /mnt/tmp && mount /dev/sdXY /mnt/tmp && touch /mnt/tmp/bootmgr && mkdir -p /mnt/tmp/boot && echo 'W.i.n.d.o.w.s. .7' >/mnt/tmp/boot/bcd && umount /mnt/tmp"
<TJ-> cjwatson: Do you know of a 'nice' way to co-install grub-pc and grub-efi so that both can be used? The scenario is a USB device being configured to boot on UEFI or BIOS systems, with a GPT
<Noskcaj> Does dh_autoreconf support cmake yet?
<Noskcaj> if so, gccxml will need a rebuild
<juliank> Noskcaj: You can use it with a custom command.
<juliank> There's only magic for autoreconf.
<juliank> As far as I know, cmake generated files are not shipped in a tarball, so there should not be any need.
<infinity> Noskcaj: gccxml needs a *lot* more than autoreconf...
<infinity> Noskcaj: It's a fork of an ancient GCC, so doesn't remotely support any arch added to GCC since that point.
<jtaylor> hm does that matter?
<jtaylor> its only working on the frontend
<jtaylor> its problem is that it doesn't support c++11
<jtaylor> which is a shame as it allows some neat stuff (e.g. the reflexion of root-system)
<xnox> jtaylor: my alternative was to use a fork of gccxml which is just a plugin, rather than embedded copy of gcc.
<jtaylor> xnox: link?
<xnox> jtaylor: https://github.com/alexleach/gccxml_plugin that one works with gcc-4.8
<jtaylor> neat thanks
<xnox> jtaylor: it's highly compatible with old gccxml, but not fully.
<Noskcaj> infinity, oh. /me runs away from that package
<Noskcaj> pitti, PING
#ubuntu-devel 2015-02-02
<tomreyn> hi, i'm trying to understand why there is no libopenal1-dbg in trusty, but can't seem to find any info on it: http://packages.ubuntu.com/search?keywords=libopenal1-dbg
<rbasak> tomreyn: looks like it's built without debug info before the package build stripping gets to it.
<rbasak> Changing -DCMAKE_BUILD_TYPE=Release for -DCMAKE_BUILD_TYPE=RelWithDebInfo might help. I'm not sure though.
<rbasak> "libopenal1 is already stripped, ignoring" is the hint I'm basing my hypothesis on.
<tomreyn> rbasak: where do you see this?
<rbasak> In the build logs.
<rbasak> https://launchpadlibrarian.net/108030443/buildlog_ubuntu-quantal-amd64.openal-soft_1%3A1.14-4ubuntu1_BUILDING.txt.gz
<tomreyn> thanks. i would not have known how to find this (how did you?)
<tomreyn> this says "quantal" though?
<tomreyn> same version as trusty though
<rbasak> Start from https://launchpad.net/ubuntu/trusty/+package/libopenal1
<rbasak> (since that's the information you know - release and binary package name)
<rbasak> Click through to source package: https://launchpad.net/ubuntu/+source/openal-soft/1:1.14-4ubuntu1
<rbasak> You can see the build information there, per architecture.
<rbasak> It was built back during the Quantal development cycle, and the binary got copied forward through to Trusty since it didn't change since then.
<rbasak> If the published version number is identical, the published binary is identical.
<tomreyn> openal-soft (1:1.14-4ubuntu1) quantal; urgency=low
<tomreyn>   * Merge from Debian testing.  Remaining changes:
<tomreyn>     - Add a symbols file for libopenal1
<tomreyn> :)
<tomreyn> thanks for explaining
<rbasak> That's different. A symbols file is to do with the symbols a shared library exports, not debugging information.
<tomreyn> oh .a
<rbasak> It would be reasonable to file a bug in Debian asking to use RelWithDebInfo instead of Release, assuming that fixes it.
<rbasak> (as Debian calls dh_strip later anyway)
<tomreyn> hmm yes looks like wheezy is lacking it, too
<rbasak> Oh - looks like it's been fixed since. You get a -dbg package in Vivid.
<tomreyn> yes later versions have it in either distro
<tomreyn> (earlier, too)
<rbasak> OK - so I think just rebuild locally with RelWithDebInfo and you should get them.
<tomreyn> thanks
<rbasak> No problem.
<tomreyn> rbasak: could you hint me on what's the quickest way to rebuild the package with -DCMAKE_BUILD_TYPE=RelWithDebInfo ? i apt-get source libopenal1, edit CMakeLists and then...?
<rbasak> tomreyn: probably with a PPA is the easiest. apt-get source, edit debian/rules (not CMakeLists), run dch and add a changelog entry, call the version number 1:1.14-4ubuntu1ppa1 or something so a security update will trump it.
<rbasak> Then run dpkg-buildpackage -S -sd -nc. You'll need a gpg key set up.
<tomreyn> rbasak: i'm just interested in trying it once now, it doesn't need to survive
<rbasak> Set up a PPA on Launchpad, then eg. dput ppa:tomreyn on the source changes file.
<rbasak> I suppose you could use apt-get build-dep libopenal1 to install all the build dependencies, then dpkg-buildpackage -us -uc to build locally.
<rbasak> I tend not to install build deps locally for every package but it might make sense for you.
<tomreyn> thanks again. the reason i'm trying to is this crash in supertuxkart: https://tomreyn.megaglest.org/stk_1e0a9022a30393a5af52cf2f5b5d222c6633aebd_quicksands_nitro_finish.txt
<tomreyn> the developers suspect libopenal may not be thread safe
<rbasak> Thank you for looking at it.
<rbasak> Remember that if you rebuild the package you should use your new libopenal1, not the one from the archive, to make sure the debug symbols match up.
<tomreyn> that's a good reminder
<alkisg> Good morning
<darkxst> pitti, systemd init is getting stuck bringing up eth0 here now (its just a dhcp config in /etc/network/interfaces)
<dholbach> good morning
<alkisg> mvo: hi, in LP #1415785 we've included a branch with the proposed patch, we put the appropriate [SRU headers] for the test case, regression potential etc, and assigned it to you. Could you have a look please and tell me if something is amiss, or sponsor it if it's OK? Thanks!
<ubottu> Launchpad bug 1415785 in update-manager (Ubuntu) "Please remove all ltsp* blacklisting" [High,Confirmed] https://launchpad.net/bugs/1415785
<alkisg> It's only needed in 12.04, I think the whole dist-upgrade functionality got removed from update-manager in 14.04+, in any case ltsp isn't mentioned in -trunk at all anymore
<mvo> alkisg: sure! thanks for doing this. so this just needs a sru into 12.04, correct?
<alkisg> Correct
<mvo> cool, I look at it in a bit
<alkisg> Thank you
<pitti> darkxst: stuck? which systemd version is that? can you please boot with debug shell (see /usr/share/doc/systemd/README.Debian) and see "systemctl jobs", and get me systemctl status -l <job> for the hanging ones?
<darkxst> pitti, 218-6ubuntu1
<darkxst> pitti, it just sits waiting for network, I'll reboot now
<pitti> yay, there's a new version of patch which should fix the symlink mess (php, glibc, etc.)
<pitti> rbasak, infinity ^ FYI; I'll retry the slew of failues
<darkxst> pitti, http://pastebin.com/FPgYidgt
<darkxst> though the message is something like 'a job is waiting on startup of ifup on eth0'
<pitti> darkxst: oh, is "systemctl reload smbd.service" hanging?
<LocutusOfBorg1> hi developers!
<pitti> rbasak: ok, the remaining regression is https://jenkins.qa.ubuntu.com/job/vivid-adt-php-horde-serialize/lastBuild/? which is real; the rest succeeds now
<darkxst> pitti, maybe, and seems racy when I boot with systemd.debug-shell
<pitti> darkxst: you mean it sometimes succeeds, sometimes not?
<darkxst> yes it succeeds with that, but not without
<pitti> darkxst: do you have some actual smbd config, or is that just installed with the defaults?
<pitti> darkxst: oh, go heisenbug.. so in the pastebin you showed me it did not actually hang?
<darkxst> pitti, it hung that time
<darkxst> took a few boots to get it too hang tho
<darkxst> smbd == samba? I do have some samba shares setup,
<pitti> darkxst: ok, then I suspect some kind of dependency loop; would you mind filing a bug with the pastebin?
<pitti> darkxst: I'll try to reproduce this in a bit; I don't know anything about samba, but perhaps it already reproduces with the default config
<darkxst> pitti, ok will do
<darkxst> I don't have anything special in my config, just a couple of shares defined
<pitti> darkxst: ah, I think I understand why
 * darkxst now hitting races in upstart boot ;(
<darkxst> (completely unrelated of course)
<pitti> so smbd hooks into DHCP hooks which reload samba which triggers /etc/init.d/smbd reload, which Requires: $network
<pitti> but $network is precisely the thing that ifup@.service is trying to bring up..
<darkxst> pitti, makes sense
<darkxst_> pitti, bug 1417010
<ubottu> bug 1417010 in systemd (Ubuntu) "systemd init gets stuck reloading smbd.service" [Undecided,New] https://launchpad.net/bugs/1417010
<pitti> darkxst_: thanks
<pitti> darkxst_: just to ensure, the boot should continue and finish after 2 mins of waiting, right?
<darkxst_> pitti, no, I left if for 20mins early today
<pitti> uh, that's a surprise
<darkxst_> in face the message says "nolimit" or something
<pitti> darkxst_: network-online comes up after 2 minutes, this should satisfy the smbd reload
<pitti> darkxst_: could you give me the systemctl list-jobs after 2 minutes?
<darkxst_> I think that pastebin would have been atleast after 2 minutes
<pitti> darkxst: ah, ok; thanks either way, I'll ponder this
<darkxst> pitti, I've not hit in any of my VM's but they don't have samba installed
<pitti> darkxst: yeah, it doesn't reproduce for me either, but I didn't really configure it
<cjwatson_> Noskcaj: unlikely; somebody who's interested should go for it
<ogra_> pitti, do you think we could get this easily SRUed into utopic ? https://launchpad.net/ubuntu/+source/libmtp/1.1.8-1ubuntu2 (just adds HW support)
<darkxst> pitti, I will try and reproduce in a VM tomorrow
<Noskcaj> cjwatson_, I'll see if i can work a merge sometime this week then
<cjwatson_> ok
<pitti> ogra_: sure, that looks totally harmless
<ogra_> yup it is ... and i dont want to have to set up a PPA for it
<LocutusOfBorg1> hi developers, do you know why sqlmap is on debian unstable but not on vivid, neither in the new queue? Am I missing something=?
<cjwatson> LocutusOfBorg1: because it was previously deleted and such things require manual action; I'll bring it back
<cjwatson> (logged in http://people.canonical.com/~ubuntu-archive/auto-sync/current.log)
<LocutusOfBorg1> thanks as usual cjwatson this is why I asked, because I was wondering about that manual hint ;)
<rbasak> pitti: thanks. Looking.
<sitter> TheMuso, didrocks: is it intentional that the pulseaudio from here has the flat-volume disabling disabled? https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions/+packages
<didrocks> sitter: I'll let TheMuso answer, I have no clue about the changes besides bluetooth
<sitter> I best leave this here for reference as well http://paste.ubuntu.com/10013864/ ^^
<rbasak> pitti: I can't reproduce the php-horde-serialize failure locally (in adt-virt-lxc). What locale does the environment use, please? I tried C.UTF-8, still passing locally.
<pitti> rbasak: trying to run here
<rbasak> Thanks. I've since tried C as well. Also I realised I was rebuilding locally, but using -B doesn't help (still passes).
<pitti> rbasak: C.UTF-8 is the default locale indeed
<rbasak> There is https://bugs.launchpad.net/ubuntu/+source/php-json/+bug/1287726 which may be related. Also I see a new upstream release that changes some of the handling around the failure case, but of course that passes for me locally too so I can't tell if it fixes anything we need.
<ubottu> Launchpad bug 1287726 in php-json (Ubuntu) "Wrong evaluation whether json is valid or not" [Medium,Triaged]
<pitti> rbasak: I get the exact same failure in schroot
<pitti> adt-run --apt-pocket=proposed -U php-horde-serialize --- schroot vivid
<pitti> qemu is still running
 * pitti runs in lxc too, for fun
<pitti> rbasak: qemu failed too (adt-run --apt-pocket=proposed -U php-horde-serialize --- qemu /srv/vm/adt-vivid-amd64-cloud.img)
<pitti> rbasak: ah, lxc doesn't currently work for me :/
<rbasak> I've not been using --apt-pocket=proposed either. Seems obvious to me.
<pitti> rbasak: ^ I can't interpret this -- don't you want to test with the php5 in -proposed?
<rbasak> Thanks - I'll use adt-virt-schroot. I didn't know thta existed!
<pitti> that's what triggers the regression, no?
<rbasak> pitti: sorry. I mean that I failed to use --apt-pocket=proposed, when obviously I should be doing so.
<pitti> ah :)
<rbasak> I've got away with never using that option ever and not really knowing about it somehow.
<rbasak> I shall amend my ways :)
<pitti> rbasak: ah, lxc finished too, same failure; doesn't look sensitive to the build env
<rbasak> adt-run --apt-pocket=proposed -B php-horde-serialize_2.0.2-5.dsc --- adt-virt-lxc -es vivid
<rbasak> This passes for me :-/
<pitti> rbasak: I suppose you could also give it some locally built 5.6 php debs to run with; if you them, that's faster than --apt-pocket + -U
<pitti> rbasak: ah, you need -U (aka --apt-upgrade)
<pitti> rbasak: apt-pocket merely fiddles with the apt sources; I figure that could be considered a bug
<rbasak> I see.
<rbasak> OK
 * rbasak tries again
<pitti> rbasak: so I guess schroot will be fastest
<rbasak> I tend to use lxc so I don't have to worry about whether schroot is sufficient or not, since most of my work involves needing server daemons to work.
<pitti> right, that shouldn't be noticeably slower
<rbasak> I hadn't looked to see if this test is actually using it, but I did see it installing apache2
<rbasak> Yeah the speed difference is only a few seconds per virt driver reset
<rbasak> adt-run -U -B php-horde-serialize_2.0.2-5.dsc --- adt-virt-lxc -es vivid
<rbasak> Still passes!
<rbasak> I'll try schroot
<pitti> rbasak: you forgot the --apt-pocket=proposed now :)
<pitti> rbasak: you need both that and -U to actually upgrade
<rbasak> Aargh. Sorry.
<pitti> rbasak: and add -s while you're at it :)
<rbasak> I don't use -s by "default" since I often use -o and that breaks it.
<pitti> ogra_: smurfice!
<ogra_> haha
<rbasak> Usually I just poke at the source and rerun the whole thing.
<pitti> rbasak: oh, I thought I fixed that
<rbasak> Maybe you did.
<rbasak> My habits may be a little outdated.
<rbasak> BTW, while we're chatting, I usually use uvtool to create myself a qcow2 image to use against adt-virt-qemu, rather than your script.
<rbasak> For that, I just need a cloud-init userdata that works.
<rbasak> http://paste.ubuntu.com/10014410/ is what I use, adapted from your script.
<rbasak> It'd be nice to maintain that independently in the autopkgtest source somewhere.
<pitti> rbasak: ah, do you use /usr/share/autopkgtest/adt-setup-vm with that?
<rbasak> Eventually I'd like to make it one command in uvtool to produce a VM image file based on a userdata file.
<pitti> rbasak: that's where I keep all the actual VM setup now, so that it can be called from cloud-init, vmdebootstap, or even just manually if you have an arbitrary install
<rbasak> pitti: no - I use uvtool instead, with the userdata separately.
<pitti> rbasak: e. g. I can run that in a standard sid install and then use that VM for adt
<pitti> rbasak: well, it's not an "instead" -- this is a script to run inside a VM, it's not about setting up the VM itself
<rbasak> pitti: ah I see - I'm behind again and didn't know about that script - thanks.
<rbasak> I'd like that to be one command using uvtool in the future too.
<rbasak> pitti: OK, reproduced the failure now. Thanks!
<pitti> rbasak: right, it's meant to be that shared resource; please let me know if it needs any adjustment for running under uvtool
<rbasak> pitti: will do. It'll be a while before I can task switch to uvtool again though :-(
<tsdgeos> mitya57: Mirv: we can set https://bugs.launchpad.net/ubuntu/+source/gammaray/+bug/1395646 as fix commited since gammaray is compiling fine on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+packages no?
<ubottu> Launchpad bug 1395646 in gammaray (Ubuntu) "gammaray fails to build against Qt 5.4.0 beta" [Undecided,Triaged]
<mitya57> tsdgeos: done
<tsdgeos> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.4 is looking not that bad :)
<mitya57> tsdgeos: thanks for your work on that!
<pitti> rbasak: oh, fixed now, nice work!
<rbasak> pitti: no problem. Latest minor upstream release (not yet in Debian) already had a fix, so I just pulled that in.
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5 -> Valid candidate \o/
<pitti> rbasak: nice work!
<rbasak> :)
<pitti> the patch thingy disrupted this quite a bit :/
<rbasak> Two uninstallables left for migration. I just uploaded them. Hopefully it'll all migrate now, just waiting for it.
<rbasak> For some reason "chdist bin2src vivid ..." gives me blank output on about three packages. No idea why and I haven't looked into it, but that's why I missed them the first time.
<Mirv> tsdgeos: indeed
<aeoril> How important is it that I get my PGP key signed via photo id in person?  What exactly will I need that step for?
<tsdgeos> Mirv: mitya57: should we set https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1398372 as fix commited since the tests are being tracked on https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1403420 ?
<ubottu> Launchpad bug 1398372 in ubuntu-system-settings-online-accounts (Ubuntu) "webbrowser + u-s-s-online-accounts + ubuntu-html5-theme fail to build against Qt 5.4" [Undecided,Triaged]
<ubottu> Launchpad bug 1403420 in Online Accounts setup for Ubuntu Touch "u-s-s-online-accounts fails all UiProxyTest with Qt 5.4" [High,Triaged]
<rbasak> aeoril: that depends. Why do you think you need to do that? For Ubuntu development, you don't. To be involved in Debian, you do (eventually).
<Mirv> tsdgeos: yes, the former was about the private header usage
<aeoril> rbasak I was just following this howto guide and it showed that step:  https://help.ubuntu.com/community/GnuPrivacyGuardHowto
<tsdgeos> Mirv: ok, done
<aeoril> rbasak that is why I was asking, I didn't know if I needed to or not
<aeoril> rbasak I was hoping eventually to do kernel/driver development.  Would I need it for that?
<rbasak> aeoril: so just for general gpg use? It's useful to be able to find trust paths across the web, but I don't think that feature is used particularly often in practice.
<rbasak> aeoril: you can contribute without having a trust path.
<aeoril> rbasak I am planning on developing for the ubuntu community, in the kernel, driver, etc. areas
<aeoril> rbasak ok, good to know
<rbasak> It's fine then. You don't need it. I wouldn't worry about it. Take an opportunity to sign keys if the opportunity arises, but I wouldn't bother seeking it out.
<aeoril> rbasak ok, thank you very much
<pitti> tjaalton: latest mesa drops libopenvg1-mesa-dev, but qtbase-opensource-src{,-gles} still build dep on that; what's the replacement?
<pitti> jibel: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zope.interface is a similar problem that we had last week: zodb always failed on amd64, succeeds on i386, but is regarded as a regression
<pitti> jibel: did you happen to see what was wrong with those, or should I nudge it manually?
<tjaalton> pitti: there is none, I'll check qtbase-opensource-src*..
<pitti> tjaalton: ah, thanks
<jibel> pitti, I didn't find the reason yet, can you fix it manually please?
<pitti> jibel: yep, done
<tjaalton> pitti: looks like it takes quite a while to build.. hasn't failed after just dropping that BD
<tjaalton> so far..
<pitti> tjaalton: I wouldn't expect it to fail
<pitti> tjaalton: it builds on hurd without it, but configure detects availability
<pitti> OpenVG auto-detection... ()
<pitti> [...]
<tjaalton> ah, right
<pitti> OpenVG enabled.
<pitti> <https://launchpadlibrarian.net/195952397/buildlog_ubuntu-vivid-amd64.qtbase-opensource-src_5.3.2%2Bdfsg-4ubuntu9_UPLOADING.txt.gz>
<tjaalton> well changelog doesn't tell why it was added
<pitti> so it's not really a question of "builds" but whether we actually need/want this?
<pitti> Riddell: ^ do you happen to have an idea about this?
<bdmurray> mvo: do you want to have a look at bug 1415785 or shall I?
<ubottu> bug 1415785 in update-manager (Ubuntu) "Please remove all ltsp* blacklisting" [High,Confirmed] https://launchpad.net/bugs/1415785
<mvo> bdmurray: I uploded it to proposed already
<bdmurray> mvo: okay, cool
<mvo> bdmurray: thanks!
<shadeslayer> mvo: synaptic poke?
<mvo> shadeslayer: uploaded this morning, waiting in the proposed queue :)
<shadeslayer> aha :)
<ogra_> heh, a poke from the past
<shadeslayer> thx
<smoser> infinity, i dont really know how i'm going to test trusty + 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,Fix committed]
<infinity> smoser: Install the trusty deb on utopic, if utopic is where you can actually test?
<infinity> smoser: Have to be a bit creative when doing backport in steps like this. :/
<infinity> s/backport/backports/
<smoser> :)
<smoser> well, it hardly is validating "trusty"
<smoser> if i do the test on utopic.
<smoser> the other path was to grab the utopic qemu-system-ppc , which i think has a chance here.
<infinity> smoser: It's validating the binary in the deb.  In the case where its only use it to be sideloaded in a VM, that works.
<infinity> smoser: qemu-system-ppc64 on x86 would work too, it's just slow.
<smoser> i dont think it works.
<infinity> smoser: I know it does.
<xnox> didrocks: systemd[1]: Failed to populate transient preset unit settings, ignoring: Invalid argument
 * xnox is =(
<didrocks> xnox: that's on your experiment? I thought you didn't go on on it
<xnox> didrocks: well, i'm trying to benchmark how slow it is.
<xnox> didrocks: and it looks strange at the moment
<didrocks> weird :/
<nemo> hey Nexia, have you passed the situation on to them already?
<Nexia> nope
<nemo> ok
<Nexia> I'd rather leave that to you who knows more of what you're talking about (:P)
<nemo> so... briefly, Nexia here has an RT5390 wireless card messed up on his 64 bit ubuntu 14.10 install. Looking through forums and Launchpad, we see reports going back over 2 years, including a patch for 64 bit support showing up in a number of threads...
<nemo> (patch to the manufacturer driver)
<nemo> However, all the launchpad bugs I could find, even the ones where a comment described patching, were closed out for various reasons
<nemo> the precise laptop in the bug was recalled, or the bug was just marked expired, or in one case the bug is there, but with no comments or followup (that one is a mint bug)
<nemo> So... given that there seems to be a fix, and that this wireless card seems to still be broken, years later, I was wondering if one of the bugs could be resurrected...
<nemo> Comment #14 on this bug describes patching... https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759
<ubottu> Launchpad bug 1173759 in linux (Ubuntu) "Ubuntu 13.04 can detect wi-fi but can't connect" [Low,Expired]
<nemo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1178545  similar bug that was marked won't fix due to the laptop model
<ubottu> Launchpad bug 1178545 in linux (Ubuntu) "Wireless Card - Ralink RT5390 [1814:5390] does not work properly with Network manager" [Low,Won't fix]
<nemo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759#yui_3_10_3_1_1422897152203_434  direct link to the comment.  Woooo! Launchpad has IDs on comments now!  Used to be there was no way to reference a comment in the scope of the bug.  Now I can do it, even if it requires inspecting the HTML :p
<ubottu> Launchpad bug 1173759 in linux (Ubuntu) "Ubuntu 13.04 can detect wi-fi but can't connect" [Low,Expired]
<sarnold> ooo
<sarnold> nemo: aww, nuts, it doesn't appear to be 'stable' -- your url didn't work for me :(
<rbasak> nemo: it's had that for a long time. Right click on the comment number on the right hand side, and save the link. Is this something newer on top of that that I'm missing?
<rbasak> Eg. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759/comments/49
<ubottu> Launchpad bug 1173759 in linux (Ubuntu) "Ubuntu 13.04 can detect wi-fi but can't connect" [Low,Expired]
<sarnold> rbasak: the intention of the url is to -scroll- the main bug to the correct comment -- that's just _one_ comment, without context, and it's a bit annoying to see where it fits amongt he others
<rbasak> Ah, I see.
<sarnold> I know, I missed it at first too until I saw that the url was quite ugly :) hehe
<TJ-> nemo: The patch you referred to; there's a newer version for kernel 3.15+ also, at http://gridlox.net/diff/rt5592sta_fix_64bit_3.15.patch. Might be worth adding that info to the bug report
<nemo> sarnold: yeah, I'm used to that working on most forums and bug systems like bugzilla.  Never worked on launchpad which sucked.
<nemo> sarnold: well, once upon a time browsers supported XPath syntax for that, but it got removed as one of those advanced features hardly anyone used
<cjwatson> Could somebody file a bug against Launchpad itself for this, please?
<nemo> sarnold: luckily most sites are pretty good w/ the IDs âº
<rbasak> That sounds pretty trivial to add though, for anybody inclined. The comments are already numbered, so just need to add an anchor tag.
<nemo> rbasak: that'd be pretty cool, I've suffered this one for years âº
<cjwatson> Actually, hang on, maybe I found it
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/627252
<ubottu> Launchpad bug 627252 in Launchpad itself "no comment permalinks for issue comments" [Low,Triaged]
<nemo> heh
<cjwatson> See also https://bugs.launchpad.net/launchpad/+bug/124166
<ubottu> Launchpad bug 124166 in Launchpad itself "browsing to bug comment permalink should show comment in context" [Low,Triaged]
<nemo> Actually, I'd prefer that to direct link to the comment which is usually not nearly as useful
<sarnold> nemo: direct link is the best/easiest/only? way to see the entire comment when it's quite long..
<nemo> sarnold: oh. you guys trim long comments in-place? â¹
<sarnold> nemo: yeah :/
<nemo> sarnold: most systems don't do that. bugzilla etc.
<nemo> sarnold: can't use JS expand/collapse?
<cjwatson> We probably could, yes.
<nemo> sarnold: heck. could auto-expand based on the #uniqueid in the URL
<cjwatson> We'd also have to work out what to do about cases where bugs with very large numbers of comments are truncated to show only the first 40 and last 40 comments.
<sarnold> heh, I've not noticed that before
<cjwatson> So it's not quite trivial to put it all together.
<nemo> cjwatson: ah, well, the # part does get passed in the request, so could get processed serverside to include it
<nemo> hm
<nemo> wait. I might be on crack on that front
 * nemo doublechecks
<cjwatson> I believe you're wrong.
<sarnold> yeah I think only local javascript would know what's on the other side of the #
<nemo> cjwatson: yep. I'm wrong. damn
<nemo> cjwatson: meh... well, could still construct a URL w/ the UID in it, as well as the # part
<sarnold> there's always some reason why it's never easy :) heh
<nemo> sarnold: eh. that still works ;)
<nemo> or just make the link have /all in it
<nemo> er. +activity ? whatever
<nemo> aaaaaanyway. thoroughly derailed the initial thing, which was seeking help for poor Nexia here
<cjwatson> Sure, it's all possible
<cjwatson> If I were Nexia I would just file a new bug and explain the history.
<nemo> I'm gonna hazard a guess that he'd like to avoid building his own driver off the patch, even w/ exact instructions, given he's kinda new to Linux
<cjwatson> Probably better than making some poor developer wade through a load of ancient stuff.
<nemo> hm
<nemo> guess he's off to bed now
<nemo> he's a... teenager? on indian time.
<nemo> cjwatson: hm well. the others were closed incorrectly IMO
<nemo> so reopening doesn't seem that inappropriate...
<cjwatson> That's as may be, I haven't waded through them myself
<nemo> but, eh, whatev.
<ogra_> we're all teenagers !
<ogra_> (inside)
<Nexiazz> Good night, sorries. and all the help is appreciated :)
<cjwatson> But new bugs are pretty cheap, and it's easier to mark a new bug as a duplicate than it is to split off a section of an existing bug
<nemo> Nexiazz: so, yeah, cjwatson wants you to file a new bug and hope this one gets love âº
<cjwatson> (But I'm not a kernel developer, so.)
<nemo> Nexiazz: maybe we can spam it here in #ubuntu-devel to raise the profile ð
<cjwatson> #ubuntu-kernel is more likely to actually be noticed by somebody useful.
<nemo> Nexiazz: if you like, I can try to help you w/ those manual patch instructions from 2013...
<nemo> ah
<Nexiazz> hm, I'll think it over tomorrow (can't think properly even if I wanted to, tbh)
<nemo> cjwatson: LocutusOfBorg1 fired us off to here âº
<Nexiazz> atm*
<nemo> Nexiazz: 'k. gn
<cjwatson> *shrug*
<LocutusOfBorg1> I wasn't aware of #ubuntu-kernel :)
<Noskcaj> Can someone please look at bug 1417253
<ubottu> bug 1417253 in rt-extension-assettracker (Ubuntu) "[RM] Please remove rt-extension-assettracker from the archive" [Undecided,New] https://launchpad.net/bugs/1417253
<TheMuso> sitter: Yes, we have had flat volumes disabled in pulse for several years now in Ubuntu. I suggest you search throught eh changelog to find the bug number where this was discussed.
<TheMuso> sitter: Here, bug numbers where this is discussed: bug 403859 and bug #433209..
<ubottu> bug 403859 in pulseaudio (Ubuntu) "Karmic - sound level gets lowered when opening new sound files" [Undecided,Fix released] https://launchpad.net/bugs/403859
<ubottu> bug 433209 in pulseaudio (Ubuntu) "app volume muted when volume slider is non zero" [Undecided,Fix released] https://launchpad.net/bugs/433209
<ari-tczew> I have a question to FTBFS and dep-waiting. If package "A" has got dep-waiting (architecture "X") on package B, but that package ("B") doesn't provide binaries for architecture "X". Can we just add missing architecture to package "B" and build it?
<aeoril> I have a problem running Ubuntu 14.04.01 under VMWare *or* Hyper-V on a Windows 8.1 machine.  I have scripts that pop-up a new bash shell then run vi with the geometry different than default (e.g., gnome-terminal --geometry 156x48+80+50 -e "/usr/bin/vi .bashrc"
<aeoril> This works fine on my native Ubuntu machine running 14.04 LTS, but when I do it in either of those VM environments on Windows 8.1 the text in vi is scrolled down approximately to the line just after what would be the line in a bash window that uses the default size, about one default window's worth of lines is displayed in vi, then I have to scroll line by line down until I see a full
<aeoril> page worth of text and it works normally after that
<aeoril> I have looked around quite a bit and cannot find any bug like this in google, and have looked a little in launchpad bug browser and so far have not seen this bug
<aeoril> I want to report a bug and try to work on this problem.  I am having a hard time reducing the number of bugs reported in my searches for this bug on launchpad.  Is that normal?  Should I wade through all the bug reports before placing my own?  I guess whoever triaged the bug would have to do that anyway?
<aeoril> searching further in launchpad bug browser, the search term "vim resize" found no similar bug - I think I am safe to file a bug report and will not find one like mine.  Should I go ahead and do that?  I have never filed a bug report before, so am a little hesitant
<jderose> so i want to help test 14.04.2, but it seems the latest daily trusty ISO still doesn't have the *-lts-utopic packages pre-installed. is there some other location where these ISOs are getting staged?
<aeoril> jderose what are the *-lts-utopic packages exactly?
<ahoneybun> http://www.jupiterbroadcasting.com/76592/how-non-devs-can-help-linux-las-350/
<dobey> jderose: i don't see any xorg packages in the archive yet. only the kernel seems to be in so far :-/
<jderose> dobey: thanks. so the x and mesa packages are in proposed... and the daily iso has proposed enabled, for this reason i assume
<jderose> dobey: but there's no magic, special place when ISOs are being staged? :)
<dobey> jderose: cdimage.u.c is all i know
<jderose> aeoril: the hardware enablement packages for 14.04.2... basically the utopic kernel, x, and mesa packages backported to trusty
<aeoril> what are the mesa packages?
<aeoril> (I understand what "kernel and x" are)
<aeoril> jderose ^
<jderose> aeoril: mesa is an open source opengl/egl implementation for 3d graphics - http://packages.ubuntu.com/trusty/libegl1-mesa-drivers
<aeoril> jderose ahh, ok - thanks.  cdimage.ubuntu.com seems very slow for me right now
<jderose> yeah, super slow for me today also. but i'm in the us, so maybe just the wrong side of the pond :)
<aeoril> jderose I was just wondering about that - I am in USA too
<dobey> slow in what sense?
<jderose> dobey: slow as in downloading at like 14k or thereabouts
<aeoril> dobey for me, there is latency in getting the directory listings.  I have not tried downloading yet today - it was plenty fast yesterday
<dobey> i'm getting 2+ MB/s right now :)
<aeoril> dobey *very* slow
<aeoril> dobey where are you?
<dobey> well, now down to 1, but i am streaming youtube hd at the same time too
<dobey> usa
<aeoril> where in the USA?
<dobey> on 150Mbps fiber
<dobey> east coast
<aeoril> hmmm ... I am in the middle - going to ping ...
<aeoril> dobey ping shows 131 ms
<dobey> yeah
<aeoril> ahoneybun I looked at your link and it seemed like a lot of ads ...
<ahoneybun> aeoril, shows cost money
<aeoril> dobey jderose it seems fine now (at least for browsing the listings)
<Noskcaj_> Can someone please rebuild opensm's r-deps? allows it to migrate from proposed
<Noskcaj_> stgraber: bdrung: Would you have time to vote on my MOTU and xubuntu-packageset application?
<aeoril> Noskcaj We chatted yesterday.  I am new to Ubuntu development.  You mentioned you could help me with a bug if I found one I wanted to work on.  I have, and was wondering if the offer was still open
#ubuntu-devel 2015-02-03
<Noskcaj> aeoril, of course. I have limited time thisafternoon, but i'll help you as much as i can
<aeoril> Can you look at this forum post please, Noskcaj:  http://ubuntuforums.org/showthread.php?t=2263747
<aeoril> Noskcaj and, thanks!
<Noskcaj> So first off, make a launchpad bug with instructions to reliably reproduce this.
<Noskcaj> Then see if it still affects the version in vivid and git master
<aeoril> ok, I searched in launchpad bugs for "vi resize" and found nothing similar, so I think it is safe that it is not a duplicate
<aeoril> git master?
<lathiat> Anyone seeing or know a bug number for getting spurious \ or \\ input when entering characters like | on vivid.. started happening a few days ago.  maybe there isn't one but having a hard time search as i'm not really sure what package that's ultimately going to be.  happens often when inputting |, if i type a character immediately after (rapidly) its more likely to occur or input even more \ characters.
<Noskcaj> git.gnome.org/browse/gnome-terminal
<Noskcaj> aeoril, upstream's git
<aeoril> ok
<Noskcaj> also maybe check bugzilla.gnome.org for the bug (upstream bugtracker)
<aeoril> you think it might be vim, or bash?  Not gnome-terminal?
<aeoril> or the virtual display driver or whatever, Noskcaj?  I guess I am asking why did you immediately think it was gnome-terminal?  Just from past experience?
<Noskcaj_> aeoril: I'll look in an hour, playing dota then getting ready for some after-school stuff
<darkxst> aeoril, you need to isolate that, if there is some other cli app that has problems then its gnome-terminal
<darkxst> if not then its vim
<aeoril> darkxst ok, thanks - I will try out some other stuff - can you think of something good to try that uses the screen like vim?
<darkxst> if it is fixed in vivid or 14.10 then its a matter of finding the patch that fixed it
<darkxst> you could try some curses apps? although don't think vim uses curses
<aeoril> darkxst I was thinking of curses - if it is fixed in vivid or 14.10, the point of finding the patch is to backport?
<darkxst> aeoril, yes
<aeoril> ok
<aeoril> what about emacs?  Is that character based, or its own gui?
<aeoril> (I forget)
<aeoril> oh, the man page viewer, but that might just use vim ... ???
<aeoril> darkxst man page viewer worked fine ...
<aeoril> darkxst nano, irssi and the man page viewer all worked fine - I will file a bug report against vim.  Thanks.
<aeoril> Noskcaj fyi I am going to bed now (late here) - I think it is vim - will file bug report against vim tomorrow.  Thanks.
<tumbleweed> Noskcaj: sure (re rebuilds)
<tumbleweed> uploaded
<Noskcaj> aeoril, ok, good to see progress
<Noskcaj> tumbleweed, thanks. Also bug 1417257
<ubottu> bug 1417257 in opencolorio (Ubuntu) "Rebuild for libopenimageio1.4" [Undecided,New] https://launchpad.net/bugs/1417257
<tumbleweed> Noskcaj: not now, but I can look in the morning
<Noskcaj> ty
<pitti> Good morning
<darkxst> hey pitti
<darkxst> I can't reproduce that boot bug anywhere else ;(
<pitti> darkxst: yeah, I couldn't either, although I have a good idea why it happens
<darkxst> I may have hit a similar state with samba on my laptop, however it didn't block the boot like happens on my desktop
<pitti> darkxst: some more things: could you attach your /etc/network/interfaces, and try to comment out eth0 so that network-manager will bring it up instead of ifupdown? does that make a difference?
<darkxst> (i.e. lots of jobs waiting on ifup after login)
<pitti> darkxst: I think I fixed that in -7ubuntu1
<darkxst> pitti,  is really just:
<darkxst> auto eth0
<darkxst> iface eth0 inet dhcp
<darkxst> maybe thats not needed anymore with systemd-networkd in play though?
<pitti> darkxst: ok, I figured (and that's what I tried); I'd like to know if the hang also happens with that commented out
<darkxst> ok will try
<darkxst> pitti, boots fine with out /etc/network/interfaces snippet
<pitti> darkxst: ok, interesting; thanks
<pitti> darkxst: so then I don't understand why it doesn't start after the 2 mins of network-online.target timeout if you do use ifupdown
<darkxst> I do see other interfaces being brought up (virtual ones) ok
<darkxst> pitti, I don't either, but the message says 'no limit' which is presumably the timeout
<pitti> darkxst: oh, which "the message"?
<pitti> darkxst: I mean ifup-wait-all-auto.service has a timeout of 2 mins
<darkxst> pitti, when it hangs it says "a start job is waiting for ifup on eth0 (<timer>/no limit)
<darkxst> or similar to that alteast
<pitti> hm, interesting; do you happen to know which job that is?
<pitti> darkxst: can you boot with the debug shell and "systemd.log_level=debug", let it sit there for some 3 minutes, then do "journalctl > /root/logs" in the debug shell, reboot to a  working system, and attach /root/logs to the bug?
<pitti> (this assumes that in the broken case you don't get any gettys or lightdm)
<darkxst> pitti, right, when it hangs I never gets and never gets to the dm
<darkxst> pitt added to bug 1417010
<ubottu> bug 1417010 in systemd (Ubuntu) "systemd init gets stuck reloading smbd.service" [High,Triaged] https://launchpad.net/bugs/1417010
<darkxst> ^pitti
<pitti> darkxst: thanks! looking
<pitti> darkxst: do you have something in /etc/network/interfaces.d/ which defines a "test" interfaces?
<darkxst> pitti, no
<pitti> Feb 03 17:43:46 duhast systemd[1]: ifup@test.service changed dead -> start
<pitti> hm, so where does that come from then
<pitti> Feb 03 17:43:46 duhast systemd[1]: sys-subsystem-net-devices-test.device changed dead -> plugged
<pitti> Feb 03 17:43:46 duhast systemd[1]: sys-devices-virtual-net-test.device changed dead -> plugged
<pitti> darkxst: so your "ip a" presumably has some "test" thingy?
<darkxst> pitti, not that I can see
<pitti> darkxst: ls -l /sys/class/net/*test* ?
<darkxst> lrwxrwxrwx 1 root root 0 Feb  3 18:09 /sys/class/net/test -> ../../devices/virtual/net/test
<pitti> ok; but that succeeded, so shouldn't be responsible for these woes
<pitti> darkxst: hm, I still don't see anything in the logs which would actually wait for ifup@eth0..
<darkxst> pitti, it was actually " A start job is running for ifup on eth0"
<pitti> darkxst: right, and that job never finishes, I wonder why; it starts fine, but then NM seems to get in the way
<pitti> actually no, I guess it just logs that eth0 got online
<darkxst> I wonder if vmware runs hooks to bridge in the virtual network interfaces?
<darkxst> though the virtual interfaces seem to come up fine
<pitti> darkxst: oh, argh; can you please try somethign?
<pitti> darkxst: edit /lib/systemd/system/ifup@.service to fix thsi:
<pitti> (give me a sec)
<pitti> Before=network.target
<pitti> to
<pitti> Before=network-onlnie.target
<pitti> erk
<pitti> Before=network-online.target
<pitti> darkxst: this should at least fix network.target, and probably a whole slew of services which need it
<darkxst> pitti, ok, trying now
<darkxst> pitti, still hanging, but now there are 2 jobs trying to start for ifup@eth0
<darkxst> and I am getting a little concerned about the races happening with gdm everytime I boot with upstart ;(
<pitti> darkxst: there should be a lot fewer jobs be in "start waiting" now
<pitti> (systemctl list-jobs)
<pitti> ^ output of that appreciated
<darkxst> I didnt check that, but it was the same message as before but with (1 of 2), (2 of 2) alternating
<darkxst> pitti, ok, but this is the last reboot! atleast until I find the charger for my laptop
<pitti> darkxst: argh, sorry about that; I wish I could reproduce this, would make things so much easier to debug
<darkxst> pitti, yep always the case
<darkxst> pitti, http://pastebin.com/HNQDUL5B 32 vs ~40 before
<pitti> darkxst: thanks; I guess the remainder is due to init.d scripts waiting for $network, i. e. the loop that I explained in the bug
<darkxst> pitti, right, but that doesnt bring us closer to why ifup is hanging!
<pitti> darkxst: it's waiting for systemctl reload smbd.service (through the dhcp-enter-hoooks script)
<pitti> darkxst: and smbd.service is in turn waiting for network-online.target as it depends on $network
<darkxst> all my VM's boot in about 0.5sec even when I install smbd and configure shares
<pitti> darkxst: and network-online.target is waiting for ifup@eth0.service to finish, closing the dependency loop
<pitti> but the latter axis should be broken after 2 mins, so that timeout isn't working
<darkxst> pitti, right, could that be hardware specific?
<pitti> darkxst: I doubt it; I haven't fully read the samba hook yet, but apparently it behaves differently depending on the config
<pitti> darkxst: what's interesting is that networking.service is not running for you
<pitti> darkxst: i. e. in that regard it could be hw specific, in that eth0 isn't detected by the kernel at that time already
<pitti> but according to your debug log it is detected before, so it ought to already block networking.service
<pitti> darkxst: oh, I think I can funge something similar in my VM
<pitti> darkxst: I'll try to analyze and understand that more thoroughly, but have a doctor's appointment first; I'll get back to you later (or via a bug reply if you are already off for the evening)
<darkxst> pitti, just cooking dinner will be back later for a bit
<dholbach> good morning
<mvo_> pitti: good morning! could you think of a reason why we would not want http://paste.ubuntu.com/10030708/ ?  if not I will upload in a bit
<pitti> mvo_: what will that change?
<pitti> mvo_: i. e. would be nice to give the rationale to in the changelog and forward it to Debian
<pitti> mvo, wgrant, infinity: wrt. apt-ftparchive clean as in http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/model/ftparchive.py#L796 (which I'm trying to do in the ddeb retriever), this fails with "unable to allocate space from the buffer cache" for me
<pitti> is there a trick to increase its cache, with env vars or config items or so?
<wgrant> Hm, I don't remember anything special.
<wgrant> What's the syscall that's failing?
<mvo_> pitti: sure, I send #776905 to debian, it will make the partition labels visible when run as non-root. right now they are empty and only filled when running as root
<pitti> mvo_: or for blkid?
<mvo_> pitti: lsblk, I have not check blkid
<pitti> wgrant: I haven't straced it yet; it's a berkeley db thingy, I just wanted to know whether you happened to come across that
<mvo_> pitti: what is the exact error message for apt-ftparchive, could you pastebinit?
<wgrant> No, we hadn't, I'm afraid.
<mvo_> pitti: not from the top of my head either, sorry (the apt-ftparchive issue)
<pitti> mvo_: ah ok, lsblk and sudo lsblk don't look any different here; but sure, go ahead (with mentioning that in the changelog please)
<pitti> wgrant: ack, thanks
<mvo_> pitti: do you have a disklabel?
<mvo_> pitti: you might create one first using e2label to see a difference :)
<pitti> mvo_: ah heh, I guess I don't; the installer doesn't seem to create one
<pitti> mvo_: btrfs here :)
<mvo_> :)
<pitti> mvo_: error message> running again (takes a while)
<mvo_> ok
<pitti> mvo_: tried in a VM, still no diff between user and sudo; so lsblk might just always need that?
<pitti> mvo_: (sudo blkid shows it fine)
<mvo_> pitti: oh? strange, for me it was no label without libudev-dev b-d and label with it
<pitti> mvo_: right, my point; I was saying that user vs. root makes no difference
<mvo_> pitti: always need libudev-dev you mean ? could be I did not dig very deep. I wonder if its a issue in debian with non-linux arches(?)
<pitti> mvo_: for sure, but you can mark it as [linux-any]
<pitti> mvo_: non-linux arches just won't get that feature then *shrug* (not a regression)
 * mvo_ nods
<xnox> morning. So cold here.... we even had slow
<xnox> *snow
<pitti> hey xnox ; here too, -8 degrees, *brrr*
<Unit193> -18C here. :P
<seb128> mlankhorst, hey, is your ppa for xmir supposed to work on current vivid amd64? it wants to uninstall the drivers because abi mismatch here
<pitti> Unit193: double-brr
<ogra_> pitti, line 404 ff ... how do i find out more about that failure in the systemd world (i guess there is a way to get finer grained info from a job ?) http://paste.ubuntu.com/10031420/
<mlankhorst> seb128: add the x-staging ppa
<seb128> mlankhorst, not sure I want to go off vivid by so much
<mlankhorst> The x-staging ppa only has rebuilds against the new abi
<pitti> ogra_: .device units are really just representations of the actual udev devices, so I don't think there's much further logging
<pitti> ogra_: in general, "sudo systemctl status -l unitname" gives you the most useful things, like the current status and the last few lines of journal output that belogns to that unit
<pitti> ogra_: in this concrete case it looks like mmcblk0p1 was requested through /etc/fstab, but the device never actually appears
<ogra_> pitti, right, which i guess is just the same i already have there ... just filtered
<ogra_> pitti, heh, exactly ...
<pitti> ogra_: and if you look at the kernel messages, it only sees 0p4 and 0p2
<ogra_> which is weird
<ogra_> this is a normal snappy install (well, should be at least, not sure how teh user built it )
<pitti> ogra_: on that device, looking at parted and sudo blkid might be insightful
<ogra_> we did already :)
<pitti> i. e. perhaps there just aren't any partitions like that
<ogra_> well, with blkid
<ogra_> it seems to be all fine
<pitti> ogra_: hm, missing fs driver in the kernel then? what did blkid say?
<pitti> ogra_: I take it there really is no /dev/mmcblk0p1? if there is, then we indeed have a bug in systemd
<ogra_> vfat (as it should ...) and labelled "system-boot" (as it should)
<ogra_> the device exists in a booted system and can manually be mounted
<ogra_> we use "auto" in fstab ... i was wondering if it has to do with that
<ogra_> (btw, you dont seem to be in #snappy :) )
<pitti> ogra_: argh, bip restart last Friday, sorry :) I am now
<ogra_> heh
<LocutusOfBorg1> sil2100, I uploaded the new lucene++ on debian and syncd in ubuntu, hope is ok for you :)
<LocutusOfBorg1> also put in collab-maint shared git repository
<pitti> darkxst: I posted a possible solution to bug 1417010
<ubottu> bug 1417010 in systemd (Ubuntu) "systemd init gets stuck reloading smbd.service" [High,Triaged] https://launchpad.net/bugs/1417010
<darkxst> pitti, will look tomorrow, its late now
<darkxst> but thanks for investigating
<pitti> darkxst: ack, thansk
<LocutusOfBorg1> dholbach, poedit is sync'd from debian/experimental, I updated it on experimental again, will it be sync'd automatically?
<dholbach> no
<LocutusOfBorg1> thanks :)
<LocutusOfBorg1> can you please sync again :p
<dholbach> do you need it synced?
<LocutusOfBorg1> :)
<dholbach> sure
<dholbach> let me take a look - no need to file a bug
<LocutusOfBorg1> the 1.7.4 is a little bug fix release, mostly for macosx, but something is linux related
<LocutusOfBorg1> thanks, much appreciated!
<LocutusOfBorg1> I hope debian will be released soon, so I'll start again uploading in unstable :p
<dholbach> :)
<LocutusOfBorg1> thanks!
<doko> Riddell, ScottK: which of the cantor, kio, marble autopkg tests can be ignored?
<doko> pitti, ^^^
<Riddell> doko: all of them, upstream doesn't mind that they fail
<pitti> doko: for gcc probably all of them
<doko> pitti, ok, and how much do we care about mysql-5.5?
<doko> ugh, still in main, and 5.6 still in universe
<pitti> doko: probably not at all, AFAIK it's slated for removal
<doko> pitti, can you override these?
<cjwatson> Might be a good idea to check that one with the server team.
<cjwatson> I vaguely recall it not being quite trivial.
<rbasak> I've been working on mysql for the last few weeks.
<rbasak> I should have an upload soon. Then we can lose 5.5.
<doko> rbasak, 5.5, or 5.6?
<pitti> doko: yep, will do in a bit (still drowning on IRC)
<rbasak> doko: the upload will be for 5.6. So we can then remove 5.5, and put 5.6 in main.
<rbasak> (both are currently in the archive)
<rsalveti> pitti: just noticed we still got whoopsie crashing in loop (desktop and touch), we need to fix this at some point
<rsalveti> no crashing, just the upstart job failing to start because of the lock file
<mdeslaur> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<medicalwei> Hello
<medicalwei> I'd like to fix a bug in a package in Ubuntu, I am wondering what's the routine if the bug is fixed in Debian.
<medicalwei> Do Ubuntu have a sponsored upload like which in Debian?
<highvoltage> medicalwei: http://packaging.ubuntu.com/html/fixing-a-bug.html
<highvoltage> medicalwei: you might want to join #ubuntu-packaging and #ubuntu-motu for packaging related questions
<highvoltage> medicalwei: (but yes, you can request a sponsor for your upload)
<medicalwei> highvoltage, Thanks :)
<rbasak> medicalwei: https://wiki.ubuntu.com/SponsorshipProcess might also be relevant for you.
<medicalwei> Okay. My case is that the bug is fixed in the packaging git repo (Alioth) in Debian, but the maintainer says he won't upload since Debian jessie is frozen.
<rbasak> That's fine. Just point that out in your sponsorship request.
<rbasak> The sponsor can take that into account.
<xnox> didrocks: yo, didier. I think i got preset-transient to work correctly.
<xnox> my initial patch from hackfest is very very buggy.
<didrocks> xnox: nice! I'm still working on the fsck thing
<xnox> there are many places where it is assumed that "!UNIT_FILE_SYSTEM" means user mode. Thus adding a new system-level scope is hard.
 * xnox ponders if we should talk on #systemd, but meh
<didrocks> ah ok
<didrocks> yeah, making sense
<didrocks> I need still to send that email (probably tomorrow) summarizing the solution we decided on
<xnox> didrocks: so i have a better patch, which adds a new option (as a /proc/cmdline, --arg, config file setting)
<didrocks> but the fsck thing got all my time
<didrocks> what do you mean about the option?
<xnox> didrocks: well, keep working on the fsck thing for now. I'll test my updated patch again and will send you that for re-review.
<didrocks> xnox: great!
<xnox> didrocks: one has to opt-into transient presets explicitely.
<xnox> and i'm now pondering, if we even need separete /lib/systemd/system-preset-transient in that case.
<didrocks> humâ¦ didn't we say that we would only do this if there were some presets?
<didrocks> like, if the dir exists and there are some presets in it
<xnox> as the policy is the same, whether or not it's transient or normal preset.
<xnox> looking at the code checking whether or not there are any presets is fragileish =)
<xnox> (as one needs to stat a lot of dirs)
<didrocks> hum, not sure that upstream would like that though
<xnox> with normal preset the flag file is /etc/machine-id
<xnox> in transient-preset case it's a runtime option.
<xnox> imho applying normal presets should also be a runtime option.
<didrocks> I guess we discussed the case where some people would want a default distro + a first setup?
<xnox> cause e.g. in debian case we wouldn't want to enable / apply normal presets by default (when machine-id is missing)
<xnox> making it a first-class option makes it easier for distro-system-user-admin configuration
<xnox> just like --show-status --dump-core --log-level etc.
<didrocks> but I think that on some setups, they sys admin of the domain would want a first-time setup
<xnox> anyway, let me test this more and send you the updated patch
<didrocks> ok
<didrocks> xnox: enjoy :)
<pitti> doko_: ok, gcc unstuck; also some of python-defaults, I'll have a closer look after lunch
<xnox> didrocks: i think i'm happy now. performance is bad if one has a lot of units without any "Install" sections....
<xnox> which systemd seems to ship quite a few....
<xnox> adding a massive "disable *" helps.
<xnox> or well shipping "disable basic.target" "disable emergency.target" et.c
<xnox> overall it's then just a small penalty.
<lfrlucas> Hi. I would like to know if this bug will be fixed on Ubuntu 14.04 using KDE (kubuntu): https://bugs.kde.org/show_bug.cgi?id=271934
<ubottu> KDE bug 271934 in general "kded4 process grows on memory usage (possible leak)" [Normal,Resolved: upstream]
<lfrlucas> This is a memory leak related with policykit package. It was already solved on upstream...
<lfrlucas> Every time we make ssh kdeinit4 memory grows.
<brendand_> does anyone know why bzr push and pull are hanging so frequently these days? is it just me?
<lfrlucas> We are using Ubuntu server 14.04 and kde desktops in our university lab. Since we do a lot of ssh, this bug is quite severe for us. I would like to know if it would be solved, or if you have any workaround. Otherwise the only solution for us seems to migrate to opensuse, which already fixed this bug
<rbasak> lfrlucas: is there a bug in Launchpad tracking this?
<rbasak> lfrlucas: also, #kubuntu or #kubuntu-devel might be more relevant channels with people more likely to know the answer there.
<xnox> didrocks: if you want to try that preset patch on ubuntu, make sure you at least copy the 90-systemd.preset file into system-preset-transient dir.... otherwise you will boot to shutdown.target.
<rbasak> But generally, bugs that don't get reported are unlikely to get fixed.
<didrocks> xnox: will probably try tomorrow
<didrocks> xnox: want to concentrate/finish/polish
<xnox> didrocks: and given how all of this works, i'm siding to actually have "disable *" policy now
<xnox> didrocks: on the fsck, yeah. please =)
<didrocks> ;)
<lfrlucas> rbasak: Only found this bug reported on  https://bugs.kde.org/show_bug.cgi?id=271934, but this is not kde related. I discussed on #kubuntu-devel  and the problem is on  policykit-1 http://packages.ubuntu.com/trusty/policykit-1
<xnox> didrocks: once your done i'll steal your fsck stuff for stuff in debian probably.
<ubottu> KDE bug 271934 in general "kded4 process grows on memory usage (possible leak)" [Normal,Resolved: upstream]
<lfrlucas> rbasak: So, I guess only ubuntu team can fix this bug
<didrocks> xnox: be my guest :)
<didrocks> xnox: I'm rewritting it to use epoll, almost done, but there is still this libplymouth thingy
<lfrlucas> I guess the soution si simply to update policykit-1
<rbasak> lfrlucas: well, a first step is to have a good quality bug report in Launchpad that you can point to.
<lfrlucas> I would expect to see this bug fixed. But several weeks passed and nothing.  I don't understand how an LTS version can exist with a leak like this. Every time we make ssh used memory grows 2-3 mb. We lots of scripts making ssh, and dektop machines get memory full in few days
<rbasak> lfrlucas: I would expect nothing without a bug report in Launchpad.
<rbasak> lfrlucas: if this is of particular impact to Kubuntu users, the Kubuntu team might be interested in fixing the issue.
<lfrlucas> rbasak: How can I open a bug report. I don't find any place on website to open new bug
<rbasak> lfrlucas: https://help.ubuntu.com/community/ReportingBugs
<lfrlucas> rbasak: I read that page. I continue without understanding how to open new bug report
<rbasak> lfrlucas: try #ubuntu for help on this.
<rbasak> lfrlucas: or #kubuntu, if it really affects KDE users particularly.
<dupondje> cyphermox: lets hope you can fix the NetworkManager crashes :)
<cyphermox> dupondje: not a problem, I just pushed it to a PPA to try it out
<lfrlucas> rbasak: This affects kubuntu and ubuntu. We have 15 machines running ubuntu-server and kubuntu. If we don't solve this, we have to migrate all machines to another distro, including ubuntu-server, we should use the same basis distro in all machines.
<lfrlucas> rbasak: THe problem is identified and fixed upstream. It is on policykit package. I'm trying to open bug but I don''t find
<rbasak> lfrlucas: I use Ubuntu server constantly, as do many others. Are you sure you aren't doing something special that results in your leak, that doesn't affect others?
<lfrlucas> rbasak: The leak is only visible in ubuntu machines using kde. But I just saying, that this should be of interest of ubuntu guys to. Because we can not keep ubuntu-server machines with leaked kubuntu machines.
<rbasak> lfrlucas: OK, you're probably best off asking in #kubuntu to help get the bug filed then.
<cjwatson> Run "ubuntu-bug policykit-1"; that should walk you through reporting a bug against that.
<lfrlucas> tarpman: On kubuntu apps,  the bug report only points to kde.bugs
<lfrlucas> cjwatson: Thanks!
<doko> I hate arm64 ... both gcc-4.9 and gcc-5 are unable to build gcc-5
<lfrlucas> rbasak: Here it is https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
<ubottu> Launchpad bug 1417637 in policykit-1 (Ubuntu) "Kdeinit4 is leaking memory on every ssh login due to known bug on policykit-1" [Undecided,Confirmed]
<xnox> doko: It's ok, it hates you to. bootstrapping toolchain - who cares about that =)
<xnox> lfrlucas: well the patch at https://bugs.freedesktop.org/attachment.cgi?id=112087 looks trivial.
<lfrlucas> rbasak: We already have solution. I hope ubuntu team can solve this bug quickly! Otherwise we cannot continue using ubuntu like this...
<xnox> lfrlucas: did you try rebuilding policykit package with that patch to see if it solves the problem for you?
<xnox> if it does doing an SRU for this one-liner is trivial.
<lfrlucas> xnox: Noo, I have no experience rebuild system packages on ubuntu
<lfrlucas> xnox: But I would like to help on that
<xnox> lfrlucas: do you know how to use "diff" and "patch" utilities?
<lfrlucas> ya
<lfrlucas> xnox: The problem should be to gennerate deb.. And what source code ubuntu uses for policykit-1 ?
<AkivaAvraham> Hey all: Live Ask Ubuntu Anything live in 5 minutes: http://ubuntuonair.com | #ubuntu-on-air
<xnox> lfrlucas: https://help.ubuntu.com/community/UpdatingADeb
<xnox> lfrlucas: follow that, policykit-1 is the package name, patch is at http://cgit.freedesktop.org/polkit/patch/?id=f4d71e0de885010494b8b0b8d62ca910011d7544
<mdeslaur> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<lfrlucas> xnox: Could you help here? http://pastebin.com/JCarGuH2
<lfrlucas> Anyone could help here?  http://pastebin.com/JCarGuH2
<rbasak> lfrlucas: your version number for an update to Trusty needs to be 0.105-4ubuntu2.14.04.1. Get rid of the "patched" thing, it's messing it up.
<lfrlucas> rbasak: I'm testing the patch that solves the bug of policykit. How to test the patch?
<lfrlucas> rbasak: xnox pointed me to  https://help.ubuntu.com/community/UpdatingADeb
<lfrlucas> xnox, rbasak: I used dpkg-buildpackage -b and run debi.
<lfrlucas> xnox, rbasak: I can confirm that the patch in http://cgit.freedesktop.org/polkit/patch/?id=f4d71e0de885010494b8b0b8d62ca910011d7544 solves the bug in https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
<ubottu> Launchpad bug 1417637 in policykit-1 (Ubuntu) "Kdeinit4 is leaking memory on every ssh login due to known bug on policykit-1" [Undecided,Confirmed]
<lfrlucas> Kdeinit4 does not grow anymore in this machine were I installed patched policykit
<xnox> lfrlucas: well comment on the bug report. For faster SRU times it's best to document how to observe the bug, and how to observe that it is gone after policykit is upgrade with such a patch.
<lfrlucas> *where
<lfrlucas> just looking memory usage in htop
<xnox> lfrlucas: e.g. i run this commend to check memory usage of foo, ssh in, check again it grows, but now it stays constant.
<xnox> lfrlucas: well on irc we know that =) random people reading and/or processing that stable release upgrade will only see what's in the bug report =)
<lfrlucas> xnox: I guess I made what you asked...
<lfrlucas> xnox: Now, should we wait for someone to fix this?
<xnox> lfrlucas: if you can prepare a debdiff - that is the diff of all packaging before and after the patch is applied with the right version number targetting vivid that would be first step.
<xnox> if you have the new .dsc that you just compiled: $ debdiff old.dsc new.dsc
<xnox> should produce that.
<lfrlucas> vivid? and trusty?
<xnox> (not version number for vivid would be e.g. 0.1-2ubuntu3, where the last digit is one higher than last one, or some such)
<xnox> then attaching such a debdiff and subscribing sponsor would seal the deal for now.
<xnox> lfrlucas: once the patch is in vivid, debdiffs for utopic & trusty can be created and uploaded.
<lfrlucas> I made the patch on trusty....
<xnox> lfrlucas: bug affects current development series (15.04) and needs to be fixed there first.
<xnox> as well as stable series.
<xnox> lfrlucas: attach that, it's already some work done - for trusty upload.
<xnox> you can do pull-lp-source policykit-1 vivid
<lfrlucas> xnox: What about version numbering? I didn't change anything
<xnox> to get the vivid's current .dsc & well utopics, and rince & repeat.
<xnox> $ dch -i
<xnox> should do the right thing, it will increment the version number and open the debian/changelog to fill in details.
<xnox> Fix memory leak in foobar (LP: #bugnumber)
<xnox> is all that's needed there.
<lfrlucas> It shows vim with this first line: policykit-1 (0.105-4ubuntu3) UNRELEASED; urgency=medium
<lfrlucas> xnox: should I change anything
<xnox> i need to go, but hopefully somebody can help you.
<xnox> let me point you at documentation
<xnox> lfrlucas: http://packaging.ubuntu.com/html/fixing-a-bug.html#documenting-the-fix
<lfrlucas> xnox: thanks
<xnox> the guide uses bzr as well... but that bit is optional.
<xnox> you can do $ debuild -S to get new dsc, and then generate debdiff with $ debdiff trusty-current.dsc your-new.dsc
<xnox> once attached to the bug report subscribe "~ubuntu-sponsors" team =)
<lfrlucas> xnox: debuild -S doesn't work for me. But dpkg-buildpackage -b works
<lfrlucas> dpkg-source: error: cannot represent change to src/polkitagent/PolkitAgent-1.0.typelib: binary file contents changed
<lfrlucas> dpkg-source: error: add src/polkitagent/PolkitAgent-1.0.typelib in debian/source/include-binaries if you want to store the modified binary in the Debian tar-ball
<xnox> lfrlucas: typically the patch should be stored in debian/patches directory
<lfrlucas> hmmm
<xnox> and added to the debian/patches/series file
<xnox> lfrlucas: binary contents changed - run $ ./debian/rules clean
<xnox> lfrlucas: if that does not help, remove the binary files that are changed. E.g. rm src/polkitagent/PolkitAgent-1.0.typelib should do the trick
<xnox> (it's a way to specify "i did not change this" and "please use copy from upstream tarball")
<lfrlucas> xnox: What description should I use for patch. Bugfix?
<xnox> fixes a memory leak when this and that happens (LP: #bugnumber)
<lfrlucas> And patch name?
<xnox> lfrlucas: re-use / get insparation from the the git patch commit message
<lfrlucas> ok
<xnox> lfrlucas: it's free-form text, see previous changelog entries for style / feel as to how to write them.
<lfrlucas> Most patches have number, like this: 01_pam_polkit.patch
<lfrlucas> Is it required?
<lfrlucas> kdeleak_fix.patch?
<lfrlucas> gpg: /tmp/debsign.bKOjVp0a/policykit-1_0.105-4ubuntu3.dsc: clearsign failed: secret key not available
<lfrlucas> debsign: gpg error occurred!  Aborting....
<lfrlucas> Any help?
<cjwatson> lfrlucas: You can ignore that if you aren't planning to upload the source package itself to an archive.
<lfrlucas> cjwatson: But debuild -S fails...
<lfrlucas> debsign: gpg error occurred!  Aborting....
<lfrlucas> debuild: fatal error at line 1283:
<lfrlucas> I want to fix bug  https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
<ubottu> Launchpad bug 1417637 in policykit-1 (Ubuntu) "Kdeinit4 is leaking memory on every ssh login due to known bug on policykit-1" [Undecided,Confirmed]
<rbasak> lfrlucas: call debuild with -us -uc also. That'll tell it not to sign.
<lfrlucas> rbasak: thanks
<cjwatson> lfrlucas: It only fails right at the end, and it has in fact successfully generated a source package.  And as rbasak says.
<lfrlucas> cjwatson: I already have debdiff output. How should I update launchpad?
<lfrlucas> Here it is : http://pastebin.com/E2yGwp4n
<cjwatson> Save the debdiff to a file and attach it to the bug.
<cjwatson> Not a pastebin link, because pastebins can expire.
<lfrlucas> ok, thanks
<lfrlucas> Can I call debdiff ?
<lfrlucas> name it debdiff
<cjwatson> Why not?
<lfrlucas> ok
<cjwatson> It hardly matters.
<lfrlucas> This is my first time doing this
<alexbligh1> hi rbasak - don't suppose you've made any progress with the backport to T of https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ?
<ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged]
<lfrlucas> cjwatson, xnox, rbasak: Debdiff is uploaded: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
<ubottu> Launchpad bug 1417637 in policykit-1 (Ubuntu) "Kdeinit4 is leaking memory on every ssh login due to known bug on policykit-1" [Undecided,Confirmed]
<lfrlucas> What will happen then?
<xnox> lfrlucas: looks good. By large it is correct, and should be easy enough to be tweaked to upload into each of the required series where the fix is needed.
<cjwatson> It's on the sponsorship queue, so it'll get looked at in time
<cjwatson> http://reqorts.qa.ubuntu.com/reports/sponsoring/ - well, it'll get there in a moment
<xnox> lfrlucas: thank you for contributing to ubuntu development.
<lfrlucas> Thank you all. We have about 7 kubuntu machines and 7 ubuntu-server machines in your university research lab. I hope to see this bug fixed ...
<lfrlucas> What's sponsor team ?
<lfrlucas> Is it possible to remove packages installed by apt-get build-dep policykit-1 ?
<sarnold> lfrlucas: best is if you still have that list of packages in scrollback and can apt-get purge them all with copy-and-paste :)
<sarnold> lfrlucas: /var/log/dpkg.log is there in case you don't have it in scrollback any longer
<lfrlucas> sarnold: thanks
<sarnold> lfrlucas: ... and it'd be best to use sbuild in the future to avoid the issue :)
<lfrlucas> sarnold: To replace the patched  policykit-1 which I installed using debi, with the original repository version, the apt-get install policykit-1 command should be enough?
<sarnold> lfrlucas: unlikely, that one might be difficult to easily fix
<lfrlucas> sarnold: At leas it installed policykit-1-0.105-4ubuntu2 over my version policykit-1-0.105-4ubuntu3 which I generated before.
<sarnold> lfrlucas: ah, nice
<dobey> you can specify an exact version with apt-get install, and you can --reinstall as well
<sarnold> dobey: ooo. nice on both counts. :)
<dobey> apt-get install policykit-1=0.105-4ubuntu2 for example
<lfrlucas> dobey: It will replace an higher version without problem, even if the installed files are different? In my case, the file files should be the same
<cjwatson> Yes
<lfrlucas> hmm nice
<lfrlucas> cjwatson: xnox told me before to subscribe to sponsors-team after upload debdiff. Is that required? What is that intended for?
<cjwatson> it's already done
<cjwatson> and it causes the bug to end up on the sponsorship queue, which I linked to above
<lfrlucas> So you guys made it for me?
<cjwatson> Somebody did, I don't know who
<lfrlucas> nice, thanks
<cjwatson> I had been about to do it for you and noticed that somebody already had
<lfrlucas> I think it was xnox
<asac> doko: slangasek: https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1417664
<ubottu> Launchpad bug 1417664 in gcc-4.9 (Ubuntu) "Unity8 build causes internal compiler error on armhf" [Critical,New]
<Noskcaj> What would be causing https://launchpadlibrarian.net/196501062/buildlog_ubuntu-vivid-amd64.sagan_1.0.0~RC4-0ubuntu1~vivid1_FAILEDTOBUILD.txt.gz to not build? It says it can't make executables
<cjwatson> Noskcaj: I think "/usr/bin/ld: cannot find -lee" may be the real error message there, so pehaps just a missing build-dep
<cjwatson> *perhaps
<Noskcaj> thanks, i'd forgot that was needed as well (it was listed in the FTBFS bug report somewhere)
<flexiondotorg> cyphermox, https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-meta
<cyphermox> flexiondotorg: cool, so I think we should start with reviewing the packages that are still only in ubuntu-mate-dev PPA and get them to the archive, and finish with the meta-package
<flexiondotorg> Agreed.
<cyphermox> let's start with fun stuff, yoga-gtk-theme maybe? :)
<flexiondotorg> cyphermox, https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/yuyo-gtk-theme
<cyphermox> oh, yuyo, not yoga
#ubuntu-devel 2015-02-04
<cyphermox> flexiondotorg: we'll still need someone else (dholbach?) to review yuyo, but have you addressed the things I pointed out?
<cyphermox> I'd be ready to look at another one ;)
<flexiondotorg> cyphermox, I'm just pushing a pull-request to the upstream git repo.
<cyphermox> oh cool.
<cyphermox> that will make the rules file simpler
<flexiondotorg> cyphermox, Indeed.
<flexiondotorg> cyphermox, Yuyo pushed upstream. Contacted Sam, he has some other fixes to apply.
<cyphermox> cool
<flexiondotorg> So, I think next up is ubuntu-mate-artwork
<cyphermox> great.
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork
<flexiondotorg> While we wait for GitHub to sync to LP, maybe the grub theme is next?
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/grub2-themes-ubuntu-mate
<pitti> Good morning
<darkxst> pitti, hi, still no luck with systemd boot hang, invoke-rc never returns so ||true isnt helping
<pitti> darkxst: (OTP, brb)
<mgedmin> who maintains ubuntu-release-upgrader?  http://pad.lv/1417880 is a papercut, IMHO (easy to fix, annoying to many people)
<ubottu> Launchpad bug 1417880 in ubuntu-release-upgrader (Ubuntu) "Invisible prompts in do-release-upgrade" [Undecided,New]
<pitti> darkxst: argh, invoke-rc.d is blocking? we have two patches which are supposed to avoid that, but perhaps that happens too late for them to apply
<pitti> darkxst: incidentally that's something I'm just discussing on the upstream list..
<pitti> darkxst: this should help: http://paste.ubuntu.com/10048858/  ; not a complete fix yet, but at least it should avoid the hang; I think it should also make the || true unnecessary
<pitti> darkxst: followed up to the bug
<darkxst> pitti, ok, will try it out in a bit, have to pop out to shops first
<pitti> darkxst: thanks; this is quite a tricky problem unfortunately, so thanks for your patience
<slangasek> xnox: hi, hadn't you at some point had a patch related to enabling i386 ovmf builds?  I don't find it in the edk2 bug report (bug #1272434) or in the Debian bts
<ubottu> bug 1272434 in edk2 (Ubuntu) "Please provide i386 & arm64 builds" [Wishlist,Confirmed] https://launchpad.net/bugs/1272434
<slangasek> xnox: I'm updating to a new upstream commit of edk2 for arm64 support, and was hoping to spare myself the pain of going through the requisite packaging changes if you'd already done so
<darkxst> pitti, ok it did boot now
<pitti> darkxst: that's with --no-block?
<darkxst> pitti, yes with you --no-block patch
<darkxst> although I still had the || true in samba hook as well
<pitti> darkxst: that wouldn't be necessary with the --no-block fix (I think), but with a slighly more correct fix it's still the right thing to do
<darkxst> pitti, right, I guess a hook shouldnt cause the unit to fail
<pitti> darkxst: it's not the unit; the problem is that a failed invoke-rc.d reload (because smbd isn't running you can't reload it) breaks DHCP
<pitti> darkxst: as for some weird reason this is a DHCP enter hook, not an exit hook
<pitti> and if the enter hook fails, the actual DHCP isn't done
<darkxst> pitti, I guess samba needs to export a dhcp server over netbios or something?
<pitti> darkxst: yeah, perhaps; for now I assume that it being an enter hook is intended
<dholbach> good morning
<pitti> darkxst: I looked at this again, and I think the || true was a red herring; I thought I had DHCP failing on a hook that exits 1 yesterday, but I can't reproduce this
<pitti> darkxst: so dropping the || true should be fine
 * pitti finds debian bug 652942 which is the same issue
<ubottu> Debian bug 652942 in samba-common "dhcp hook runs reload on shutdown (after service has been stopped)" [Important,Open] http://bugs.debian.org/652942
<Noskcaj> Can someone please look at bug 1417253
<ubottu> bug 1417253 in rt-extension-assettracker (Ubuntu) "[RM] Please remove rt-extension-assettracker from the archive" [Undecided,New] https://launchpad.net/bugs/1417253
<pitti> dpm: ah, thanks for the l10n-stats heads-up!
<pitti> dpm: once it's all there, I'll adjust langpack-o-matic accordingly
<dpm> pitti, yw. ack, sounds great!
<Saviq> doko_, hey, not sure if it matters, but I was unable to reproduce the gcc failure locally (except once when it rebooted my phone)
<Saviq> doko_, which is why I did not submit any preprocessed source, was hoping you could get that from a builder
<cjwatson> Saviq: We can't extract anything from builders.
<cjwatson> Saviq: Have you tried on porter-armhf?
<pitti> well, you could abuse the build log by cat'ing stuff
<cjwatson> Sure
<cjwatson> But it's probably easier to reproduce on a porter box
<pitti> (not nice if the stuff you are cat'ing is large, though)
<Saviq> cjwatson, not sure what porter-armhf is
<pitti> *nod*, just mentioning the last resort; I've had some cases where stuff wasn't reproducible on porter boxes
<cjwatson> You don't know about porter boxes? *blink*
<cjwatson> https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes
 * cjwatson upgrades the relevant chroot
<pitti> I wish they had a sensible schroot setup, but otherwise they are great indeed
<cjwatson> Yeah, I have an RT in for that
<cjwatson> One of these days
 * Saviq pubkey-denied :/
<cjwatson> Ask IS to add you to the porting_team group.  All technical staff in UE should be in that AFAIK ...
<xnox> slangasek: i have some refactoring done to support alt builds.
<xnox> slangasek: however, efi-shell does not have gcc assembly files ported to compile for ia32 with gcc compiler (MSVC only compiler)
<xnox> and i got disappoint.
<slangasek> Saviq: separately, you should be aware that doko is already working on using the hand-cranked armhf porter box to try to debug your recent gcc ICE so throwing more logins at the problem is unlikely to resolve it more quickly
<Saviq> slangasek, understood, he did put the bug in Incomplete and asked for preprocessed sources, so wasn't sure whose court the ball was in
<slangasek> Saviq: ah - actually the machine is currently idle, so we can try to get a reproducer on there.  however it is a panda
<Saviq> slangasek, I'll try again on my phone here, prolly faster than a panda
<slangasek> ok
<Saviq> I *think* when I tried before I might not have been using the new gcc, only realized today the silo PPAs have proposed enabled
<cjwatson> Saviq: the new gcc is in the release pocket anyway
<slangasek> correct
<Saviq> cjwatson, yeah, I know, just saying that might be why I wasn't able to repro locally yesterday
<cjwatson> slangasek: really?  the relevant chroot in the porter box doesn't have anything like unity8's build-deps installed - I'm putting those in place at the moment
<slangasek> cjwatson: right, perhaps he didn't actually get past the point of complaining to me that shedir was still the porter box ;P
 * cjwatson tries a build on shedir, since apparently nobody else is
<cjwatson> doko,Saviq,slangasek: bug updated with the usual stuff from README.Bugs
<Saviq> cjwatson, thanks
<caribou> tkamppeter: do you have time to sponsor a fix I have for CUPS : bug #1352809
<ubottu> bug 1352809 in cups (Ubuntu) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809
<caribou> or anyone who feels like uploading cups
<pitti> darkxst: still here by chance?
<tkamppeter> caribou, no problem, I can do it.
<caribou> tkamppeter: I extracted & adapted only the fix for the CUPS_SERVER override. Details are in the comments with reference to the upstream bug
<tkamppeter> caribou, OK, fix is simple will add it to current Debian and Vivid, via Debian GIT repo.
<caribou> tkamppeter: ah good; I intended to do a reportbug on it (didn't know you were on the debian side)
<caribou> tkamppeter: thanks. Once it gets in vivid I'll SRU to trusty & Utopic
<slangasek> xnox: can you send me a pointer to whatever your refactoring was to support alt builds?  I need to reconcile it with dannf's requests for arm64 support
<xnox> slangasek: ok.
<xnox> slangasek: not asap.
<slangasek> ok
<slangasek> xnox: I'll hold off on uploading until I can take a look at your proposal; I don't want to reorganize this stuff in the archive more than once
<slangasek> Saviq: added a suggestion of a possible unity8 temporary workaround to the bug report fyi
<Saviq> slangasek, thanks
<Saviq> will test in a moment
<Saviq> slangasek, this seems to get us through indeed, thanks a bunch
 * Saviq runs to prep an MP
<loin> hi, is there a easy way to build a executable on a newer ubuntu that will run on older debians? currently it says that my glibc is too old when trying to run on older systems. when i objdump i find out that it uses memcpy from GLIBC_2.14 instead of using the memcpy from an older version. i don't want to use hacks such as __asm__(".symver memcpymemcpy@GLIBC_2.2.5"); in my c code
<mgedmin> loin, pbuilder or sbuilder can be helpful there, AFAIU
<loin> mgedmin: is this even worth bothering with? should i just install a older ubuntu and have the older glibc natively?
<mgedmin> these tools create a chroot with a minimal older ubuntu/debian installation that you can use to build binaries compatible with those versions
<rbasak> loin: build it on a much older release maybe? I would use sbuild - it's much easier than installing an older Ubuntu, quicker once set up and easily repeatable for easier developer iteration.
<mgedmin> and you can have many chroots for many versions
<cjwatson> loin: I agree with mgedmin and rbasak.  https://wiki.ubuntu.com/SimpleSbuild
<loin> thanks cjwatson, i'm still investigating
<cjwatson> in general new libc is compatible with binaries built against old libc but not necessarily vice versa.  hacking around with symver is a recipe for weird failures and horrible confusion.
<loin> cjwatson: that's why i'm not doing it
<loin> wish there was a simpler way, though
<cjwatson> sbuild is really easy once you absorb the capital cost of setting it up.
<rbasak> mk-sbuild helps with that. Although I feel it could be improved by requiring less stuff, it isn't too bad.
<cjwatson> and if you aren't doing things that are in the form of source packages, then setting up sbuild involves setting up schroot instances for the relevant releases, which you can use in isolation
<pitti> https://wiki.ubuntu.com/SimpleSbuild FTR
<cjwatson> linked above :)
<pitti> ah sorry, missed that
<loin> thanks guys, this has been helpful
<mterry> @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: mterry
<rbasak> I'll soon be uploading a new src:mysql-5.6 that takes over some binary packages (eg. mysql-common) from src:mysql-5.5.
<rbasak> Is there anything special I need to do for this? For example, do I need to upload a new src:mysql-5.5 that drops mysql-common? Or will the new one just take over?
<pitti> rbasak: the new one will take over
<rbasak> OK, thanks!
<pitti> rbasak: i. e. if multiple sources build a binary foo, the one with the highest version number wins
<pitti> rbasak: that said, we should still clean up the old sources of course
<pitti> but nothing bad should happen
<rbasak> That makes sense. Yeah - the old src:mysql-5.5 will need to be deleted afterwards.
<cjwatson> yeah, we should clean up the old one not least because it will be impossible to reupload it without removing those binaries
<flexiondotorg_> Hi
<flexiondotorg_> cyphermox, Thanks for everything yesterday.
<flexiondotorg_> I'm going to try and clean up some more packages.
<flexiondotorg_> cyphermox, When you have the time let me know and I'll suggest the next package for assessment ð
<cyphermox> flexiondotorg_: it will take me a bit
<cyphermox> but if you have time to bug dholbach for the second review you need that could work in the meantime ;)
<flexiondotorg_> No problem. I leanrt enough yesterday to hopefully make some corrections myself.
<flexiondotorg_> dholbach, How are you fixed today?
<Unit193> cyphermox: Anything new for NM?  Chance of it in vivid?
<flexiondotorg_> dholbach, Do you have time to look at some packages that will need uploading into the official archive?
<dholbach> no, not today I'm afraid
<flexiondotorg_> dholbach, OK.
<dholbach> if you want, you can subscribe me to the bug or MP and I can take a look at it tomorrow if nobody beats me to it
<cyphermox> Unit193: NM 0.9.10.0 is in vivid barring one bug if you paired a bluetooth phone and installed the ubutnu-desktop-next metapackage,
<Unit193> cyphermox: Great!  I presume you saw 1.0.0 hit exp?
<cyphermox> dholbach: thanks, we can ask any other MOTU too, it's for landing new packages
<cyphermox> Unit193: yes
<dholbach> brilliant, thanks
<cyphermox> Unit193: just have no time just now to prepare it, and it would take time to update the patches, do the testing for everything, etc.
<cyphermox> maybe off hours, later this week? :)
<Unit193> Yes, understandable.  .10 is the one I'm looking forward to.
<cyphermox> it's already landed, you can feel free to play with it ;)
<arges> infinity: any objections/issues with sru-releasing all the xserver/xorg stuff?
<dobey> the lts-utopic xorg?
<dupingping> how can i get full window image includes it's decoration in opengl plugin and convert it to memory buffer?
<pitti> darkxst: ok, afer pulling out my hair for another day, I now followed up to bug 1417010 again; I'd be grateful if you could test this again
<ubottu> bug 1417010 in systemd (Ubuntu) "Reloading services can result in a deadlock under systemd" [High,In progress] https://launchpad.net/bugs/1417010
<mterry_> @pilot out
<mterry> @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:
<cyphermox> xnox: hey, would you happen to have time for a code-review for ubiquity?
<smoser> infinity, http://paste.ubuntu.com/10058049/
<smoser> does that make sense?
<smoser> 2 of the cells have no memory.
<smoser> (seeing this because openstack gets a 'None' for memory and tries to divide it)
<system0x01>  I consider squash some of the bugs. Which tool/tools will be appropriate  for that purpose
<cyphermox> system0x01: I suggest you start by reading http://packaging.ubuntu.com/html/introduction-to-ubuntu-development.html; section 2 will tell you all you need to know about the tools suggested
<darkxst> pitti, updated "service" script boots fine
<flexiondotorg_> Trevinho, Are you available for a quick question?
<bdmurray> pitti: https://code.launchpad.net/~brian-murray/apport/bug-1084979/+merge/248685
<bdmurray> pitti: Could you have a look at that during your work day?
<sarnold> "Does Ubuntu have some piuparts facility somewhere that can be integrated with PPA so new builds would be automatically tested for install/upgrade/remove?" https://bugs.launchpad.net/bugs/1417917
<ubottu> Launchpad bug 1417917 in mariadb-5.5 (Ubuntu) "package mariadb-server-5.5 install returned error exit status 1 due bug in mysql flags removal" [Undecided,Confirmed]
#ubuntu-devel 2015-02-05
<dupingping> How to get window's full image in compiz plugin?
<darkxst> pitti, what is the best place for this to live? bug 1418262
<ubottu> bug 1418262 in apport (Ubuntu) "apport hook to detect wayland sessions" [Undecided,New] https://launchpad.net/bugs/1418262
<darkxst> I suppose debian would find that useful also
<pitti> Good morning
<pitti> darkxst: wonderful!
<darkxst> pitti, yep I though so as well, seems a reasonable solution as well
<pitti> darkxst: followed up to 1418262
<darkxst> pitti, its kind of useless in weston
<darkxst> thats just a reference compositor, don't think anyone is actually using it
<darkxst> all of the wayland libraries are installed by default
<darkxst> which only leaves maybe Xwayland
<pitti> bdmurray: will do, thanks
<pitti> darkxst: ah, is the complete rendering etc. done in the libraries?
<pitti> darkxst: it doesn't matter if the package is installed by default -- the hook of course needs to actually do some runtime detection (I left that out in the comment, I thought it was obvious)
<darkxst> pitti, I think run-time detection is really hard, since there is no wayland server as such
<pitti> darkxst: if all else is inappropriate we could also put it into apport, but I rather don't want to know about or maintain how wayland sessions are detected; that's something that a wayland packages are much better at
<darkxst> wayland is basically a  set of libraries that define a protocol, the compositor becomes the server
<pitti> darkxst: well, I can't believe that -- there must be *something* to tell a process that it can connect to wayland; the equivalent of $DISPLAY for X?
<darkxst> pitti, as mentioned in the bug report, there seems to be a $WAYLAND_DISPLAY var
<pitti> ah
<darkxst> hopefully that is generic and not just a GNOME-ism
<pitti> ah, and the wayland libs are synced with Debian
<darkxst> pitti, and then there are other env vars that define (for GNOME) which backend is in use i.e wayland of Xwayland
<darkxst> I assume apport reads the program env and not the gloval env?
<pitti> darkxst: followed up again
<pitti> darkxst: there is no "global" env; yes, you get the crashed program's env
<darkxst> pitti, replied on apport bug
<darkxst> and by global, I meant the users env
<darkxst> but that doesn't matter it works as expected really
<darkxst> so basically a tag, and perhaps including (GDK/CLUTTER)_BACKEND in the report if they are set as wayland is enough for us
<darkxst> currently all GNOME apps run by default under Xwayland, unless the user explicitly requests wayland backend
<darkxst> that I suspect will change in 3.16
<alkisg> Good morning
<pitti> darkxst: that sounds good
<pitti> darkxst: so if you have a tested hook, I'll include it into the next apport upload
<darkxst> pitti, I will write one, but not tonight, need to get back to painting
<darkxst> should be pretty straight forward though, so in the next day or so
<pitti> *od*
<pitti> err, *nod*
<alkisg> When an SRU is in the queue (specifically, update-manager in https://launchpad.net/ubuntu/precise/+queue?queue_state=1), is there something the reporter can do to speed up its review?
<pitti> alkisg: not formally; you can ask SRU team members on IRC perhaps; often queue processing isn't done for longer periods of time, and then some poor soul comes along and processes them all in a big batch
<alkisg> Thank you pitti... bdmurray, would you mind if I pinged you, since in the wiki it mentions your name for Thursdays? :-/
<sarnold> in the past I've done the verification-done steps for other bugs that the package upload was affecting..
<sarnold> granted, sometimes only the original reporter is in position to do that, but if you can reproduce the problem, it can help move things along; but I didn't see any outstanding verification-needed tags on the bugs
<alkisg> I think that part comes after the upload to -proposed and before the upload to -updates... Now we're before the -proposed step
<sarnold> ahh
<darkxst> alkisg, see https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<alkisg> darkxst, that's where I got bdmurray's name from :)
<darkxst> alkisg, its early there, wait until later!
<alkisg> Sure, np, thank you
<darkxst> pitti is only up since he some sort of time freak ;)
<sarnold> sure sign it's bed time when pitti joins :)
<alkisg> Haha, I got up at 01:30 today, I'm sure I beat him
<pitti> it's been a lot worse -- these days I sleep until 7!
<pitti> alkisg: eww -- local time?
 * alkisg wishes he could do that
<alkisg> pitti: yes, usually I wake up around 4, but I'm probably getting the flu...
<darkxst> pitti, 7 is a good time to wake up ;)
<pitti> fully agreed :)
<darkxst> should be much better than 5 or 6 you used to appear ;)
<pitti> I'm sure I'll go back to that in summer
<darkxst> is that all it is, too cold!
<pitti> too dark
<darkxst> opposite to my problem, too light to sleep in
<pitti> I guess that's due to being on opposite hemispheres :)
<darkxst> more a lack of blinds I think!
<pitti> oh yeah! great invention that
<darkxst> pitti, I have spent the last 3 months building this studio apartment but its still a WIP
<darkxst> don't to the final bits though
<darkxst> down even
<darkxst> hence no blinds!
<infinity> arges: No objections, was going to do it today.
<Noskcaj> How come python-click hasn't synced from unstable? It's got no ubuntu delta
<infinity> smoser: I don't speak (or use) virsh.  Which bit am I looking at?
<darkxst> infinity, will there be respins of trusty for -proposed bug>
<pitti> Noskcaj: it's a new package, that doesn't happen automatically
<infinity> smoser: "<topology sockets='1' cores='160' threads='1'/>" looks wrong, though.  Looks like you didn't disable SMT on the host.
<pitti> Noskcaj: do you need it?
<infinity> darkxst: We're not even remotely close to releasing today, proposed will be off before candidates happen.
<infinity> darkxst: By "not close to releasing today", I mean "we'll slip for a week, probably", but we haven't sorted a date yet, and thus not communicated it.
<darkxst> infinity, I have no clue what is happening since there seems to have been zero communication to the flavours ;(
<infinity> pitti: python-click was blacklisted by cjwatson, IIRC.
<darkxst> infinity, it would be nice to be kept in the loop!
<pitti> infinity: ah, to not potentially collide with our click source?
<infinity> darkxst: Right, I should have sent out a "we're delaying it, but not sure how long" email, I guess.
<infinity> pitti: Something like that.
<darkxst> I did expect delays given how late the lts stack landed, however seen nothing official
<infinity> Package: python3-click
<infinity> Source: click
<pitti> ah, heh
<pitti> here we are, two packages using common English words without a proper noun :)
<darkxst> infinity, all the flavours (probably) have their testers firing into action for a release tomorrow
<infinity> darkxst: Yeah, I should get a mail out ASAP.  I've mentioned the delay in passing on #-release, but not formally.  Sorry about that.
<darkxst> not that extra testing is a problem, but you know!
<darkxst> infinity, I may have seen comments hinting at that, but it wasn't concrete
<infinity> darkxst: Yeah, I didn't think anyone in the community would complain about having extra time, but obviously it sucks to *waste* your time, too.
<darkxst> I recall a 'might slip by a week, but I don't intend for that to happen?'
<infinity> darkxst: Oh, that was a couple weeks ago.  Reality and my intent didn't align, clearly. :P
<infinity> darkxst: Just landed the HWE stuff too late to have confidence in twiddling it all in place without error.
<darkxst> infinity, yes I noticed that, very clearly
<darkxst> and really I couldn't care if its delayed by however long, but these things need to be comminucated to the flavours QA teams
<darkxst> and not just in hints!
<slangasek> xnox: have you looked at how edk2 might be cross-buildable?  I haven't found the magic setting in the convoluted build system yet
<Noskcaj> pitti, I' m assuming it fixes the FTBFS
<pitti> Noskcaj: of what?
<Noskcaj> of python-click
<pitti> Noskcaj: we don't have that package in ubuntu at all
<Noskcaj> https://launchpad.net/ubuntu/+source/python-click
<Noskcaj> It says vivid-proposed
<pitti> Noskcaj: ah, and supposedly cjwatson blacklisted it afterwards, so I guess we should just remove it again
<slangasek> xnox: n/m, I seem to have figured it out... apparently you get to specify 'ARMGCC' if you want cross-build support ;P
<dholbach> good morning
<cjwatson> pitti,Noskcaj: I removed it, but I think I must have got unlucky with timing or something.  Removed again.  Not much to be done about it unless click is renamed
<flexiondotorg_> Trevinho, Are you about
<Trevinho> ehm? :o
<flexiondotorg_> Trevinho, Do you remember we spoke about me adding MATE support to Compiz?
<Trevinho> flexiondotorg_: yep
<flexiondotorg_> Trevinho, I've made a merge proposal.
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/compiz/compiz-mate/+merge/248684
<Trevinho> col
<Trevinho> cool
<flexiondotorg_> I'd really like to ship Ubuntu MATE 15.04 with Compiz.
<flexiondotorg_> But I realise feature freeze is fast approaching.
<flexiondotorg_> Any chance you'll have the time to review that?
<Trevinho> flexiondotorg_: I'm on it
<flexiondotorg_> Trevinho, I've been building a version of Compiz in my PPA, so it has been tested.
<flexiondotorg_> Trevinho, Thanks!
<Trevinho> flexiondotorg_: would be possible to share some of the code of the mate integration plugin with the gnome one?
<Trevinho> flexiondotorg_: so something like a private lib
<Trevinho> or even a plugin with gsettings stuff
<flexiondotorg_> Trevinho, possibly. You'd know better than me.
<flexiondotorg_> Trevinho, I just took the gnome stuff and adapted it. The only other thing I did was to remove Unity and HUD from the mate integration.
<flexiondotorg_> Trevinho, I'm travelling this week. And need to go to a conference now. But post here and I'll read the backlog.
<flexiondotorg_> Trevinho, Would is be possible to merge what I have now and then look to refactor it in a future merge proposal.
<tkamppeter> doko, it is about the new HPLIP package and the pointer warnings. Can this build error be overridden, as the code affected is only for memory card readers in VERY old HP inkjets. Printing, scanning, fax and all less than ~8 years old devices are not affected.
<cjwatson> No, the error can't be overridden.
<cjwatson> tkamppeter: ^-
<cjwatson> It's pretty much never hard to fix.
<cjwatson> You're probably just missing an #include <Python.h> or some such.
<Trevinho> flexiondotorg_: in case yes, hopin there's a future one :)
<arges> infinity: ok i'll let you practice your typing skills to sru-release those things.
<aeoril> I am working on Bug 1417978 <1417978@bugs.launchpad.net> I have verified that the bug no longer happens in today's daily build of vivid.  I the bug happens in trusty (14.4).  I need to see if it happens in utopic (14.10).  However, whenever I go look around at cdimage.ubuntu.com, I cannot seem to find any binaries for 14.10 for PC (just powerpc mac).  How do I find the x64 binary for
<aeoril> Utopic (14.10) to try this out on?
<ubottu> bug 1417978 in vim (Ubuntu) "vim improperly displaying text when loaded in gnome-terminal with altered geometry" [Undecided,New] https://launchpad.net/bugs/1417978
<aeoril> Noskcaj darkxst ^
<aeoril> Noskcaj darkxst I found it on the normal download page, but would still like to know where it is on cdimage.ubuntu.com
<Laney> aeoril: it's on releases.ubuntu.com
<aeoril> Laney Thanks!
<aeoril> Laney I guess I am "triaging" this bug I made - however, I have never done that before.  Noskcaj and darkxst were helping me.  I verified it works fine in vivid, and am now checking previous releases to see where it was fixed and if it needs to be backported.  Is that the right thing to do at this stage?  I believe that 14.04.1 is being updated to 14.04.2?  How do I find the daily build
<aeoril> for 14.04.2?  Or whatever the latest work on the update/upgrade to 14.04.1 is?
<aeoril> Laney also, I was thinking of getting the latest version of VIM to try on 14.04.1 to see if it works?
<aeoril> Laney also, I need someone to verify separately that it does not work as I say on 14.04.1/14.04?
<aeoril> (confirm)
<jdstrand> hallyn: ok, I think you are going to need to update /etc/apparmor.d/abstractions/libvirt-qemu to strip out the deny rules (or change the tmp dir and add new rules for it) in at least the setUp()s of the failing tests. test_CVE_2010_2239() did something similar conditional on karmic. This would have to be conditional on vivid and whatever SRUs this change went into
<bluefoxxx> Hello!
<bluefoxxx> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361954
<ubottu> Debian bug 361954 in wnpp "RFP: ossec-hids -- Host-based intrusion detection system" [Wishlist,Open]
<bluefoxxx> This stalled out in 2011, after good progress.
<bluefoxxx> I would like to see the ossec-hids packages in Ubuntu by 16.04 LTS, but that requires packaging in debian upstream.
<bluefoxxx> How do I file this on Launchpad?
<bluefoxxx> Do I file a bug, linking to Debian bug #361954?  Or is there some other process to follow?
<ubottu> Debian bug 361954 in wnpp "RFP: ossec-hids -- Host-based intrusion detection system" [Wishlist,Open] http://bugs.debian.org/361954
<bluefoxxx> ubottu is pretty smart
<ubottu> bluefoxxx: I am only a bot, please don't think I'm intelligent :)
<cjwatson> if it's done in Debian in time then it'll hit Ubuntu automatically
<cjwatson> it's not obvious what you gain by filing a Launchpad bug
<bluefoxxx> It stalled in 2011; it's not getting done unless someone with technical capability to finish and maintain it also has stake in finishing it
<hallyn> jdstrand: ok, thanks
<bdmurray> pitti: do you have any plans for a Vivid release of apport? I'd like to SRU the fix for bug 1084979.
<ubottu> bug 1084979 in apport (Ubuntu) "Submitting error report asks confounding questions" [Medium,Fix committed] https://launchpad.net/bugs/1084979
<xnox> infinity: yo, is C.UTF-8 thing an ubuntu one, or is it upstream now?
<xnox> what needs to be done to get it upstream? I'm interested to do that.
<infinity> xnox: It's Debian/Ubuntu, but we're sorting out how to make it upstreamable.
<infinity> xnox: Which probably needs a rewrite to make it not a separate locale.
<xnox> infinity: yeah, ideally it needs to be a "builtin" like C is.
<xnox> infinity: who is "we" in "we're" above?
<infinity> xnox: Me, Aurelien, and Carlos have discussed it off and on.
<infinity> xnox: What's your motivation?  Just being able to rely on it existing on all distros?
<xnox> infinity: in /my/ distro.
<infinity> xnox: Your distro being? :P
<xnox> infinity: let's pretend it's ubuntu.
<infinity> xnox: You're in luck, it's already in Ubuntu!
<xnox> infinity: not really, it's in ubuntu patches, i want it upstreamed.
<infinity> xnox: Anyhow, it'll never be backported to, say, RHEL7, but we're certainly working to have it uptreamed long before there's another RH. :P
<xnox> infinity: cause honestly using ubuntu's glibc patches on ubuntu would be crazy =)
<infinity> xnox: It's in Debian patches, not Ubuntu patches!
<xnox> infinity: potato
<infinity> potahto
<xnox> infinity: anyone, let me be your monkey, tell me what needs done to get it sorted into builtin "C.UTF8" given how littel i have touched of glibc codebase.
<xnox> s/anyone/anyway/
<infinity> xnox: I feel like telling you would be about as much time as writing the patch.
<xnox> infinity: sure, but without telling the design plan, it's never going to happen.
<xnox> like console-setup/initramfs-tools merge
 * xnox knows infinity better =)
<infinity> xnox: Did I just hear you volunteer to do the console-setup merge?
<infinity> xnox: slangasek will be thrilled to have it off his plate.
<xnox> infinity: tough chance, i've assigned that as a work item to steve to sort out.
<infinity> slangasek: ^ xnox wants to merge console-setup.
<slangasek> heh
<slangasek> infinity: but you wanted to review my partial merge :)
<xnox> it's a blocker to move systemd =)
<slangasek> xnox: I have the merge done but there are Ubuntu-specific installer integration bits that need forward-ported (the SKIP handling)
<infinity> Ahh, right.
<infinity> slangasek: Yes, I can review and sort those bits.
<xnox> slangasek: i can do installer changes.
<slangasek> lp:~vorlon/console-setup/1.108-merge-mach-2/
<xnox> slangasek: what needs doing?
<infinity> slangasek: This conversation is coming back to me now.
<slangasek> xnox: no, this is the changes to the installer bits within console-setup
<xnox> infinity: or will you?
<infinity> slangasek: That's... An impressive delta.
<slangasek> infinity: yeah.  mostly because of gratuitous changes on the Debian side :-P
<slangasek> but a lot of this stuff should clearly be getting upstreamed
<smoser> slangasek, if you get a chance could you take a quick look at bug https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1418568
<ubottu> Launchpad bug 1418568 in cloud-initramfs-tools (Ubuntu Precise) "depends on cloud-utils without knowledge of cloud-image-utils" [Medium,Confirmed]
<smoser> comment 1 should give you enough information... my question is if there is something i can do to the cloud-tools archive packages to make this work (ie, fix without SRU of cloud-init)
<slangasek> smoser: where does the cloud-image-utils package live? cloudarchive?
<smoser> yes. its just a backport of trusty level of cloud-utils
<slangasek> smoser: have you tried making cloud-image-utils in the cloud archive Conflicts/Replaces/Provides cloud-utils?
<smoser> well it does conflict
<slangasek> those weren't alternatives, I mean have you made it declare all three relationships on cloud-utils
<smoser> also note the other removal (cloud-intiramfs-growroot) which depends on cloud-guest-utils.
<smoser> cloud-utils from precise was later split into cloud-utils (meta package), cloud-guest-utils, cloud-image-utils
<slangasek> mm
<slangasek> is that cloud-utils metapackage also in the cloud archive?
<smoser> yes. but juju would like to declare the smaller dependency chain in cloud-image-utils in later releases.
<slangasek> yes but that shouldn't matter
<smoser> no? its juju's request to install cloud-image-utils that causes the problem.
<slangasek> installing cloud-image-utils from the cloud archive should pull in the cloud-utils package from the cloud archive, not remove the one from the main archive; unless the cloud-utils/cloud-image-utils relationships are buggy
<smoser> hm.. maybe the dependencies are buggy.
<slangasek> smoser: your cloud-image-utils/cloud-guest-utils should declare Breaks: + Replaces: for this case, not Conflicts:
<slangasek> if you fix that, you /should/ get the desired results
<slangasek> but see the advice in policy about not having versioned conflicts
<smoser> ok. thanks. i'll look at that.
<smoser> slangasek, http://paste.ubuntu.com/10075299/ thats the debian/control of cloud-utils in trusty (which would go back to cloud archive)
<slangasek> smoser: Breaks/Replaces, *not* Conflicts/Replaces
<smoser> yeah. thanks. i'll test.
<xnox> didrocks: transient presets are on the mailing list.
<xnox> didrocks: for the time being i'm not interested in /dev/null symlinks.
<xnox> diddledan: as one can do "echo disable foo.service" >> /etc/systemd/system-preset-transient/00-local.preset
<xnox> didrocks: to override the "distro" transient-presets.
<xnox> diddledan: unping
<didrocks> xnox: seen that, I saw that you didn't really wanted to send it yourself first before I discussed it on the ML
<didrocks> xnox: as I spent quite some hours with various people to discuss solutions
<didrocks> let's see, I hope that's not going to put some issues for the debian integration
<didrocks> but that's just not really cool, as I warned you at the sprint already about thisâ¦
<xnox> didrocks: it is very generic thing, disabled by default, and has a lot of room to be improved/modified.
<xnox> or semantics changed.
<xnox> didrocks: in a sense this is first prototype one can start playing around with.
<didrocks> yeah, let's see, I'll review it on the upstream ML, I'm just done with the fsck thingy
<didrocks> implementing plymouth protocole manually btw
<xnox> cool.
<xnox> didrocks: well, we'll see what happens. I've tried to make the cover letter sound very open-ended and point out that this is not yet complete solution.
<xnox> complete solution, for anyone, that is.
<didrocks> xnox: just weird that you didn't mention that it was based on what we discussed as a comity during the hackfest
<didrocks> but ok
<didrocks> committee*
<xnox> didrocks: i did mention hackfest.
<xnox> no idea what a "comity" is.
<barry> smoser: any status on py3 cloud-init?
<smoser> its on the todo list.
<smoser> i did some owrk on the non-python parts that you hadnt touched.
<smoser> i'll work some more today on it.
<barry> smoser: sounds good, thanks
<bdmurray> cjwatson: is there any way to manually resolve Contents.gz being out of date when we encounter bug 1384797?
<ubottu> bug 1384797 in Launchpad itself "Contents generation races with publisher" [Low,Triaged] https://launchpad.net/bugs/1384797
<cjwatson> nothing really apart from fixing that bug
<cjwatson> I did get started on that a while back but haven't had the time to finish - I was up to http://paste.ubuntu.com/10076288/, don't remember the state in detail
<cjwatson> if I get time away from huge test suite of hugeness tomorrow I'll see if I can get back to that
<bdmurray> cjwatson: okay, thanks
<ki7rw> i'm just curious as to what's the difference between lm-sensors4 and lm-sensors? sensors-detect doesn't work until i install lm-sensors (lm-sensors4 was previously installed) - ubuntu 14.04 64 bit
<tjaalton> smoser: hey, commented #1418568 since it needs the sru header ;)
<tjaalton> so if you're available to do that now then we can accept the upload
<smoser> tjaalton, sweet. i will do that quickly.
<tjaalton> cool
<smoser> tjaalton, done
<smoser> thank you!
<tjaalton> thx :)
<hallyn> hi - bug 1418664 , what usually causes the error message "package is in a very bad inconsistent state;" ?
<ubottu> bug 1418664 in cgmanager (Ubuntu) "package cgmanager 0.32-4ubuntu1 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Critical,Incomplete] https://launchpad.net/bugs/1418664
<mihok> I'm having trouble getting blah.links to do.. anything? I thought once I packaged the folder in .deb it would automagically create symlinks for my package when installed?
<mihok> also some tutorials show use of a debian/ folder, others show DEBIAN/, which is correct?
<tarpman> mihok: debian/ is in the source package and you maintain it; DEBIAN/ is in the binary packages and is (typically) generated by the build tools
<mihok> tarpman, ah thanks, what if my binary is really just a bash script?
<tarpman> mihok: sorry, I don't understand the question
<cjwatson> then that just means you skip the "compile stuff" step
<cjwatson> you still have a source package and a binary package
<mihok> ah
<cjwatson> blah.links is used by dh_link; ideally you're just using the short dh form based on /usr/share/doc/debhelper/examples/rules.tiny, which will run all the standard tools for you
<cjwatson> I highly recommend reading the various debhelper man pages, they're very good
<cjwatson> if you see any tutorial that spends any meaningful amount of time talking about DEBIAN/, discard it immediately and read something else
<mihok> ah really
<cjwatson> it's occasionally worthwhile to explain the internals of binary package building, but not in the context of a "how to package stuff" tutorial, and it's a good sign that the author is either rambling on about stuff you don't need to know, or is themselves terminally confused
<mihok> I was assuming you could skip the 'source' step and just have it in binary form
<cjwatson> in principle yes; in practice it's making trouble for yourself
<mihok> right
<mihok> makes sense, thanks
<cjwatson> (there are lots and lots of "source" packages that consist only of interpreted code; but the source package format is still the one you want to use for version control, it lets you use the various tools for producing decent-quality binary packages with minimal effort, etc.)
<mihok> off hand do you know of any tutorials that go through the whole process well? ive been finding some random ones that arent that good and going through the ubuntu packaging guide
<cjwatson> the Ubuntu packaging guide is ok; https://wiki.debian.org/IntroDebianPackaging (less detailed) and https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf (more detailed, arguably too much) are decent too
<cjwatson> though I'm afraid it's 15 years since I used a tutorial myself so I'm not sure I'm the best person to answer :)
<mihok> no worries, thanks for your help though!
<cjwatson> you could also take the approach of finding a simple package with a similar kind of structure
<cjwatson> and apt-get source that and use it as a baseline
<cjwatson> one of my own (not so much blowing my own trumpet, as this way I know what I'm suggesting) is "madison-lite", which is just a perl script (but the perl/shell distinction doesn't matter here except for a couple of extra entries in Depends) plus man page plus examples
<mihok> oh cool I didnt know you could do that
<cjwatson> so if that helps at all then feel free
 * cjwatson -> pub
<cjwatson> people here or on #ubuntu-packaging are likely willing to review a source package if it's stuck up on the internet somewhere, too
<darkxst> aeoril, to backport the fix to 14.10 or 14.04 you would need to find the actual commit that fixed
<aeoril> darkxst how would one do that? Trial and error?
<darkxst> aeoril, search upstream bugtracker
<darkxst> maybe search upstream git logs or whatever VCS they use
<aeoril> darkxst I still need to verify vim was the problem, and not gnome-terminal or whatever ...
<darkxst> as a last resort you could run a bisect
<aeoril> darkxst I already talked with a guy over at #vim and he said they don't really have a bug tracking system
#ubuntu-devel 2015-02-06
<darkxst> aeoril, you could build vivid vim and try run that in 14.10
<darkxst> or test with gnome-terminal from gnome3-staging ppa
<darkxst> against standard 14.10 vim
<aeoril> darkxst vivid vim works, so that is exactly what I was thinking - just shortcut to the vivid vim and if it solves the problem
<aeoril> If not, try gnome-terminal as you suggested
<aeoril> darkxst how do I find the build source for the vivid vim?
<aeoril> is it in launchpad?
<aeoril> (bazaar)
<darkxst> pull-lp-source vim vivid
<aeoril> pull-lp-source is an actual command at the command line?
<darkxst> yes
<aeoril> cool - that makes it easy!
<darkxst> in ubuntu-dev-tools package
<aeoril> gotcha - still gotta install those, but there is a developer wiki for that
<aeoril> (to set up my build environment)
<aeoril> darkxst doesn't someone need to independently verify the bug also?
<aeoril> (confirm?)
<aeoril> darkst how do I pull and build gnome-terminal from the ppa?
<aeoril> pull-lp-source vivid gnome-terminal?
<darkxst> aeoril, you would need to install the whole ppa probably, it needs gtk3.14 and an update libvte compared to 3.14
<aeoril> ok, how do I install a ppa?  I can google that if it is involved
<aeoril> (maybe I need to go through the beginner developer tutorial and steps at this point ...) darkxst
<sarnold> apt-add-repository lp:.... ought to take care of much of it for you
<darkxst> aeoril, there are instuctions at the top of any ppa's web page
<aeoril> darkxst cool, I think I can take it from here
<aeoril> sarnold cool, thanks!
<aeoril> sarnold darkxst will installing the gnome-terminal ppa package update gtk3.14 and libvte systemwide?  e.g., do I need to do it on a test virtual machine that I can throw away after figuring out this bug because it will not be plain vanilla 14.4.1 anymore?
<sarnold> aeoril: whatever packages in the ppa have higher version numbers than ones on your system will replace the system ones with the next apt-get update -- unless you go to some efforts to pin package versions.
<sarnold> aeoril: VM would be best -- I know that might make it harder to reproduce the problem, though, your issue feels like a racy thing that might be harder (or easier?) to reproduce in  VM
<darkxst> aeoril, it will update most of GNOME to 3.14, maybe safer to do it in a VM
<aeoril> sarnold ok, I'll make a new vm so I can screw around without any worries
<aeoril> sarnold it happens equally and very reproducably on a vm in VMWare, Hyper-V and on my 14.04 regular Ubuntu install
<sarnold> yay :)
<aeoril> sarnold it happens *rarely* on 14.10, but it did happen twice - much less reproducable on 14.04.  It has never happened on my 15.04 vm after many tries
<aeoril> sarnold no kidding!
<aeoril> much less reproducable on *than* on 15.04* (misworded)
<aeoril> whoops, screwed up the fix - "*than* on 14.04*" :(
<sarnold> aha :) I'm glad it's easily reproducable in vms, that makes it far easier to deal with :)
<aeoril> yes, this particular problem does not seem to care about vms
<aeoril> what do you guys do if vms fail to reproduce problems on bare metal machines?  Dual boots, quad boots, etc?
<aeoril> (not sure how many different versions of Ubuntu you can have as alternate boots)
<aeoril> I have read about chroot ...
<darkxst> aeoril, for GNOME bugs there is jhbuild which is handy
<aeoril> sarnold I am also glad it has *never* happened (so far) on 15.04 - I probably need to try it out a bunch more times though to make sure because 14.10 is pretty rare ...
<aeoril> darkxst ok, I am writing down all this as I get it here so I can remember
<aeoril> sarnold darkxst if I find that vivid vim works on 14.04/14.10, can we just use vivid vim for the backport?
<aeoril> vivid's vim version*
<darkxst> aeoril, no, only bug-fix only releases can be bugported to a stable release
<aeoril> ahhh, ok - so I would have to see if the latest bug-fix only release of vim in launchpad fixes the problem, and use it if it does?
<aeoril> darkxst ^
<darkxst> aeoril, vim doesnt really seem to do proper releases
<aeoril> darkxst I was just thinking that - the guy on #vim said their release/bug versioning was a mess ... or really not existant ...
<darkxst> in which case you would want to backport the one patch that fixes the problem
<aeoril> darkxst hmmm ... sounds difficult and laborious to find the individual patch I guess ...
<darkxst> sometimes, often its pretty easy though
<aeoril> darkxst oh, ok - that is good to know
<darkxst> but first determine if its gnome-terminal or vim
<aeoril> darkxst I was just exploring while I had you available
<aeoril> darkxst what about confirmation from someone else?  What if the bug is somehow in my personal hardware/software setup?  Probably not, since two different machines do it, one normal install the other vms under Win 8.1, very different hardware darkxst
<darkxst> you don't necessaraily need confirmation from someone else, especially if you can reproduce in clean installs on different  hardware
<darkxst> atleast not at this stage
<aeoril> darkxst yes, clean installs on all vms, and on the regular machine as well
<aeoril> darkxst well, gotta knock off for a while - I'll try to get back to it tonight.  Thanks!
<aeoril> sarnold thank you as well!
<aeoril> darkxst you still there?  I am back and firing up a new vm with 14.04.1 to test vim and/or gnome.  I'll let you know how it goes.  Thanks.
<aeoril> sarnold ^
<sarnold> hey aeoril :)
<aeoril> sarnold hey - I am back and starting to work on the steps outlined by you and darkxst for the vim/gnome-terminal bug
<sarnold> aeoril: nice, happy hunting :)
<aeoril> sarnold This is fun!
<aeoril> yah, this is totally cool ... :)
<aeoril> sarnold I am just glad I can use vms!  SOOOO much easier, I hope!
<aeoril> vms are just tooooo easy - almost makes you feel guilty or something!
<aeoril> I am sure they can also be problematic for many scenarios, though ...
<aeoril> sarnold something actually cool - I built my machine to run lots of vms for various scenarios, this one included, so I have 32GB memory, so can have lots of vms running with lots of memory and just switch easily
<sarnold> aeoril: ooh yeah, 32 gigs is a lot of breathing room :)
<sarnold> especially since VMs typically can get away with less ram themselves -- their backing block devices are cached by the host, too
<aeoril> sarnold yah, the guys on #hardware thought I was an idiot to do it, but it has already proved its worth.  I have 12GB used right now with 4 vms running simulataneously, 19GB still free!
<aeoril> It is very convenient and easy to switch to various running configurations ...
<aeoril> sarnold vmware says it uses 768MB for the video card by default, more if you choose
<sarnold> aeoril: hah, fancy. I always use kvm and it has the lowest of low-end video cards; most of the time I just ssh in. heh. that might not work so well for your problem though...
<aeoril> sarnold the hardware was pretty cheap though really, and the software is all free, so ...
<sarnold> aeoril: pretty amazing, right? my first PC had 4 megabytes RAM..
<aeoril> sarnold my first pc had 4K!
<aeoril> lol
<sarnold> aeoril: PC? :)
<aeoril> Apple II ...
<sarnold> hehe
<aeoril> My XT had 640K - and a hard drive!
<aeoril> oh, maybe 1GB, but 640 usable, other stuff was reserved, I think
<sarnold> "640k ought to be enough for anyone" :)
<aeoril> sarnold yes, there was a guy at my old place of work that had that in his signature
<aeoril> sarnold darkxst how do I install this?  I tried sudo apt-get install ncurses but it did not work (not found):  https://launchpad.net/ubuntu/+source/ncurses
<aeoril> sarnold darkxst ./configure for vim needs it ...
<sarnold> aeoril: it probably needs libncurses5-dev -- but a neat thing is apt-get build-dep -- it'll install all the packages needed to build a specific package
<sarnold> aeoril: (of course, better is to use a tool like sbuild to make repeatable builds that don't require installing new packages in your 'main' system -- but I assume you're doing the development on the VM, where it doesn't matter)
<aeoril> sarnold yes, vm
<aeoril> sarnold not sure how to use apt-get build-dep ...
<sarnold> aeoril: try: apt-get build-dep vim
<aeoril> sarnold I downloaded the vivid version of the vim source from lp - will apt-get build-dep vim still be ok for that?  I am on a 14.04.1 trying to build the vivid version of vim to test it on a 14.04.1 system ...
<sarnold> aeoril: it'll get close most of the time
<aeoril> sarnold I did this: pull-lp-source vim vivid
<aeoril> sarnold this seems gunky - maybe I should use sbuild?
<sarnold> aeoril: I wouldn't bother yet, faster iteration is probably more important at this point
<aeoril> yes, sbuild seems involved ...
<aeoril> sarnold making, thanks ...
<sarnold> woo
<aeoril> sarnold sssswwwwweeeeeettt!  That appeared to fix it!  Ran vim out of the temp directory from build, no problems, reran vim from normal spot, crapped out as usual!
<Unit193> Heh, what can I say?  I use pbuilder. :P
<sarnold> aeoril: oh good, now you get to figure out what changed :)
<aeoril> sarnold lol there lies the rub!
<aeoril> sarnold should I do something to the bug report at this point?
<sarnold> aeoril: probably not, not much to be done yet
<aeoril> this is still pretty cool ...
<aeoril> sarnold so now I have to put on my developer hat? lol
<sarnold> aeoril: you may have success bisecting their revision control, if they've got public trees..
<aeoril> sarnold they've got public trees, but the revision control apparently sucks ... they use mercurial and the guy on #vim said that the revision control is a mess
<aeoril> sarnold I think it is safe to say we have at least narrowed it down to a vim problem ...
<darkxst> aeoril, bisecting would still find the commit
<darkxst> regardless of how messy it is
<sarnold> I'm seeing lots of checkins per day; it might not be ideal, but it's liable to give small enough checkins that'd it be useful
<sarnold> I was afraid it was going to be tarball imports or something else fairly .. ghetto
<aeoril> darkxst sarnold can I do anything with the lp source code instead?
<aeoril> bisect on Ubuntu lp source/patches or whatever?
<sarnold> aeoril: no :(
<aeoril> sarnold how did you see their source code history?  Do you have mercurial and fetched their source code and looked at the commits in your local repo you fetched?
<sarnold> aeoril: https://code.google.com/p/vim/source/list
 * sarnold <-- lazy
<aeoril> sarnold looks like they have issues tracked though
<sarnold> aeoril: yeah, if you can find an issue, so much the better :)
<aeoril> sarnold lots of issues ...
<sarnold> I'm not surprised, they support a lot of crazy platforms
<aeoril> sarnold like Windows?
<darkxst> aeoril, I think a bisect would be your best bet here
<aeoril> darkxst yes, I think so
<darkxst> probably quicker than trawling through undescriptive commit messages!
<aeoril> darkxst quick search on issues found nothing, lots of commits
<aeoril> sarnold darkxst so, I guess once I download the latest source repo, I just checkout commits bisecting from my local repo, bisecting dates, until I hit the right commit?
<aeoril> s/right commit/commit that fixes the problem/
<darkxst> vcs should provide a bisect command (never tried in mercurial though)
<aeoril> darkxst ok, that would be better then (much)
<darkxst> don't try and do it manually!
<darkxst> atleast with git bisect, you provide the last know bad commit and then a known good commit
<darkxst> git chooses the commits to checkout and you tell it if each one was good or broken
<darkxst> it would be a similar concept for mercurial
<aeoril> http://www.selenic.com/hg/help/bisect :)
<sarnold> hg does have a bisect sub-command, but I have no idea how you tell it success / failure; if it works, it'll be awesome...
<aeoril> sarnold ^
<darkxst> or there is a git mirror of vim on github -> https://github.com/vim-jp/vim/commit/f69eb7659a7bf4a586c569ae63fc2cc6ad364710
<sarnold> :)
<aeoril> darkxst oh, that is good to know - which do you suggest I use?
<darkxst> probably git, given I know it works!
<aeoril> lol ok, I would rather use git!
<aeoril> darkxst sarnold wow, this is really cool - I am learning a lot rapidly ...
<aeoril> Your help is immensely cool and appreciated ...
<aeoril> darkxst sarnold I think I have lucked out with my first bug being relatively easy, at least so far (I know, famous last words ...)
<sarnold> hah, normally terminal bugs don't get called "easy" :)
<aeoril> sarnold terminal bugs?
<aeoril> you mean terminal as in gnome-terminal?
<sarnold> aeoril: anything involving ncurses, terminfo, terminals...
<darkxst> aeoril, and you haven't found the solution just yet
<aeoril> sarnold well, i said "so far" ...
<sarnold> you might fix gnome-terminal but break xterm, rxvt, urxvt, aterm, wterm, Eterm, konsole, or the virtual terminals...
<aeoril> I am an optimist!
<sarnold> :)
<aeoril> ahhh, I see ... right, didn't even think about that ...
<aeoril> I am just a babe in the woods!
<aeoril> Ready for the wolves to start circling!
<aeoril> lol
<sarnold> it's a good start though, the best way to get involved is to fix a bug that annoys you :) once you've gotten started, future problems will seem that much easier..
<aeoril> sarnold yes, I am learning a lot - the funny thing is, with this particular bug, I just realized using screen I don't need to mess with the problem behavior, but it is good to learn on I guess
<aeoril> screen or tmux
<sarnold> aeoril: hah :) but similarly, gnome-terminal --geom .... -c "screen -e vim ..." is a bit much just to get a working vim in terminal.
<aeoril> sarnold well, I have them as scripts, so "pup vi .bashrc" means "pop up a new gnome terminal sized per the script and run vi in it on .bashrc"
<aeoril> So, pup <something> becomes useful for a variety of things
<aeoril> sarnold can you think of a better way?
<aeoril> sarnold well, I think tmux or screen are the best ways
<sarnold> aeoril: tmux / screen would do it fine, but you're already on this path, might as well keep going :)
<aeoril> sarnold yes, I am going to try to complete this bug fix
<sarnold> sweet
<darkxst> aeoril, get bisecting then ;)
<aeoril> darkxst not tonight - already late - tomorrow ... :)
<sarnold> indeed, goodnight aeoril, darkxst :)
<aeoril> sarnold night~
<darkxst> aeoril, night
<aeoril> night, darkxst ~
<pitti> Good morning
<pitti> bdmurray: yes, I'll do one today, I got darkxst' wayland hook
<darkxst> hey pitti
<darkxst> also bug 1418766
<ubottu> bug 1418766 in apport (Ubuntu) "ubuntu-bug launches in CLI mode under wayland session" [Undecided,New] https://launchpad.net/bugs/1418766
<pitti> darkxst: do our GTK packages have native wayland support, or do we need to explicitly check for xwayland?
<pitti> darkxst: because, under xwayland you ought to have $DISPLAY?
<pitti> [ ! -z "$DISPLAY" -o -z "$WAYLAND_DISPLAY"]
<pitti> ITYM -a there (will fix when merging)
<pitti> oh, and why the ! ?
<darkxst> pitti, initially when you launch you only have $WAYLAND_DISPLAY, I think you won't get into XWAYLAND until gtk is initialized
<pitti> darkxst: I mean, will GTK work without xwayland too?
<pitti> darkxst: i. e. does GTK have native wayland support in our packages?
<pitti> darkxst: if not, we need to check [ -n $WAYLAND_DISPLAY ] && (xwayland installed)
<darkxst> pitti, GTK does have native wayland support, however apport isnt completely safe yet due to the couple of GdkX11 calls
<darkxst> only core stuff is running native wayland by default
<darkxst> and Xwayland gets installed with the session, so it wouldnt be possible to have WAYLAND_DISPLAY set and xwayland not installed
<darkxst> and right that expression isn't quite right
<pitti> darkxst: ah, ok; so existance of $WAYLAND_DISPLAY implies xwayland is present?
<darkxst> I guess [ -z "$DISPLAY" -a -z "$WAYLAND_DISPLAY"] is right
<darkxst> pitti, atleast on GNOME
<darkxst> maybe not for weston
<darkxst> I guess it wouldnt hurt to check if installed
<pitti> darkxst: http://paste.ubuntu.com/10087059/ ?
<darkxst> pitti, yep looks good to me
<darkxst> pitti, and its really only set_modal_for() that would break under native wayland, although I don't think there an equivalent of that implemented in wayland yet
<pitti> darkxst: ah, perhaps we could more gracefully intercept that failure, and just not make it modal then?
<dholbach> good morning
<pitti> hey dholbach!
<dholbach> hi pitti
<darkxst> pitti, right, should be simple enough but for 3.14 normal GTK apps all default to Xwayland unless the user forces things with GDK_BACKEND
<darkxst> no probably not too urgent
<darkxst> s/no/so/
<darkxst> pitti, and I actually don't know how to check for that in python/introspection, atleast in C its GDK_IS_X11_DISPLAY()
<pitti> darkxst: do you have a way to quickly test apport-gtk under native wayland?
<darkxst> pitti, yes
<pitti> darkxst: ok, so ATM this crashes on the Gdk bits; do you have a backtrace?
<pitti> darkxst: I need to know what/where to intercept, to skip the set_modal_for bits
<pitti> darkxst: I suppose Wnck also wouldn't work under wayland
<darkxst> pitti, actually it doesnt crash but it probably should
<pitti> darkxst: ah, so what happens?
<darkxst> am getting an "Error: no display specified" though
<pitti> darkxst: something like http://paste.ubuntu.com/10087376/ should be enough, if the actual imports work
<darkxst> pitti, yes seems so
<pitti> darkxst: great, thanks for testing; committing that then
<darkxst> gah, still
<darkxst> getting no dispay specified errors after clicking send though
<darkxst> even in Xwayland
<darkxst> seems like the browser call fails since there is no DISPLAY set
<pitti> darkxst: ah, that's from xdg-open?
<darkxst> pitti, yes
<darkxst> pitti, xdg-open really needs a $DISPLAY
<pitti> darkxst: ah, so that one also needs to be fixed for wayland then
<darkxst> pitti, yeh looks like it
<darkxst> pitti, by why doesnt the try catch the failure and fall back to webbrowser?
<darkxst> I suppose it considers the subprocess.call successful?
<darkxst> but it shoudn't right?
<darkxst> or xdg-open isnt returning proper exit codes?
<pitti> darkxst: I suppose xdg-open erroneously returns 0?
<darkxst> pitti, yep it does
<darkxst> pitti, or its really coming from firefox ;(
<pitti> darkxst: does ffox actually work under wayland?
<pitti> it's still GTK 2
<darkxst> pitti, seems it works under Xwayland, but only when $DISPLAY is set
<alkisg> slangasek: good morning, could I ping you about putting an update-manager SRU in precise-proposed, if you happen to have some time today?  https://launchpad.net/ubuntu/precise/+queue?queue_state=1 and https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<slangasek> alkisg: several of the bugs fixed in this upload are still waiting for the information required by the SRU process
<alkisg> slangasek:  ah sorry I didn't realize that, I thought mvo had only uploaded one particular bug I'd reported...
 * alkisg as at a loss on how to help with that sru now
<alkisg> Split my own bug in a different SRU? Help in the other bug reports that are in the same upload?
<slangasek> alkisg: filling out the other SRU bugs with the required information would be a good idea
<alkisg> slangasek: thanks, I hope I'll be able to find test cases for them... E.g. "install ubuntu 12.04.4" doesn't sound so quick...
 * alkisg tries
<pitti> bdmurray: uploaded now
<slangasek> alkisg: test cases aren't required to be quick, but correct
<alkisg> slangasek: I'll obviously need to do the verification-done step afterwards too though, for 3 bugs that didn't get enough attention from their reporters...
<alkisg> It's a bit unfair for me, considering I reported another bug :)
<alkisg> I'd prefer it if it was possible to upload an SRU with just my bug fix, but OK I understand the deal
<alkisg> I'll try to give all the appropriate feedback for the other bug reports
<slangasek> alkisg: then you can talk to the uploader (mvo?)
<slangasek> alkisg: talk to him about a reupload without the other changes
<alkisg> slangasek: yes, I understand, but of course it'll be more burden for mvo then. I'll see first if I can easily do the SRU steps for the other bug reports.
<alkisg> Hmm I think I'll try pinging the reporters as a first step :)
<mpt> Help, Iâm trying to push an Ubuntu packaging bug fix but Launchpad wonât let me
<mpt>  ð 09:19:58@libnotify> bzr push lp:~mpt/libnotify/533631-timeout-doc
<mpt> bzr: ERROR: Permission denied: "~mpt/libnotify/533631-timeout-doc/": : Project 'libnotify' does not exist.
<mpt>  ð  09:20:21@libnotify> bzr push lp:~mpt/ubuntu/libnotify/533631-timeout-doc
<mpt> bzr: ERROR: Invalid url supplied to transport: "lp:~mpt/ubuntu/libnotify/533631-timeout-doc": No such distribution series libnotify.
<mpt> I got the branch from lp:ubuntu/libnotify, so why canât I push to lp:~mpt/ubuntu/libnotify?
<mpt> Do I need to specify vivid/?
<mvo> slangasek, alkisg: I look at this, in a call right now
<Odd_Bloke> mpt: I think I have done so in the past.
<seb128> slangasek, hey, what's the status of systemd by default? ;-)
<ogra_> mpt, perhaps it gets confused by all the smileys :)
<alkisg> ð
<cjwatson> mpt: The namespace for personal source package branches is lp:~OWNER/DISTRIBUTION/DISTROSERIES/SOURCE/BRANCHNAME
<cjwatson> mpt: so yes, you must include vivid/
<mpt> Ok, that works. Thanks Odd_Bloke, cjwatson
<darkxst> pitti, changelog had me a little worried for a sec "Also check for $WAYLAND_SESSION"
<darkxst> but the code is ok!
<mpt> ogra_, I set that up as an easy way to tell whether the last command succeeded or failed :-) (Only bzr diff messes it up)
<cjwatson> Plain "diff" does the same
<cjwatson> Interestingly, "git diff" doesn't
<cjwatson> Ah, you have to say --exit-code if you want diff-style exit codes
<cjwatson> Shocking, I think that's actually a good UI design decision by git
<mpt> Human sacrifice â¦ cats and dogs living together â¦ mass hysteria â¦ and good UI decisions in Git
<pitti> darkxst: ah, should I have described that differently?
<darkxst> pitti, wayland session or  $WAYLAND_SESSIO
<darkxst> $WAYLAND_DESKTOP
<darkxst> cut and paste fail there
<ogra_> $WAYLAND_WAY
<darkxst> DISPLAY
<ogra_> :)
<pitti> darkxst: ah, you mean _DISPLAY instead of _SESSION; fixed in NEWS in bzr
<darkxst> pitti, yes exactly
<pitti> (and fixed on https://launchpad.net/apport/trunk/2.16)
<darkxst> ta
<pitti> jdstrand: I'd like to point out bug 1418928
<ubottu> bug 1418928 in postgresql-9.4 (Ubuntu Utopic) "New upstream microreleases 9.1.15, 9.3.6, 9.4.1" [Undecided,In progress] https://launchpad.net/bugs/1418928
<jdstrand> pitti: thanks!
<jdstrand> tyhicks: fyi ^
<pitti> jdstrand: ah, should I ping tyhicks in the future about security updates?
<jdstrand> pitti: either is fine, but typically, yes
<zul> mterry:  ping can you have a look at the  libxml-xpath-perl MIR please
<smoser> :)
<zul> mterry:  its blocking libvirt
<Bluefoxicy> sigh
<Bluefoxicy> why does every Linux distro install a 200MB /boot?
<Bluefoxicy> before you know it, you've got three kernel images installed somehow, and /boot is full
<cyphermox> flexiondotorg_: how far how we for reviewing your packages? are you still looking for a second reviewer?
<aeoril> darkxst I am looking at github.  I found two mirrors of google mercurial vim.  One is outdated, the other is vim-jp.  How do I know I can trust these mirrors?
<aeoril> darkxst is there a way to do a checksum or something on a commit?
<darkxst> aeoril, it would just be an autosync repo, should be fine
<aeoril> darkxst I wonder why one of the mirror repos is not up to date though?  That is what got me thinking ...
<darkxst> not sure you can checksum, both git and mercurial hash commits differently
<aeoril> darkxst https://github.com/b4winckler/vim
<aeoril> darkxst yes, I see - good point ...
<darkxst> idk, autosync can break from time to time I guess
<aeoril> darkxst oh well, I will start bisecting on the japanese github mirror repo ...
<darkxst> aeoril, ok
<aeoril> darkxst what is the best way to figure out the starting/ending commits in the github vim repo based on the lp versions that are in the ubuntu builds?
<aeoril> for the bisection
<sarnold> easiest is probably to just select one at random from two years ago and the most recent
<sarnold> you'll cut off half of them with the third test right in the middle, so there isn't too much reason to optimize finding the first and last ones to work with :)
<aeoril> sarnold I feel like I am asking too many dumb questions ... I don't see anyone else doing so ...
<sarnold> aeoril: ask away :)
<darkxst> aeoril, though don't go back to far, if this used to work pre trusty
<darkxst> I would start with first 7.4 commit
<aeoril> darkxst sarnold Viewing the trusty revision history, the last revision for release is 57 dated 2010-03-08: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/vim/trusty/changes/57
<aeoril> darkxst sarnold wouldn't I just choose that date as a good approximation?  But that is almost 5 years ago ...
<sarnold> aeoril: I have no idea what that ubuntu-branches thing is..
<aeoril> then, choose the latest and go from there?
<aeoril> sarnold really?
<sarnold> aeoril: yeah :) I don't think I've seen it before. and 2010 was a looooong time ago. I assume it's a process that predates my involvement.
<darkxst> sarnold that is the packaging revisions
<darkxst> nothing to do with vim commits
<sarnold> aeoril: from this thing you can see that trusty shipped with a 7.4.052-based package: https://launchpad.net/ubuntu/+source/vim
<aeoril> sarnold darkxst I got to it from here:  https://code.launchpad.net/ubuntu/+source/vim
<aeoril> sarnold lol ok - same link!
<darkxst> aeoril, really just start at 'v7-4'
<aeoril> darkxst I am just looking around, trying to learn ... sorry if I am asking too many questions ...
<aeoril> darkxst where do you see the info that it was v7-4?  I am clicking around and do not see that
<darkxst> its a tag
<darkxst> aeoril, you should just be able to run git bisect v7-4
<darkxst> ^insert bad though
<aeoril> darkxst sarnold oh, I was under the code section on launchpad - I see the tag now
<aeoril> (launchpad for vim)
<darkxst> aeoril, go to your git tree! launchpad is just confusing you!
<FOSS_drivers_FTW> Hello
<FOSS_drivers_FTW> is there any reason why xserver-xorg-video-ati is still at 7.4.0 in vivid?
<FOSS_drivers_FTW> see:
<FOSS_drivers_FTW> http://packages.ubuntu.com/vivid/xserver-xorg-video-ati
<FOSS_drivers_FTW> Debian already has 7.5.0, see:
<FOSS_drivers_FTW> https://packages.debian.org/search?keywords=xserver-xorg-video-ati&searchon=names&suite=all&section=all
<FOSS_drivers_FTW> 7.5.0 is the latest version, see:
<FOSS_drivers_FTW> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
<FOSS_drivers_FTW> so, is there any reason why vivid is still using an old version? why hasn't the latest version been imported from Debian?
<aeoril> sarnold darkxst please bear with me - I am trying to understand.  I see on the launchpad site (https://launchpad.net/ubuntu/+source/vim) a line next below "The Trusty Tahr" that says "2:7.4.052-1ubuntu3" ... "release (main)" ... "2014-01-02" - what exactly do those three things mean there? (the version, release(main) and date)?
<darkxst> aeoril, 7.4.052 was the upstream version
<darkxst> -1ubuntu3 is the ubuntu version
<darkxst> the rest doesnt matter
<aeoril> what is the 2:?
<darkxst> an epoch
<darkxst> part of ubuntu version also
<darkxst>  7.4.052 is the bit you wanted to know I suspect
<darkxst> aeoril, go to your git tree
<darkxst> git bisect start
<darkxst> git bisect bad v7-4
<darkxst> git bisect good
<darkxst> then start building!
<aeoril> darkxst ok, thanks - but still learning here - give a man a fish, feed him for a day, teach a man to fish, feed him his whole life ... :)
<darkxst> aeoril, and 'man git bisect' will give you even better instructions
<aeoril> ok, cool - thanks
<sarnold> heh, every time I need git manpages I always think of http://git-man-page-generator.lokaltog.net/
<darkxst> aeoril, most of the git man pages have nice simple examples
<aeoril> darkxst so, to find out I needed to start "bad" at 7-4, you looked at the launchpad page at that 7-4-52 and figured "spitball at 7-4?"
<aeoril> darkxst or, did you just go by the date of the trusty release as a rough estimate?
<darkxst> first
<aeoril> I noticed precise was 7.3 and switched to 7.4 in trusty looking at the launchpad page'
<aeoril> darkxst ok, that is the piece of information I was searching for - thanks (I know you already answered it previously, but just checking)
<aeoril> darkxst sarnold ok, I'll clone the github repo now and start bisecting - thanks for your patience
<brainwash> FOSS_drivers_FTW: it's not automatically synced from debian, because the current ubuntu package has some ubuntu delta
<FOSS_drivers_FTW> brainwash: thanks for the reply. so what can be done to make sure it will be synced before Debian Import Freeze?
<brainwash> FOSS_drivers_FTW: you could file a report and request that the new version is synced
<aeoril> darkxst sarnold do the debian/ubuntu versions always try to include the versioning scheme of the underlying package in their version names?  What if vim had some completely insane version names?
<aeoril> here, it really helped us
<darkxst> aeoril, versions are always [upstream]-[debian][ubuntuX]
<sarnold> is "requestsync" the right tool for that job?
<brainwash> FOSS_drivers_FTW: maybe also ask in #ubuntu-x
<darkxst> if the ubuntu delta can be dropped it is
<sarnold> aeoril: I haven't yet seen a case where the upstream version isn't included; sometimes when projects change their version scheme, the epoch is needed..
<aeoril> darkxst upstream means vim here? (7-4-052, for instance)
<darkxst> aeoril, yes
<darkxst> "-1" is the debian version
<darkxst> "ubuntu3" the ubuntu version
<aeoril> just about to ask that darkxst
<darkxst> sometimes the debian version is "-0" which means the package is not based of a debian revision
<aeoril> so we had an epoch change here because of the 2: ?
<darkxst> aeoril, the epochs, seem to have come from many years ago
<darkxst> but yes at some point (twice) vim must have changed versioning schemes
<darkxst> although there are occassions when the epoch's come from packaging changes (not upstream)
<aeoril> darkxst ok, cool
#ubuntu-devel 2015-02-07
<aeoril> darkxst it appears to make this work I have to switch the meaning of good and bad:  http://stackoverflow.com/questions/15407075/how-could-i-use-git-bisect-to-find-the-first-good-commit
<sarnold> ha
<aeoril> yah, I know ...
<aeoril> (found another article that confirmed this article)
<aeoril> http://git.661346.n2.nabble.com/Why-can-t-I-use-git-bisect-to-find-the-first-good-commit-td6214209.html
<darkxst> aeoril, sure
<darkxst> its makes little difference (apart form possibly confusing you)
<aeoril> darkxst now I have to test how not stupid I can be and see if I can do it without screwing myself up ... :P
<aeoril> but, right now I have to cook for my sick wife ...
<FOSS_drivers_FTW> good night
<derpderp> i have downloaded the latest kernel repo from ubuntu's git archive, but how can I find the code that runs the interface used when changing resolution and monitor placement?
<sarnold> derpderp: poke around in drivers/video/ or drivers/gpu/, both those seem likely candidates
<derpderp> thank you!
<sarnold> derpderp: you might have some success to read through the xrandr source code; it may contain magic that would help you discover what the kernel routines are.
<derpderp> okay. i am having major problems dragging the rectangles in the interface when positioning monitors
<derpderp> itss ridiculous so I thought I could look into it
<derpderp> xrandr sounds more likw what I wnat/
<sarnold> derpderp: is the problem with the dragging-rectangles bit, or what happens to the monitors after you've dragged the rectangles?
<sarnold> derpderp: it might make more sense to look at the control panel source then.. or whatever tool it is that provides the little rectangles ;)
<derpderp> dragging rectangles bit
<derpderp> are there places to go to find where the control panel source is?
<derpderp> I hate to ask so many Qs, I'm usually able to figure things out ubut im new to opens \\ source dev
<sarnold> derpderp: try looking in the unity-control-center package; apt-get source unity-control-center  ought to download it for you
<derpderp> thanks!
<aeoril> darkxst_ you there?
<Noskcaj> aeoril, What's the question? He'll see it eventually
<aeoril> Noskcaj hey, I have been bisecting
<aeoril> hey, darkxst
<darkxst> aeoril, as Noskcaj said, just ask the question ;)
<aeoril> darkxst sarnold I did the bisection.  Wish I had verified v7-4 did not work before starting - it worked fine from the vim git repo, so entire bisection worked fine to versions predating trusty version, or what should be in trusty
<sarnold> hey aeoril :) bummer :/
<aeoril> yah, sucks
<aeoril> darkxst sarnold so could something specific to the ubuntu packages be the problem
<aeoril> ?
<darkxst> aeoril, build the trusty version and see
<darkxst> aeoril, it could well be in a different package though
<aeoril> darkxst does that make sense?  Building the vivid version worked fine on trusty
<sarnold> it could be debian or ubuntu specific packaging.. check the patches in debian/patches/ and see if any of them look like they might be related
<aeoril> sarnold ok - sounds good
<darkxst> aeoril, gtg be back later
<aeoril> darkxst ok, thanks
<sarnold> (check both the vivid and the trusty packages, you never know.. :)
<aeoril> sarnold there is not debian/patches in either version ...
<aeoril> sarnold http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/vim/vivid/files/head:/debian/ http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/vim/trusty/files/head:/debian/
<sarnold> aeoril: oh? http://paste.ubuntu.com/10103567/
<sarnold> aeoril: yeah, go ahead and ignore that ~ubuntu-branches thing entirely :)
<aeoril> sarnold where the heck are you clicking to find this stuff?
<sarnold> aeoril: I cheated, I've got some handy tools that make it easy to download all currently supported versions of a package.
<sarnold> aeoril: so I just typed "umt download -r vivid,trusty vim" and a few seconds later had the unpacked sources sitting on my machine :)
<aeoril> sarnold can I get to it from the launchpad website?
<sarnold> aeoril: yeah, one second..
<aeoril> sarnold am I just stupid? :(
<sarnold> aeoril: nope :) I've got these handy tools because it's not an easy task, otherwise, hehe
<aeoril> sarnold are those tools standard, or did you write them yourself?
<sarnold> aeoril: they're not standard, they just live in a bazaar tree; it's a royal pain to set them up though...
<aeoril> better one royal pain than many
<sarnold> aeoril: oh! I just remembered, there's a much better way than getting them through launchpad
<aeoril> source packages?
<sarnold> aeoril: install the ubuntu-dev-tools package; then you can use 'pull-lp-source vim trusty' and 'pull-lp-source vim vivid'
<aeoril> sarnold that is exactly what I did with vivid ... :)
<sarnold> hahaha
<sarnold> that's the downside to having keen tools that simplify some tasks.. they make it easy to overlook fundementals.
<aeoril> darkxst had me do that for vivid ...
<aeoril> but I forgot about it til you just mentioned it ...
<aeoril> sarnold I am making the trusty vim and going to try it out
<sarnold> woo :)
<aeoril> sarnold it worked fine
<aeoril> sarnold the build environment for trusty vs. what I have must have been the difference
<sarnold> aeoril: but the /usr/bin/vim fails?
<aeoril> sarnold yes
<aeoril> sarnold /usr/bin/vi maybe that is the difference?
<sarnold> aeoril: time to compare ./vim --version with /usr/bin/vim --version and try to find out what's involved..
<aeoril> (vi vs. vim)
<aeoril> what about vi vs. vim?
<sarnold> aeoril: could be
<aeoril> not sure why it is vi in trusty instead of vim ...
<sarnold> aeoril: when you call it with 'vim' it changes a lot of the 'vi-compatible' options
<aeoril> typing just "vim" just does not work
<sarnold> ... also, check /etc/alternatives/vi*  -- turns out my vim is actually calling vim.gtk. I never knew :)
<aeoril> sarnold mine is vim.tiny ...
<aeoril> sarnold the compiled one is full gui, the trusty one is small without gui, according to --version
<aeoril> s/full gui/normal gui/
<aeoril> sarnold vivid is also vim.tiny
<sarnold> aeoril: hah, so the tiny version in trusty is broken, the tiny version in vivid is fine?
<aeoril> sarnold apparently
<aeoril> sarnold gcc command line is very different between versions also according to --version.  I am guessing pass option to ./configure to make vim.tiny?
<sarnold> aeoril: yeah, check the debian/rules file to see if it makes it easy to tell what..
<aeoril> sarnold --version shows that both vi.tiny in trusty (/usr/bin/vi links to it) and what I compiled from trusty vim source are based on 7.4 version dated 2013 aug 10 with patches 1-52,
<aeoril> sarnold "vim-tiny" - that is the name of the VARIANT - not sure what to put on the ./configure command line though
<sarnold> aeoril: note these bits:
<sarnold> CFLAGS_vim-tiny:=$(CFLAGS) -DTINY_VIMRC
<sarnold> CFGFLAGS_vim-tiny:=$(CFGFLAGS) $(TINYFLAGS)
<sarnold> aeoril: read up the debian/rules from there to figure out what should go in the CFGFLAGS and CFLAGS, then look down to the line that has a ./configure in it -- and try to run much the same configure command line :)
<aeoril> I asked on #vim and they said "./configure --with-features=tiny" - would that work?
<sarnold> sounds like good advice :)
<aeoril> sarnold I am confused about what you said about the debian/rules thing though - I looked around but could not make sense of it ...
<sarnold> aeoril: it's based on make and the makefile format; if you're not accustomed to working with them, they can be a bit much
<aeoril> sarnold I used to be pretty good with make, but it has been a long time ...
<sarnold> hehe, for me, it takes about a month before I feel like I'm out of touch :)
<aeoril> sarnold try 10 years or so ...
<aeoril> on Unix ...
<sarnold> oh man, it wasn't even gnu make?
<aeoril> no, Sun Solaris and a real-time System V r4.3 variant ...
<aeoril> well, I mean, maybe it was gnu - don't really know.  Just know it was a long time ago
<aeoril> everything looks pretty familiar, but I have forgotten what stuff does really
<sarnold> solaris didn't feel 'right' until I'd replaced most of the tools with gnu versions.. and the old SCO unix thing I used that might have been 4.3 was all around terrible :)
<aeoril> sarnold hwo old are you?
<sarnold> aeoril: 36?
<aeoril> sarnold just wondering because of your working on older systems
<sarnold> aeoril: it was an amazing job to find while in high school, hehe
<aeoril> sarnold I found the series of lines that set up the TINYFLAGS - it starts out with "TINYFLAGS:=--with-features=small" then adds on various enable/disable flags as well.  Shouldn't I use debian/rules to configure the build, not what was recommended in #vim?
<aeoril> sarnold I remember there was a procedure for using the debian build rules to configure the build when I did some ubuntu builds back in the day
<sarnold> aeoril: well, at least with the simple rules from #vim, you've got something _small_ to work with; the full set of debian/ubuntu configure options might be harder to work with
<aeoril> sarnold I can look that up though on the ubuntu wiki I guess
<sarnold> aeoril: time for dinner :) have a good night, happy hunting :)
<aeoril> sarnold yah, I am gone too now
<aeoril> sarnold thanks :)
<sarnold> nice, have a good weekend then
<aeoril> ok, thanks
<slangasek> xnox: could you really not find a better way to handle keyboard name translations for console-setup than by build-depending on all of the language packs?
#ubuntu-devel 2015-02-08
<aeoril> darkxst sarnold thinking what to do next - probably build vim.tiny, but not sure which way to do it
<aeoril> darkxst sarnold probably take the easy way first and build with --with-features=tiny (or small)
<aeoril> darkxst did you read the backlog about the vim.tiny and vim.gtk (or vim.gui or whatever)
<darkxst> aeoril, no
<darkxst> and I have no idea what tiny is
<aeoril> darkxst the version of vim that ships with ubuntu is vim.tiny (found via a chain of 2 symbolic links) - it is a stripped down version of vim, I assume.  The one I tested turned out to be configured as "Normal GTK2 GUI"  --version shows this information.  --version shows "Small version without GUI" for the ones that ship with Ubuntu, and /debian/rules in the vim package downloaded from lp
<aeoril> verifies this
<darkxst> aeoril, I doubt that is something you could change via an SRU
<darkxst> and why GTK?
<aeoril> darkxst I am not sure I would want to change that, but was thinking of doing some more testing somehow using a build more like what is on Ubuntu.  Why GTK?  I have no idea - should I be able to answer that?  Because there is a GUI version and it uses GTK because the designers chose to???
<darkxst> aeoril, rerun you bisect using the same build options as ubuntu uses
<darkxst> aeoril, actually I have seen that gtk interface I think, but only on windows!
<aeoril> darkxst yes, that is what I was thinking - that was my original question, at least what I was trying to convey - should that be my next step ...
<darkxst> certainly worth a try, shouldnt take long, know you know how to git bisect ;)
<aeoril> darkxst yes, the gtk gui version was not any different on Ubuntu than the small no-GTK/GuI version, from what I could see
<aeoril> darkxst yes, I think I can pull out the proper config rules from /debian/rules - I found the main ones but need to hunt around for any others - another good thing to learn, how to read /debian/rules ...
<darkxst> aeoril, heh enjoy that
<darkxst> no  idea what vim uses but basically there are two competing standards, debhelper and cdbs
<aeoril> darkxst my question was based on something you do not know, though.  There may be a shortcut to try before figuring out all the options from /debian/rules - I asked on #vim and they said I could create vim.tiny with a simple command line option to ./configure - ./configure --with-features=tiny.  Not exactly the same, but if it fails, it might show me the place anyway using bisect
<aeoril> darkxst debhelper and cdbs - ok - can you explain further, or should I google those?
<aeoril> darkxst I remember using debhelper, but not all the details ...
<aeoril> darkxst maybe I should take a detour to a tutorial on the Ubuntu or Debian wikis to learn packaging better?
<aeoril> darkxst I remember that debhelper or whatever built the desired build environment using rules I specified in some kind of config file.  You have to run it and fix problems until all errors and warnings were gone, IIRC
<darkxst> aeoril, its just two different systems really dh is simple, cdbs more complicated but mor powerful
<darkxst> (technically they both use debhelper just in different ways)
<darkxst> aeoril, gtg, but try build trusty version 7.4.052 (or whatever it was) and see if it fails
<darkxst> if so go ahead with a bisect
<darkxst> with you =tiny thing
<aeoril> darkxst yes, will do - already found out it works fine without -tiny, so need to do that.  Thanks
<aeoril> darkxst will you be back?
<aeoril> darkxst actually, I need to go too so never mind
<aeoril> darkxst will bisect tomorrow, if I can (busy day)
<darkxst> aeoril, ok
<aeoril> darkxst unfortunately, my wife is sick so I have not had the normal amount of time to spend on this past couple of days ...
<aeoril> (she has the flu)
<darkxst> soft ;)
<aeoril> darkxst soft?
<aeoril> Society of Forensic Toxicologists? darkxst?
<aeoril> oh, you meant my excuse was soft - I thought you were throwning an internet acronym at me!
<darkxst> hah no your wife is soft taking up all your time for the flu ;)
<aeoril> darkxst yes, she is a princess for sure - with a capital P!
<aeoril> darkxst but, I am still very fortunate to have her ...
<darkxst> heh I kinda had one once, it was very much a one way street
<aeoril> darkxst actually, it is just the opposite - I am having to do all the stuff she normally does, so I appreciate all the more what she accomplishes in a given day in addition to full time work!
<darkxst> ok, really gtg now
<aeoril> darkxst ~bye!
<aeoril> darkxst and thanks!  Will get to it tomorrow hopefully!
<darkxst> aeoril, if you want easier bugs to work on come join Ubuntu GNOME team ;)
<aeoril> darkxst maybe so ... :)
<aeoril> darkxst so far, I still like this one ... :)
<aeoril> darkxst I think the hard part is having to work with upstream repo for bisect?
<darkxst> aeoril, that is the usual way
<aeoril> darkxst I figured ... :)
<darkxst> I do all my dev work on upstream git repos (for GNOME)
<aeoril> darkxst I hope I am doing ok with all this ... not being a burden on you guys
<darkxst> and then backport patches to suit ubuntu packaging
<aeoril> darkxst I see
<darkxst> and mostly because I prefer git over bzr
<darkxst> and jhbuild makes it nice and quick to test builds
<aeoril> darkxst yes, I was not really as fond of bzr as I am of git now
<aeoril> darkxst yes, that sounds interesting, and git is a plus for me I think
<darkxst> aeoril, bzr is dead really (in maintenance mode atleast)
<aeoril> darkxst I kind of saw the writing on the wall for it a long time ago with the advent of git and github, and some of the problems with big projects people reported with it
<darkxst> aeoril, git pre-dated bzr
<aeoril> darkxst maybe the advent of git's popularity or my own familiarity with it?  Anyway, git seemed like a bzr killer at some oint to me
<aeoril> point
<aeoril> darkxst the thing that really concerned me several years ago about bzr is when I heard people on IRC or whatever mentioning it was unstable with large projects
<darkxst> not sure about that
<aeoril> darkxst there was a particular project they mentioned that was really huge, maybe the biggest on bzr at the time, and people said it was unstable
<darkxst> my issues with it are that I learnt git first
<darkxst> and bzr really has nothing on git, for local branches where you hammer the history
<darkxst> rebases and what not
<aeoril> darkxst My biggest issue with my line of chatting at the moment is I really never learned either very well so I need to stop talking about what I don't know about ... :P
<aeoril> darkxst But i am happy to listen to you! :)
<darkxst> well I was going remember!
<aeoril> darkxst now I just don't believe you at all! ;)
<aeoril> darkxst Have an Ubuntu day!
<aeoril> (or night or morning or evening or whatever)
<darkxst> aeoril, U-GNOME day ;)
<aeoril> lol ok!
<darkxst> and its about mid afternoon now
<aeoril> where in the world are you?
<darkxst> in your future ;)
<darkxst> Aus
<aeoril> Cool!
<aeoril> You are about 18 or so hours ahead of me then!
<aeoril> And hot!
<aeoril> (probably)
<darkxst> aeoril, yes hot, I want to move to Europe to fix that
 * darkxst gone now though
<aeoril> toodles~
<svetlana> 1) patch pilots URL in topic got cut off. 2) http://emacs-app.sourceforge.net/ is in gnu/emacs now, built by supplying --with-ns option to configure. how do I request that it is packaged -- with debian first, or not?
<Bluefoxicy> 9.9 Wonderful.  upgrade Chromium, and AGAIN youtube stops working with the html5 player.
<Bluefoxicy> My video driver still hangs a lot
<Bluefoxicy> like I can't use rhythmbox because it nearly kills my PC; if I hit the Gnome 3 activities view, trying to composite causes a 2-5 second hang.
<Bluefoxicy> It was snappy on 14.04 LTS
<Bluefoxicy> Do you know what they told me when I filed the bug?
<Bluefoxicy> "Upgrade your bios."
<Bluefoxicy> Yes, it worked on the previous version, but this version the problem must be my bios.
<Bluefoxicy> Well I did that, and it's still broken.  Good job:  the Intel HD2000 chipset is useless in Ubuntu 14.10, and five-star in 14.04.
 * ejat jom makan 
<Bluefoxicy> I'm upgrading to 15.04 as soon as the first beta is out, because I can't imagine it being worse than 14.10.  Every distro occasionally has its sunken ship release, the one that should be blotted out of history; 14.10 is it for Ubuntu.
<Bluefoxicy> Upgrading from 14.04 to 14.10 is as advisable as upgrading from 98SE to Windows ME
<bekks> Why dont you stick with 14.04 if that worked fine?
<Bluefoxicy> Because I'd have to downgrade backwards, somehow, and I can't do-release-downgrade
<Bluefoxicy> Hopefully someone took down some lessons learned from this release and came up with a list of things to not do again, and things to do in the future before releasing a production OS
<bekks> Because there is no do-release-downgrade at all and downgrading releases isnt supported at all.
<bekks> Did you file bugs for every single item of your "list", so these "things" will get noticed?
<Bluefoxicy> No, because some of them are things like the Google Calender plug-in ceasing to function at all in Thunderbird, which I'm not sure is supported anyway, or why it's broken.
<Bluefoxicy> I filed a bug on the video driver and was told that if it worked in 14.04 and ceased functioning on upgrade to 14.10, it was obviously my bios
<bekks> Bluefoxicy: So if it was you bios, ubuntu cant do anything about it.
<bekks> And shipping an old graphics driver is no viable solution.
<Bluefoxicy> bekks:  It was a regression.
<Bluefoxicy> My hardware is Intel HD2000 in modern Core i5 CPUs
<Bluefoxicy> If a newer graphics driver fails where an old one worked, the new driver has a regression.  That's a bug.
<bekks> If it fails because of a bios issue, the driver cant do anything about it.
<Bluefoxicy> When I finally did get my bios updated--a difficult task, as there's no floppy drive and it's difficult to boot DOS (last time I tried a memdisk boot, it refused to patch the bios)--it didn't fix anything.
<Bluefoxicy> bekks: it didn't fail because of a bios update; the response was "oh your bios is a version behind, so we're not looking at this"
<Bluefoxicy> bringing the bios up to date didn't fix it.
<Bluefoxicy> Apparently the proper response to a report of stuff suddenly not working on upgrade is "well that's somehow someone else's problem"
<Bluefoxicy> when I figure out how Chromium broke AGAIN on upgrade, I'll file a bug on that.  If I ever do.  For some reason, it could play HTML5 youtube videos an hour ago; I ran apt-get upgrade and it upgraded Chromium; I restarted Chromium and now I can't make Youtube videos play at all.
<bekks> Besides some rare facts I can see a lot of ranting in your posts. Did you continue on providing information on your bug report which you created?
<Bluefoxicy> I ran some commands I was asked for and provided a bunch of files
<bekks> And meanwhile you can add several additional bug reports for the other items on your "list" :)
<Bluefoxicy> Most of everything came down to the graphics driver; there's also some kind of system issue with running out of memory (the OOM killer doesn't kick in when you're low on pagecache, so you just grind the system to a halt--this is being looked into on linux-mm), which is secondary to Chromium going out-of-control and allocating tons of RAM; and Chromium randomly breaks for Youtube HTML5 videos when it's updated
<Bluefoxicy> Of course, the graphics driver in question is a majority driver:  it's Intel HD graphics
<Bluefoxicy> and I have nfc what's actually wrong with Chromium
<bekks> And can you confirm that issue using other browsers?
<Bluefoxicy> https://www.youtube.com/watch?feature=player_detailpage&v=eRxOcdLm2_8 plays with HTML5 in Firefox.  In Chromium, it just shows a spinning circle, and downloads the whole video; if I seek through the video, it shows me the frame I seek to (as if paused), while the player acts as if it is perpetually waiting to buffer.
<Bluefoxicy> oh ffs.
<Bluefoxicy> I can't unload the sound card driver module.  I bet my sound card driver is AFU and it's causing video to not play in Chromium (only on Youtube:  video plays without sound on Twitch and in Firefox; I have nfc why)
<Bluefoxicy> I need about 5 minutes to do some maneuvering to cover my identity in some other places before I can reboot.
<Bluefoxicy> sound core failure.  Complete sound core failure.  Now I have to track down why >:|
#ubuntu-devel 2016-02-08
<Pharaoh_Atem> rbasak: ping
<Pharaoh_Atem> rbasak: I've sent you an email with patches and a plea for help :/
<ScottK> tsimonq2: Congratulations on membership.
<pitti> Good morning
<Unit193> Howdy.
<pitti> cjwatson: this is testing PPA + overlay + xenial-proposed; apt's ProblemResolver list in there is rather long (starting with libjsoncpp0v5); supposedly either something in -proposed breaks it or it doesn't have strong enough dependencies; I'll have a closer look
<pitti> smb: err no, that sounds really strange; try with -s, shell in, and see what happens in detail?
<pitti> roaksoax: are there maybe more entries in the .postinst which do something to rackd.service again? does it get run on install, maybe there's a short-circuit?
<pitti> smb: /usr/share/zoneinfo/UTC was wrong?? erk; on my system it's a symlink to "Zulu"
<pitti> smb: and that's what's in the .deb too
<smb> pitti, Yeah its misleading as Zulu has various meanings. But one is UTC
<smb> pitti, It was wrong when I used the downloaded image directly with kvm, so I guess something in the generating of it went wrong
<smb> pitti, So the link was there as well but the Zulu file was different to what the pkg is installing
<pitti> smb: i. e. there's something weird in the cloud image build process?
<pitti> smb: seems fine in today's amd64 image at least
<smb> pitti, Maybe a one off. It was ok at the start of last week, then broken for about the second half. I had not yet looked again
<pitti> smb: oh, wait -- maybe this?
<pitti> $ cat /etc/timezone
<pitti> Europe/Berlin
<pitti> $ ls -l /etc/localtime
<pitti> lrwxrwxrwx 1 root root 27 Feb  5 15:17 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
<pitti> this is indeed inconsistent
<pitti> and sounds like some cloud-init bug
<smb> Might be a result of cloud-init though
<pitti> $ TZ=UTC date
<pitti> Mon Feb  8 09:31:39 CET 2016
<pitti> ah, yeah
<smb> Not sure what is normal there
<pitti> that seems to confuse date somehow
<pitti> smb: well, /etc/timezone and /etc/localtime should certainly agree
<pitti> /etc/timezone is a Debianism
<pitti> it should ideally be dropped at some point, as it's redundant with the /etc/localtime link
<smb> pitti, I'd check the /usr/hsare/zoneinfo/zulu file
<smb> when I looked it was rather largeish and had CET info in (when you check with strings/less
<smb> The correct file is only a few bytes iirc
<pitti> -rw-r--r-- 1 root root 127 Jan 30 00:13 /usr/share/zoneinfo/Zulu
<pitti> ^ on my host
<pitti> -rw-r--r-- 1 root root 2335 Feb  7 09:53 /usr/share/zoneinfo/Zulu
<pitti> ^ on cloud image
<pitti> whoa
<smb> pitti, excactly
<smb> pitti, and that goes away if one reinstalls tzdata
<pitti> smb: indeed, that looks like a grave bug in cloud-init or the image build process
<pitti> smb: can you please file that against cloud-init for now and ask utlemming/smoser about it?
<smb> pitti, Probably rarely observed, Just that libvirt has a build test that verifies that the time offset of UTC is 0...
<smb> pitti, ok will do
<pitti> smb: I'm downloading today's cloud init and will dissect it with directly mounting it, to see if it's already broken in the image or at first boot
<smb> pitti, ok. awsome
<smb> pitti, fyi, I created bug 1543025
<ubottu> bug 1543025 in cloud-init (Ubuntu) "Wrong UTC zoneinfo in cloud-images" [Undecided,New] https://launchpad.net/bugs/1543025
<seb128> hum, lightdm is getting some reports of package install issues with that error
<seb128> "insserv: Service dbus has to be enabled to start service lightdm
<seb128> insserv: exiting now!
<seb128> update-rc.d: error: insserv rejected the script header"
<pitti> smb: hm, kpartx is acting up, but the .squashfs is correct
<pitti> smb: so for now my gut feeling is cloud-init
<seb128> doko, good morning! could you have a look to bug #1542747?
<ubottu> bug 1542747 in telepathy-mission-control-5 (Ubuntu) "Empathy stop working with accounts setup with GOA after last telepathy update" [High,New] https://launchpad.net/bugs/1542747
<seb128> your multiarch upload changed the plugins location it seems
<smb> pitti, Ok, so that sounds like its messed up during the config phase... yes
<seb128> the rules had
<seb128> "# We specifically do not want multiarch: only one version of MC can be
<seb128> # installed anyway, the plugin directory is based on the ${libdir}, and
<seb128> # empathy/experimental ships a plugin in the non-multiarch location
<seb128> CONFIGURE_FLAGS += --libdir=\$${prefix}/lib"
<pitti> l
<seb128> it seems like the debian maintainer specifically decided to not multiarch ... shouldn't we do the same?
<dholbach> good morning
<seb128> hey dholbach!
<dholbach> salut seb128
<pitti> smb, smoser, utlemming: I think I found the culprit in cloud-init, I updated bug 1543025
<ubottu> bug 1543025 in cloud-init (Ubuntu Xenial) "Wrong UTC zoneinfo in cloud-images" [High,Triaged] https://launchpad.net/bugs/1543025
<smb> pitti, Ah good catch
<seb128> hum, is https://errors.ubuntu.com/ loading for others?
<seb128> the list stays on loading for a while and returns an error here
<pitti> still at "Loading..." here
<seb128> oh, loaded this time
<pitti> seb128: oh, it loaded now
<seb128> pitti, yeah, same here, thanks for testing!
<pitti> Mirv: bug 1542239 fixed if you want to check
<ubottu> bug 1542239 in Auto Package Testing "Unable to run some retries" [Low,Fix released] https://launchpad.net/bugs/1542239
<seb128> pitti, do you know about that "update-rc.d: error: insserv rejected the script header"" that impacts lightdm?
<seb128> https://errors.ubuntu.com/problem/14b7d70c74b6a386bf9677234a61bb0265f97886
<pitti> no, I don't -- what does insserv complain about?
<seb128> dunno, what I copied is what is in the log
<seb128> "insserv: Service dbus has to be enabled to start service lightdm
<seb128>  insserv: exiting now!
<seb128>  update-rc.d: error: insserv rejected the script header"
<pitti> sudo /usr/lib/insserv/insserv --verbose --dry-run
<pitti> ?
<pitti> ah
<pitti> so, dbus is disabled
<seb128> well, I would have to have the issue locally to be able to run debug commands...
<pitti> well that then
<seb128> lightdm and insserv didn't change recently
<seb128> I wonder why that started being an issue
<Mirv> pitti: hmm, still getting the same message, do you think the fix is fully deployed?
<pitti> Mirv: it should be
<Mirv> pitti: ok, I reopened the bug now at least
<pitti> Mirv: ok, then I need you to interactively debug this with me, as that was the only wrong thing that I saw
 * pitti enables some debug logging
<Mirv> pitti: ok. I don't see a logic yet - qtcreator-plugin-ubuntu and rocs fail (from under qtdeclarative-opensource-src-gles), but unity8 succeeds. all of them are in universe.
<pitti> ERROR:root:https://api.launchpad.net/1.0/ubuntu/+archive/primary?person=https%3A%2F%2Fapi.launchpad.net%2F1.0%2F%7Etimo-jyrinki&sourcepackagename=qtdeclarative-opensource-src-gles&ws.op=checkUpload&component=main&pocket=Proposed&distroseries=https%3A%2F%2Fapi.launchpad.net%2F1.0%2Fubuntu%2Fxenial failed with 403: Forbidden
<xnox> pitti, is there systemd-tmpfiles sysv service running on kfreebsd/hurd on debian?
<pitti> ah, so that's still wrong -- component=main
<Mirv> although there is a difference that in addition to MOTU I have PPU rights to unity8
<pitti> xnox: nope
<xnox> pitti, =((((((
<pitti> xnox: someone proposed to reimplement some parts of the specification, but it's not in Debian yet
<xnox> pitti, i wonder if just that can like simply compile on kfreebsd.
<pitti> xnox: no, it won't
<xnox> ditto e.g. like sysusers, etc.
<xnox> =(
<pitti> well, someone could take the source, rip out all the linux specific bits etc., and make that build
<pitti> but that's not trivial
<pitti> Mirv: hit that URL again, please?
<pitti> Mirv: yep, as it's using &component=main -- as you have PPU, the component doesn't matter for LP
<pitti> Mirv: i. e. the determination  of the component is still wrong
<pitti> Mirv: oh, crap, I see it, nevermind
<pitti> Mirv: ok, please try again
<Mirv> pitti: works now!
<pitti> great
<Saviq> pitti, hey, after an update of init-system-helpers, ofono fails to install with "invoke-rc.d: unknown initscript, /etc/init.d/ofono not found."
<Saviq> or at least I think that's the cause
<pitti> Saviq: which version did you upgrade from?
<Saviq> pitti, not upgrade, builders fails to install ofono https://launchpadlibrarian.net/236956211/buildlog_ubuntu-xenial-amd64.unity8_8.11+16.04.20160208-0ubuntu1_BUILDING.txt.gz
<pitti> Saviq: ok; can you please file a bug with the URLs?
<pitti> I'll look ASAP
<Saviq> pitti, thanks
<pete-woods> hi folks, I'm looking for some assistance in landing (https://code.launchpad.net/~pete-woods/ubuntu/xenial/libgcrypt20/disable-arm-asm-rijndael) into xenial+vivid overlay. it's not a train-managed package, so I don't know how to land it
<pete-woods> was hoping a friendly archive admin or such like could help me out
<pete-woods> (it's a simple branch that disables some broken ARM assembler for AES in libgcrypt, falling back to C code)
<pete-woods> without it, the keyring crashes on the phone
<pete-woods> I've linked it to branches, reported the bug upstream, etc
<seb128> pete-woods, hey, #ubuntu-ci-eng might be a better place to ask about overlay landings
<pete-woods> seb128: okay, thanks will head over there
<Saviq> pitti, bug #1543051, looks like it ignored invalid initscripts before, now it bails out
<ubottu> bug 1543051 in init-system-helpers (Ubuntu) "New helpers version fail on "unknown initscript"" [Undecided,New] https://launchpad.net/bugs/1543051
<pitti> cjwatson: that was another example of bug 1541334; I deployed the fix now, test is green now
<ubottu> bug 1541334 in autopkgtest (Ubuntu) "Do not run silo tests against all of -proposed" [Undecided,Fix released] https://launchpad.net/bugs/1541334
<pitti> Saviq: thanks
<cjwatson> pitti: ah, great, thanks
<pitti> infinity, cjwatson: wow, we still don't have a proper xenial buildd chroot? http://launchpadlibrarian.net/222053869/chroot-ubuntu-xenial-amd64.tar.bz2 is allegedly the current one, but has wily deb sources and pakcage versions
<cjwatson> pitti: that's up to infinity :)
<pitti> Saviq: fix uploaded; it shouldn't be necessary for the package to land in -release, published in -proposed should be enough; so as soon as https://launchpad.net/ubuntu/+source/init-system-helpers/1.28ubuntu2 is published and on the mirror, you can retry the build
<Saviq> pitti, yup, thanks!
<Mirv> pitti: could kblog and ktnef be overriden for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src - I've filed a bug #1543093 after reproducing the failures locally on stock xenial
<ubottu> bug 1543093 in ktnef (Ubuntu) "fails to build with No rule to make target '/usr/lib/libical.so'" [Undecided,New] https://launchpad.net/bugs/1543093
<Mirv> it's not simply a missing build dependency or such, but something else
<cjwatson> multiarch fallout?
<tsimonq2> thanks ScottK :)
<pitti> Mirv: done
<Mirv> thank you!
<pitti> xnox: are you interested in looking into the upstart test regression? (that happend a fair while ago), or should I just bump the force-badtest?
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/u/upstart/20160207_110626@/log.gz
<pitti> search for "not ok" (one hit, "26 - with single-line script that is killed")
<pitti> which consistently fails on all arches and all runs
<mterry> jdstrand, hello!  We had settled on python-oauthlib as the recommended oauth bindings library a while back.  I'm getting a MIR (bug 1540431) that wants python-oath2client.  Apparently it is the Google-oriented flavor of oauth libraries, and would be difficult to just swap out for oauthlib (has direct support for appengine, etc).  What is the security stance on having two oauth libraries in main?  How much trouble would that be?
<ubottu> bug 1540431 in python-uritemplate (Ubuntu) "[MIR] python-googleapi python-oauth2client" [Undecided,Incomplete] https://launchpad.net/bugs/1540431
<xnox> pitti, it's flakey on ppc64el builders (had to retry the builds). I'm suspecting it's specific to how adt package tests are run.
<xnox> pitti, either to little or too much load.
<xnox> pitti, and the test is racy. We may or may not catch the thing we are trying to catch =/
<pitti> xnox: yes, that's what I meant -- should we just disable that test, if it's known to not work properly anyway?
<pitti> better than entirely ignoring the whole thing
<xnox> pitti, i was pondering to upload: not ok 26 - ..... # TODO -> which will then make it XFAIL, rather than FAIL.
<xnox> pitti, to be honest, unless it affects user-session, or touch, i really don't care.
<pitti> xnox: XFAIL would then fail if it actually succeeds, no?
<ogra_> is that a branded FAIL ? like XNOX-FAIL ?
<ogra_> :)
<xnox> ogra_, expect...
<xnox> pitti, depends how i code it =), i'll make it "ok" or "not ok # TODO"
<xnox> :P
<pitti> xnox: ah, that sounds perfect
<pitti> xnox: thanks
<caribou> Laney: Hi, I would need help with a trusty backport : https://bugs.launchpad.net/trusty-backports/+bug/1494141
<ubottu> Launchpad bug 1494141 in trusty-backports "HAProxy 1.5 init script does not terminate processes" [Medium,In progress]
<caribou> or anybody from the backport team as a matter of fact
<caribou> pitti: did you get to verify the juju-local bug caused by rsyslog since I uploaded 8.16 ?
<pitti> caribou: yes, it doesn't crash any more; thanks!
<caribou> pitti: good, I can close the bug
<Laney> caribou: what actually is needed?
<caribou> Laney: it's been sitting idle for a long time and would need that the current package be replaced by the version in wily-updates (as stated in my last comment)
<caribou> Laney: it was stopped waiting for fixes to make it to the stable release
<caribou> Laney: and is causing problems in Openstack
<Laney> caribou: it is a confusing bug and your comment says "From what I can gather", and not "Please backport from wily-updates" - the former reads to me like you aren't certain
<Laney> So if that's what you want, please make it clear and say that you have tested it
<Laney> for example fix the bug title too
<caribou> Laney: ok, will do & ping you back
<Laney> thanks
<dobey> hmm, when's lts-wily xorg expected to land in trusty updates?
<jdstrand> mterry (and tyhicks): in general we try to avoid things like that. istr this particular case came up once before...
<jdstrand> mterry: ah, yes, bug 1213934. I'll let sarnold comment when he comes online
<ubottu> bug 1213934 in python-oauth2 (Ubuntu) "[MIR] python-oauth2" [Critical,Won't fix] https://launchpad.net/bugs/1213934
<mterry> jdstrand, yeah I know we don't like it.  I'm just not sure that oauth2client is as simple a comparison because of all its google-specific stuff
<mterry> But yeah let's hear sarnold
<mterry> jdstrand, also, did you ever get my email about that PAM module I wrote for lockscreen password?
<mterry> jdstrand, I figure if we're going to use it on phones, you folks should make sure I didn't do something stupid
<jdstrand> we did. tyhicks and I need to give it a priority and assign it to someone. we are pretty behind on reviews atm
<caribou> Laney: just tested & updated the bug; let me know if that is adequate for you
<doko> ginggs, https://bugs.launchpad.net/bugs/1542928
<ubottu> Launchpad bug 1542928 in python-scientific (Debian) "python-scientific should be removed" [Unknown,Confirmed]
<Laney> caribou: ok, thx
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst, seb128
<nandersson_>  Hi, how many years does one have to wait for a contributed patch to enter Ubuntu? This bug is oooooooooooooold, patched and still Canonical hasn't added the patch. What is the reason behind this? https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061/+subscriptions
<ubottu> Launchpad bug 1390061 in bash-completion (Ubuntu) "bash-completion tilde expansion every time" [Medium,Confirmed]
<mdeslaur> nandersson_: I've subscribed ubuntu-sponsors to the bug so the patch gets looked at
<Laney> caribou: done
<seb128> nandersson_, Ubuntu contributors are not restricted to Canonical and that bug should perhaps be sent to Debian, also what mdeslaur said
<caribou> Laney: thank you sooo much !
<tseliot> pitti: for some reason I can't find dh-modaliases on armhf in xenial (arch is set to all in the control file though)
<roaksoax> pitti: there are none: http://paste.ubuntu.com/14993709/
<pitti> tseliot: hm, rmadison also says "all"
<roaksoax> pitti: this was working fine the week before last though, and we just started seeing this last week when trying to update packaging
<pitti> roaksoax: that's the source's .postinst; I mean the built version, with #DEBHELPER# expanded
<nandersson_> mdeslaur, Thanks a lot! :)
<nandersson_> seb128, Thanks. Actually I think it is already patched upstream in Debian, but I will check that.
<cjwatson> tseliot: it's definitely there.  how are you checking this?
<tseliot> cjwatson: my xenial chroot can't find it, also here: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.4.15/+build/8908972
<showaz> nandersson_, http://bash-completion.alioth.debian.org/
<cjwatson> tseliot: the latter is irrelevant, it's arch: all so only built on amd64
<cjwatson> tseliot: when you say "can't find it", could you give me a transcript?
<nandersson_> showaz, Yes, I'll check with Luk and David. Thanks
<cjwatson> tseliot: (https://launchpad.net/ubuntu/xenial/armhf/dh-modaliases shows it as published, and I can see it in a chdist instance)
<tseliot> cjwatson: sbuild says E: Build-Depends dependency for sbuild-build-depends-nvidia-graphics-drivers-361-dummy cannot be satisfied because the package dh-modaliases cannot be found
<tseliot> apt-get failed.
<cjwatson> tseliot: check sources.list etc., or schroot in and see what apt-cache thinks
<tseliot> cjwatson: I did: http://pastebin.ubuntu.com/14993739/
<cjwatson> tseliot: when did you last sbuild-update?
<pitti> tseliot: there is no /ubuntu-ports, it's just /
<roaksoax> pitti: argh! my bad: http://paste.ubuntu.com/14993743/
<pitti> tseliot: ah well, it actually does seem to work, supposedly a symlink to .
<cjwatson> yes, /ubuntu-ports has long been a thing
<cjwatson> having a non-/ root for the archive is helpful for mirrors
<tseliot> pitti: yes, I think apt would have complained otherwise
<pitti> roaksoax: dpkg-maintscript-helper rm_conffile /lib/systemd/system/maas-clusterd.service 2.0.0~alpha1+bzr4635-0ubuntu1 -- "$@"
<pitti> roaksoax: o_O
<pitti> roaksoax: that's not a conffile
<tseliot> cjwatson: I created the chroot maybe a couple of hours ago
<pitti> $ wget -O- http://ports.ubuntu.com/dists/xenial/main/binary-armhf/Packages.bz2 | bzgrep -A10 'Package: dh-modalias'
<pitti> tseliot, cjwatson ^ works (just to ensure that there's really nothing wrong on the mirror)
<tseliot> hmm...
<seb128> nandersson_, the xenial version has been rebased on Debian and has  trivial diff, so the issue should apply to Debian as well
<cjwatson> yeah, I was just doing the same thing :)
<pitti> smb: lol, the messed up UTC timezone is breaking one of my tests, too :)
<nandersson_> seb128, yeah, I am reaching out to Debian maintainers, and have it incorporated there :)
<cjwatson> tseliot: try schrooting in and doing 'apt-cache policy base-files ncurses-base dh-modaliases'
<seb128> nandersson_, thanks
<tseliot> cjwatson: http://paste.ubuntu.com/14993776/
<pitti> tseliot: curious, what kind of setup can run both amd64 and armhf debs at the same time?
<tseliot> it does seem to be there..
<cjwatson> pitti: qemu-user-static presumably
<tseliot> pitti, cjwatson: correct
<cjwatson> tseliot: can you paste the entire output from sbuild, including the command line used to invoke it?  add the --debug option while you're there
<tseliot> that is also how I build Mir on armhf ;)
<tseliot> cjwatson: sure
<doko> ginggs, any idea about petsc on powerpc?
<roaksoax> pitti: yes, I've already cleaned that up, but obviously that doesn't affect things at all
<tseliot> cjwatson: err... it's giving me a different error now: http://pastebin.ubuntu.com/14993857/
<tseliot> that I can probably fix
<cjwatson> mm, that might be something to do with nss databases in the chroot
<tseliot> cjwatson: I managed to fix that, and now the old error is back
<tseliot> cjwatson: http://pastebin.ubuntu.com/14993921/
<cjwatson> tseliot: pass, for the moment - if you tell sbuild not to purge the session then you can use schroot -rc <session id> -u root and see what's up
<tseliot> cjwatson: ok, I'll try that, thanks
<ginggs> doko, no ideas about petsc on powerpc yet, sorry, and there's also aces also fails on powerpc. i'm not sure if petsc still builds in debian on powerpc; it doesn't look like it has been rebuilt there yet
<seb128> smoser, hey, you are core-dev ... any reason you go through the sponsoring queue for https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-ppp-to-server-ship/+merge/284943 rather than doing the changel yourself?
<smoser> seb128, i think peer review makes sense for all people.
<smoser> even for uber elite people who are core dev like myself :)
<smoser> but i mostly planned on doing that one today.
<smoser> i just sent to mailing list and waited to get wider view of it.
<marlinc> The latest updates removed ubuntu-make
<marlinc> The following packages have unmet dependencies.
<marlinc>  ubuntu-make : Depends: python3-argcomplete but it is not going to be installed
<marlinc> https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1543228
<ubottu> Launchpad bug 1543228 in ubuntu-make (Ubuntu) "Latest update caused removal of ubuntu-make" [Undecided,New]
<kuly-zu> when i run netstat i saw some PID/program-name has a -, even if it's run with sudo, why?
<teward> kuly-zu: i think that's a question for #ubuntu not here
<hallyn> pitti: was talking with tych0, and wondering - should lxcfs try loading liblxcfs with relative path first and then the libdir path, or other way around?
<hallyn> i was doing libdir first, but maybe there's no good reason to do so
<sarnold> relative to what? loading libraries from "relative" paths feels scary
<hallyn> sarnold: as in dlopen("lib.so") vs dlopen("/usr/lib/lxcfs/lib.so")
<hallyn> subject to all the usual rpath/ldlibrarypath stuff of course
<hallyn> agree it feels scary, but LD_LIBRARY_PATH Is pretty will thought out these days
<sarnold> hallyn: would cwd ever be anything that allows untrusted writing? e.g. /tmp or /var/tmp ?
<hallyn> sarnold: i don't think so.  depends on init i suppose.  note lxcfs is not setuid-root
<hallyn> surely . isnot in library path by default?
<sarnold> it is not :)
<sarnold> but dlopen("lib.so")..
<cjwatson> dlopen("lib.so") isn't interpreted as a relative path
<cjwatson> see dlopen(3) - "If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname.  Otherwise ..." and it's the "otherwise" bit that pertains here
<sarnold> cjwatson: ah, thus the source of my confusion :) thanks
<cjwatson> AFAIK this is basically the same as an ELF object having DT_NEEDED with no slash in it, which is entirely usual
<hallyn> interesting, i hadn't realized what a pickle dlopen("a/b") would be -not that i can see any reason to do that
<hallyn> anyway, so the poin tis that lxcfs will ship /usr/lib/lxcfs/liblxcfs.so, and i'm trying to decide whether it is better to have lxcfs try dlopen("lxcfs.so") first and fallback to libdir, or not
<hallyn> the usual case if "make; ./lxcfs" suggests yes
<hallyn> (i see, so my wrong terminology was adding to confusion :)
<barry> cjwatson: you don't mind if i upload a new python-six dropping python-six-whl?
<tedg> So I need to have different versions of the compiler choose whether the symbols file is used.
<tedg> Specifically, because gcc5 has different signatures than gcc4.9.
<tedg> So if built on gcc 4.x I don't want to check symbols.
<tedg> Can't seem to figure out how to detect that and turn off symbols in a reasonable way. Ideas?
<ginggs> doko: fwiw, i just tried building petsc on debian powerpc porterbox and it fails there too - as soon the mpi test program is launched
<doko> ginggs, ahh, so openmpi is broken. filing a bug report
<ginggs> doko: i concur. aces3 fails in exactly the same way (and does not use petsc)
<cjwatson> barry: not if you do it to Debian :)
<barry> cjwatson: of course! :)
<barry> thx
<tedg> xnox: Trying to figure out dh_acc, do you know of a project I could look at and steal from?
<dobey> tjaalton: if you're around, i'm just curious why xorg-server-lts-wily hasn't made it into trusty-updates yet :)
<tjaalton> dobey: probably because of some miscommunication.. the dailies need to be tested, then the stack can be moved to updates, i'm told
<tjaalton> noone did the testing part yet
<dobey> oh
<dobey> hmm
<doko> rbasak, please could -server write a MIR for lua-lpeg, new b-d for nmap
<nacc> slangasek: for new src packages (e.g., php-pear moving from src:php5 to src:php-pear), is there a template for filing a bug? Its more intuitive for updating to a new version, but for packaging an altogether new package, I wasn't sure
<nacc> slangasek: nm! found it on the wiki, sorry for the noise
<xnox> tedg, checkout reverse-depends -b src:acc-package-name ?!
<xnox> tedg, it's convoluted, and there are bug reports about it. in practice, build once with it enabled everywhere, retrieve abi tarballs, ship them.
#ubuntu-devel 2016-02-09
<hallyn> pitti: d'oh, i'm afraid i'm dropping bug 1543170 in your lap
<ubottu> bug 1543170 in lxc (Ubuntu) "lxc fails to install" [Critical,Triaged] https://launchpad.net/bugs/1543170
<hallyn> seems liek a standing bug in invoke-rc.d called through debootstrap
<hallyn> maybe the bug really is that debootstrap isn't setting things up right, dunno
<nacc> is there a relatively straightforward way for me to tell dh or dpkg-buildpackage that i don't want d/patches to be applied?
<sarnold> (guessing) mv debian/patches/series debian/patches/series.ignoremeplease   ?
<nacc> heh
<nacc> yeah, so i can do that
<nacc> but i'm trying to come up with a "clean" way to do a bootstrap (for php7 purposes)
<nacc> when i did it in my ppa, i basically did exactly what you said for the first build
<slangasek> it's not clean to skip debian/patches when unpacking a package, when using dpkg format 3.0 (quilt).  It's part of the definition of the unpack
<slangasek> so yeah, rm debian/patches/series (or mv) is better
<nacc> slangasek: ok, so how do i capture that is only needed in, e.g., stage1?
<slangasek> nacc: I don't think you do
<slangasek> nacc: you can apply additional patches via debian/rules based on profile
<slangasek> or you can make the patch against the source "clean" so that it can be applied for both stage1 and normal build
<nacc> slangasek: in this particular case, i basically don't want to patch in stage1 and want to patch othewrise
<nacc> the patch in question introduces a build-dep
<nacc> that is not otherwise there, and leads to a cycle
<cjwatson> can you modify the patch to make the behaviour conditional?  that's the usual answer
<slangasek> ^^
<sarnold> nacc: heh, cyclical deps on php7 bringup.. they threw you right into the deep end, didn't they? :)
<nacc> cjwatson: hrm, i'm not sure ... it is patching the source to autoload some classes from Symfony (whch in turn depends on the package being rebuilt). I wonder, though, since it is just a bootstrap -- i'm not intending for it to be 'functional' in stage1
<nacc> cjwatson: slangasek: is taht acceptable? that is, stage1 is purely a build artifact?
<slangasek> nacc: yes, stage1 packages should never be used for anything other than further bootstrapping
<cjwatson> https://wiki.debian.org/BuildProfileSpec defines what's acceptable from stage1
<nacc> i'd need to go look at what build-deps on this, to make sure *it* can build :)
<nacc> cjwatson: yep, i'm reading (and rereading) that :)
<nacc> cjwatson: i don't think i can modify the patch in any sane way, that i can see yet :)
<nacc> sarnold: heh, yep
<cjwatson> it's pretty rare for it not to be possible to at least bodge the patch to let you switch it off with an environment variable or something
<xnox> nacc, i thought build-profiles are exported as environment variables, and you can e.g. do somthing like ifeq (stage1,$BUILD_PROFILE_VARIABLE_NAME) and do like quilt pop -a =)
<nacc> cjwatson: well, it's interpreted PHP code ... so not sure how far i want to go that route
<nacc> xnox: they are; would i do that in an override_ section? that's what i was trying to figure out
<nacc> cjwatson: hrm, maybe i can do what you're suggesting ... let me take a stab at it :)
<nacc> cjwatson: one issue i see is that i'm adding an environmental check to every user of this code just so we can bootstrap it?
<cjwatson> depends whether that's an intrusive thing
<mwhudson> can dep8 tests download random junk from the internet?
<xnox> mwhudson, yes, through a proxy
<mwhudson> cool
<xnox> mwhudson, https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038448.html
<nacc> cjwatson: slangasek: xnox: sarnold: for now, i think just letting the patch apply but removing the b-d works. Will test it in the AM to be sure. Thanks for the help/suggestions!
<tedg> xnox: I tried that first, this returns no results on xenial: $ apt-cache rdepends dh-acc
<xnox> tedg, rdepends has nothing to do with build-dependencies.
<xnox> $ reverse-depends -b dh-acc
<xnox> Reverse-Build-Depends
<xnox> =====================
<xnox> * muffin
<tedg> xnox: Ah, sorry, yes.
 * tedg grabs a muffin
<tedg> xnox: Not sure if you're still up, but I don't see any abi dump for muffin.
<tedg> xnox: I'm not sure it's actually checking against anything.
<xnox> tedg, i believe lp:upstart and/or upstart package had abi dumps, which we did verify.
<xnox> $ du -a upstart-1.13.2/lib/abi/
<xnox> 504	upstart-1.13.2/lib/abi/i686-linux-gnu/libupstart_1.0.0.abi
<xnox> 508	upstart-1.13.2/lib/abi/i686-linux-gnu
<xnox> 520	upstart-1.13.2/lib/abi/x86_64-linux-gnu/libupstart_1.0.0.abi
<xnox> 524	upstart-1.13.2/lib/abi/x86_64-linux-gnu
<xnox> 1036	upstart-1.13.2/lib/abi/
<xnox> but that's without dh_acc help
<xnox> tedg, well, not tarballs, just flat files.
<RAOF> tedg: You're aware that Mir uses abi-compliance-checker in one of our release targets?
<tedg> RAOF: Do you use dh_acc ?
<RAOF> No, we don't use that though.
<RAOF> We're the reason that abi-compliance-checker is in main, though.
<RAOF> So feel free to MIR dh_acc :)
<xnox> RAOF, same source package. so MIR shouldn't be required, just binary promotion.
<tedg> Heh, I thought this was going to be an easy way to move from symbols.... but eh, it's being more painful than I'd wanted.
<RAOF> xnox: Oooh, even easier.
<RAOF> tedg: Once you've got it all worked out, I'll happily steal it for Mir's packaging :)
<xnox> tedg, both are interesting tools, and both do different stuff.
<xnox> the are things one can catch with symbols vs acc.
<RAOF> What can you catch with symbols that you can't catch with acc?
<RAOF> Bah. Of course. Debian metadata!
<tedg> The problem with symbols is that you need a GCC version specifc symbols file for anything C++, which isn't well supported and annoying.
<xnox> versioned deps, alternative deps, etc.
<xnox> tedg, use appropriate filters to mark them as optional.
<tedg> xnox: Almost everything would be optional because the signature for string changed.
<RAOF> Isn't your actual problem that you're trying to provide a stable C++ ABI? :P
<xnox> there are plenty of c++ kde packages that get g++ symbols rihgt
<tedg> Basically removing the checking almost completely at that point.
<ScottK> xnox: But by using the pkg-kde symbolhelper.  Not the regular one.
<xnox> tedg, have you used demangled c++ names? where the demangled name is used throughout rather than a mangled one?
<xnox> ScottK, hello =) how are you.
<ScottK> Hello.
<xnox> tedg, yeah that pkg-kde symbolhelper is nice, for c++ heavy stuff.
<tedg> xnox: Yes, the problem is how the containers changed in representing strings.
<ScottK> Not bad, just passing through.
<xnox> tedg, wait, that's an ABI break no? there is no way around that, you will have different abi in dual landing.
<tedg> Sadly I still have to land things on Vivid :-/
<xnox> tedg, and you _mus_ use different soname in vivid vs xenial.
<tedg> xnox: Yes, but then I need both symbols files, which doesn't really work.
<xnox> tedg, and you _must_ use different soname in vivid vs xenial.
<xnox> tedg, you can do include directive to factor them out.
 * tedg doesn't know what an include directive is
<xnox> tedg, why do you say doesn't work? you should have e.g. libfoo1.symbols and libfoo1v5.symbols
<xnox> and inside those you can do #include "packages.symbols.common" for common things
<xnox> tedg, $ man dpkg-gensymbols
<xnox> tedg, really read that, it has info on a lot of funky stuff one can do with symbols.
<tedg> xnox: How does the symbols code know which to choose?
<xnox> tedg, what do you mean which one to choose?
<xnox> tedg, on vivid you should be generating libfoo1 binary package, on xenial libfoo1v5 binary package.
<tedg> libfoo1.symbols vs libfoo1v5.symbols
<xnox> which means, changing debian/control on the fly. or for example, simply skipping this or that binary package.
<tedg> Uhg. Okay. How change debian/control on the fly?
<xnox> sorry go to go. but ACC will not solve your problem with symbols at all, nor the fact that you are maintaining two ABIs for two SDKs
<tedg> K, thanks xnox !
 * RAOF wonders what people would think about statically linking libstdc++ into libmirclient...
<tedg> RAOF: As long as you wrap all the containers to "Mir::list" :-)
<RAOF> libmirclient exposes no C++ types. :P
<xnox> RAOF, i hate you
<xnox> =)
<RAOF> :P
 * tedg hates types, rewrites everything in Python
 * xnox alert resistance RAOF is charging the weapon
<RAOF> This is a real thing that might happen at one point, though, unless we have some fancier way to handle the phone-15.10-ABI-exists-forever preblem.
<tedg> What I guess I don't understand, is what is the knob that knows what distro series a package is building for?
<tedg> Not sure how to make a control file that understands/works with that.
<RAOF> debian/changelog, surely?
<tedg> It has the information, but not sure how to build a control file from that.
<tedg> Or, wait, doesn't control have to be read before rules? To determine build deps?
<tedg> Uhg, shlibs is fine.
<RAOF> You could *technically* change the control file between the start of build and when the binary packages are being built.
<RAOF> So, early in debian/rules.
<RAOF> I think that people are likely to hit you with sticks if you try that.
<RAOF> Just maintain two separate packaging branches, one for vivid-overlay, one for xenial.
<hallyn> tedg: fwiw qemu ships a debian/control-in which is parsed into debian/control
<hallyn> allowing a single control-in to work for both edebian and ubuntu
<hallyn> there is a target in debian/rules to make control
<RAOF> Ah. I see the âsomething writes a malformed EFI entry, resulting in Ubuntu failing to appearâ bug still exists, then.
<pitti> Good morning
<slangasek> pitti: good morning (nice timing ;)! do you know of any recent changes to scalingstack firewall configs that would explain apport autopkgtest no longer being able to hit api.launchpad.net?
<xnox> pitti, good morning =)
<pitti> hallyn: that sounds very familiar, I fixed that yesterday
<pitti> oh, seems slangasek beat me to duping it by 5 mins :)
<pitti> hey xnox!
<slangasek> pitti: yes, and now I'm looking at the autopkgtest failures that are blocking init-system-helpers in -proposed
<slangasek> cf apport ;)
<Mirv> pitti: robru suggested pinging you about autopkgtest running page being suspiciously short, no silos mentioned and still eg there are a lot of "Test in progress" at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html since yesterday
<pitti> slangasek: eek, they can't? no, I'm not aware of changes, but I do have to adjust the $no_proxy list every now and then
<slangasek> pitti: well, maybe I'm misunderstanding https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/apport/20160208_130843@/log.gz - on second glance, the first set of errors seem to be a gpg problem
<xnox> cjwatson, i wonder if perl-modules really outght to be arch:any. The reason being, arch-skew is a pain. Especially on architectures that are faster than amd64 =)
<slangasek> (HOME=/root, but not writable by the test?)
<pitti> slangasek: right, these got broken before though, apport has a hint
<pitti> slangasek: (on my list to investigate)
<xnox> cjwatson, but i guess it's only I that has that problem =)
<slangasek> pitti: haha, once again I failed to read down to the bottom
<pitti> slangasek: it's held because of the linux and openssh regressions
<slangasek> see, I'm just going to annoy you so much by not reading to the bottom that you'll eventually have no choice but to fix it
<pitti> http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ isn't very stable
<pitti> slangasek: heh, indeed! this ween isn't a sprint week, so I'm slowly crawling through bug fixes and backlog like this
<pitti> meh, ppc64el machines are *still* unhappy
 * pitti follows up to the RT again
<slangasek> pitti: ok, and I'm confident in saying that init-system-helpers didn't regress openssh's checksum testsuite to regress on armhf
<pitti> right
<pitti> I just hinted i-s-h, it's quite urgent
<slangasek> pitti: thanks!
<pitti> and retried openssh/armhf
<xnox> pitti, doko - findutils migrated which breaks python3.4. python3.4 is stuck in -proposed, because of amd64 build-failure.
<pitti> oh, I got python3.4 removed on dist-upgrade yesterday
<pitti> I thought that was by intent
<pitti> (doko was working on removing 3.4)
<xnox> either all of those modules should not be arch:all, or we need to fix python3.4.
<xnox> pitti, sure, but at the moment debootstrap now fails in xenial-release.
<xnox> because findutils breaks python3.4 in release.
 * xnox has no idea why/how it migrated like that.
 * xnox ponders to upload findutils with the breaks removed for now.
<xnox> https://launchpadlibrarian.net/237057251/buildlog_ubuntu_xenial_s390x_s390x_cpc_BUILDING.txt.gz
<xnox> actually, i'm not sure how/where/why python3.4 is pulled in.
<xnox> doko, gave back python3.4:amd64 xenial-proposed
<pitti> Mirv: bumped those
<didrocks> do we have some busted buildds?
<didrocks> https://launchpadlibrarian.net/237060009/buildlog_ubuntu-xenial-amd64.ubuntu-make_16.02_BUILDING.txt.gz
<didrocks> W: The repository 'file:/Â«BUILDDIRÂ»/resolver-Oah2dz/apt_archive ./ Release' is not signed.
<dholbach> good morning
<xnox> didrocks, that's normal.
<didrocks> xnox: not sure I feel reassured :)
<xnox> didrocks, i believe sbuild now generates a brand new archive in a temporary location, to call $ apt-get build-dep $src_pkg
<xnox> didrocks, instead of trying to parse the build-deps in the .dsc by itself.
<xnox> didrocks, in theory, recent enough apt should have gained capability to do $ apt-get build-dep $src_pkg.dsc without these extra archive thing.
<didrocks> xnox: yeah, (I guess I meant apt build-dep ;))
<xnox> didrocks, note it's the 'file:/Â«BUILDDIRÂ»/resolver-Ls0sgY/apt_archive' which is unsigned, a temp directory, inside the build-directory, inside the brand new chroot.
<didrocks> ok, didn't know that changed :)
<xnox> didrocks, but like version constraints, alternative deps are all resolved correctly like this, ditto multi-arch, build-profiles and a bunch of other stuff.
<didrocks> ok, good to know! :)
<didrocks> which comes to my next question (I guess it's for doko): any hint on python3-argcomplete now being installable in xenial? :p
<didrocks> didn't see any upload, nothing
<didrocks> xnox: do you have a chdist handy? The one on snakefruit doesn't seem to want to get up to date
<xnox> didrocks, i do, what's up?
<xnox> argcomplete thing?
<didrocks> xnox: do you mind trying to install python3-argcomplete (as the logs above mention, it doesn't want to in -proposed)
<didrocks> yep ;)
<didrocks> xnox: any lead or should I setup my own chdist?
<xnox> didrocks, let me find that terminal
<didrocks> hidden in a jungle of others! :)
<xnox> didrocks, it's installable in -proposed.
<xnox> but without findutils.
<xnox> didrocks, soon python3.4 will be fully removed, and then things will get better.
<pitti> Mirv: valid candidate  now
<pitti> slangasek: I get the regressions locally as well, so not a firewall issue
<pitti> slangasek: ooh -- that's bug 1541925 again
<ubottu> bug 1541925 in gnupg (Ubuntu) "Tries to create temp files under ~/.gnupg but doesn't create the dir" [High,New] https://launchpad.net/bugs/1541925
<xnox> pitti, python-numpy -> numexpr adt test looks strange, as it's using "old" numexpr unlike all other arches. Can it be triggered/hinted to test both numpy & numexpr from -proposed on s390x? or e.g. hinted over
<didrocks> xnox: hum, what is your definition of "soon", not sure how to unblock ubuntu-make today :)
<xnox> didrocks, remove python3.4 from the archive =)
<xnox> didrocks, or make the python3.4/amd64 build and pass test-suite.
<didrocks> xnox: I guess doko is on it, right? ;)
<xnox> didrocks, what do you mean "unblock" ubuntu-make? if it's in a ppa, enable building with -proposed.
<didrocks> xnox: no, it's in xenial
<xnox> and on !amd64 =)
<xnox> ah
<xnox> =(
<didrocks> and blocked in proposed due to this FTBFS
<pitti> xnox: I retried it for now, so it should run against the new version; if that still doesn't help, I'll have a closer look and hint
<xnox> pitti, thanks.
<pitti> xnox: err .. look at the queues on http://autopkgtest.ubuntu.com/running.shtml
<pitti> that will take a while
<xnox> pitti, from same numpy triggers, python-pywcs is werid it says regressions yet no test exist in that package
<pitti> the Perl did it again
<xnox> pitti, is that something you have to manually remove?
<didrocks> so, basically a lot of packages are going to FTBFS due to this half-transition/removal I guess?
<xnox> didrocks, well. it's an arch skew, yes.
<pitti> xnox: right, I consider exit code 8 "no tests in this package" as regression, as usually it's not intended to remove htem
<pitti> so I at least want to have a look and make sure it's intended
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
<xnox> pitti, but it looks like it's getting reverted to a older version.
<pitti> xnox: ah no, it seems they were added only in -proposed, so running against the released version doesn't work
<xnox> =/
<xnox> quite.
<pitti> xnox: requeued with running both from -proposed
 * pitti expects having to shortcut perl a bit
<xnox> blimey
<xnox> pitti, we need more builders =)
<xnox> pitti, i'm failing to run components-missmatch report locally. Are there magic options that one should pass to it?
<xnox> cause at the moment, it tries to like demote dash for me, which should remain in required =/
<xnox> what options are used to run the official report for e.g. xenial-release?
<michael-vb> Hello again.  I posted a question regarding unity-settings-daemon in combination with VirtualBox guests on Launchpad - https://answers.launchpad.net/unity-settings-daemon/+question/284461 - and was wondering whether anyone could comment.  I might mention that sometimes resizing blocks altogether.
<pitti> xnox: looking at snakefruit's bin/archive-reports, I don't see anything fancy really
<pitti>                         component-mismatches -e touch \
<pitti>                                 -d "$OUT/$name.dot" -o "$OUT/$name.txt.new" \
<pitti>                                 --html-output-file "$OUT/$name.html" \
<pitti>                                 --csv-file "$OUT/$name.csv" \
<pitti>                             component-mismatches
<xnox> horum.
<pitti> although the latter argument doesn't seem to belong to the c-m call itself
 * pitti tries to interpret what
<pitti>                 background pids component_mismatches component-mismatches
<pitti> means
<xnox> pitti, is that bin/archive-reports at all available for mere mortals to view? e.g. in ubuntu-archive-tools repository?
<xnox> pitti, i was expecting to see included/excluded seeds.
<pitti> xnox: http://bazaar.launchpad.net/~ubuntu-archive/+junk/scripts/changes
<xnox> maybe my output is incomplete for components-mismatches to process.
<pitti> i. e. http://bazaar.launchpad.net/~ubuntu-archive/+junk/scripts/view/head:/archive-reports
<pitti> xnox: although there's an uncommitted delta there: http://paste.ubuntu.com/15000949/
<pitti> (not sure who added this)
<pitti> so maybe the "-e touch" does something magic
<pitti> but if anything, including touch should want *more* packages in main
<cjwatson> pitti: what's up with snakefruit?
<cjwatson> oh, component-mismatches arguments
<pitti> cjwatson: xnox wondered how we call c-m ... that
<xnox> cjwatson, well i ran components mismatches locally against https://code.launchpad.net/~xnox/germinate/+git/germinate output and it decided to demote dash to universe.
<xnox> i don't think that would fly =)
<cjwatson> it expects a mirror of dists/ in ~/mirror/ubuntu/
<cjwatson> and you might need to pass --germinate-path
<cjwatson> also it expects germinate output in the format emitted by stuff in lp:ubuntu-archive-publishing because reasons ... it might be easiest to lay things out somewhat by hand
<cjwatson> though running generate-extra-overrides from there probably shouldn't be ridiculously impossible
<cjwatson> (it uses the germinate Python modules, so set PYTHONPATH appropriately if you want to run against your own versions from a working tree)
<cjwatson> I still need to stare at your germinate MP at some point :)
<xnox> i've spend this morning starring at mounting loop4p1 and then installing bootloader on to loop0 and not seeing what the problem was =)
<xnox> cjwatson, yeah, starring at that mp might be useful. or e.g. diffing / starring at the produced outputs too http://people.canonical.com/~xnox/germinate-output/
<xnox> i'll ask steve to figure out components-missmatches. as i have customer work to do =)
<michael-vb> Once more - any one here knowledgeable about how unity-settings-daemon works, and specifically the RandR code?  If not, who might know?
<Mirv> pitti: nice! too bad the Train still thinks the silo has failed automated signoff.
<xnox> michael-vb, try #ubuntu-desktop? desktopy developers are there.
<seb128> michael-vb, #ubuntu-desktop is better placed for unity-settings-daemon questions but no we don't have anyone familiar with the randr code afaik, that part come from gnome-settings-daemon and wasn't change by us
<michael-vb> Oh dear, that was what I was afraid of.
<seb128> what's your issue?
<xnox> michael-vb, i only work on things from "nothing installed" to "reaching multi-user.target" =)
<michael-vb> (10:38:01) michael-vb: Hello again.  I posted a question regarding unity-settings-daemon in combination with VirtualBox guests on Launchpad - https://answers.launchpad.net/unity-settings-daemon/+question/284461 - and was wondering whether anyone could comment.  I might mention that sometimes resizing blocks altogether.
 * xnox guesses seb128 has a highlight on "ubuntu-desktop" keyword.
<michael-vb> It was an issue back in the days when it was still gnome-settings-daemon too, but I never found time to properly look into it.
<michael-vb> I suspect that back then someone got it working "well enough" but a VM places more strain on it.
<michael-vb> I am rather afraid to start trying to contribute code, as last time I tried I spend more time on the bureaucracy than the code.
<xnox> michael-vb, don't use VirtualBox =) install ubuntu for real? =)
<michael-vb> Rather hard, given my current job.
<michael-vb> That said, I run Ubuntu on my host system too.
<seb128> michael-vb, it's worth a bug report (we might already have one) but would need debugging by somebody having the issue...
<michael-vb> I am happy to debug, and obviously I can read and write code.
<michael-vb> But I was hoping we could somehow work around the issue.  My experience of getting things fixed in Ubuntu is not great.  Not wanting to complain, just to live with the facts.
<seb128> yeah, there are more things to work on that we have people/hours in the week
<michael-vb> Don't worry, I know all about that.
<seb128> is that buggy monitors.xml recreated if you delete it?
<michael-vb> (https://www.virtualbox.org/report/1)
<michael-vb> It hasn't been re-created since I deleted it last.  But of course I would take time to observe what happens.
<michael-vb> And things have been working since then too in my test guest system I must say.
<michael-vb> I dare say that when I find what triggers it that may also give me an idea for a work-around.
<michael-vb> Then I take it I don't need to switch over to #ubuntu-desktop, but rather observe and open a bug report when I can report something sensible?  I think in the first place I have moved on a bit.
<seb128> michael-vb, best is to open a bug against unity-settings-daemon and maybe come ask about it again on #ubuntu-desktop after feature freeze
<seb128> I doubt we are going to have slots for that sort of debugging this week
<michael-vb> Oh, is it feature freeze time?  Perhaps I should be updating to 16.04...
<seb128> next week it is
<michael-vb> I  personally usually start off debugging that sort of thing by making the bug reporter work as much as possible.  It also gives me an idea of how seriously to take it.
<michael-vb> But I wouldn't have expected a debugging slot in the week anyway.
<michael-vb> I will get back to then.  Hope the feature freeze goes well.
<michael-vb> (get back to you)
<michael-vb> Thanks all.
<xnox> cjwatson, parted patch is kosher, and it was filed as a bug report in debian.
<cjwatson> I noticed, on my queue, thanks.
<sil2100> ginggs: hey!
<sil2100> ginggs: I saw you did a no-change rebuild for cmake for the libjsoncpp sync-transition that happened - are you working on the transition in overall, or can I proceed with all the other uploads?
<sil2100> ginggs: don't want to step on your toes
<sil2100> ginggs: ...I'll go ahead with a few projects if you don't mind
<sil2100> Since this libjsoncpp transition is blocking us a bit
<xnox> Obscure shell -> is there any reason, why this thing doesn't do "for bridge in $br_list" instead of <<< ? http://paste.ubuntu.com/15001260/
<xnox> pitti, cjwatson ^
 * xnox is lost, i see bashism.
<xnox> full thing http://paste.ubuntu.com/15001267/
<pitti> xnox: what are these ':'?
<pitti> oh, IFS
<xnox> pitti, quality IBM code =)
<pitti> xnox: and what is <<< ?
<pitti> is that some shorthand for echo 'string' | ?
<pitti> i. e. constructing stdin from a string?
<xnox> pitti, <<< is bash HEREDOC or some such, it's liek <<EOF, apart from without "EOF" and i think it spawns a separate shell.
<pitti> right, that's bash
<xnox> pitti, but, imho, there is no reason to do this crazy "while read" and <<<$br_list, when one can do: for bridge in $br_list; do
<pitti> i. e. two nested loops, one over the bridges, one over the three commands
<pitti> or  just expand out the latter, it's just three after all (same number of lines as a for loop)
<ginggs> hi sil2100, please go ahead, i've been meaning to find out how to set up a transition tracker in ubuntu
<ginggs> debian's is here: https://release.debian.org/transitions/html/auto-libjsoncpp.html
<sil2100> ginggs: yeah, that would be useful, but in the case of libjsoncpp at least there's not too many reverse-deps
<zbenjamin> jdstrand: ping, hey this came up a few weeks ago: https://bugs.launchpad.net/ubuntu-sdk-ide/+bug/1520551   could we give the debug policy the ability to handle that correctly?
<ubottu> Launchpad bug 1520551 in Ubuntu SDK IDE "Profiling from Ubuntu SDK IDE is working only if "networking", policy group is enabled in apparmor" [Undecided,New]
<didrocks> doko: hey! any idea on the python issue in -proposed we discussed above? (I saw you talked on ubuntu-desktop so, I guess you are around? :))
<didrocks> python3-argparse can't be installed with findutils
<doko> didrocks: pointer?
<didrocks> doko: https://launchpadlibrarian.net/237060009/buildlog_ubuntu-xenial-amd64.ubuntu-make_16.02_BUILDING.txt.gz for instance
<didrocks> and as xnox said:
<didrocks> 09:51:15       xnox | didrocks, it's installable in -proposed.
<didrocks> 09:51:26       xnox | but without findutils.
<xnox> doko, it would help a lot for https://launchpad.net/ubuntu/+source/python3.4/3.4.4-2 to migrate, because findutils which breaks python3.4 is in release, thus python3.4 is not installable in release pocket anymore.
<xnox> doko, given that python3.4 is on the way out, could you upload something that e.g. skips the testsuite on amd64? such that it migrates?
<xnox> doko, or e.g. shall we upload a findutils without breaks for a little while?
<xnox> (breaks on the python3.4 package)
<doko> meh, looking
<doko> jtaylor, tumbleweed: what's the way to go forward with numpy? 1.11 beta doesn't look promising either ...
<doko> what is the distutils numpy autopkg test supposed to test?
<doko> fails in -release too
<didrocks> doko: thanks for the fix. I'll do a give back once it's published in proposed
<jtaylor> doko: whats the failure?
<doko> jtaylor, the distutils test emits a user warning on stderr. now allowing stderr for this test
<jtaylor> what is it printing?
<Laney> there's actual failures
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-numpy/20160207_105740@/log.gz
<jtaylor> ah its still 1.10
<jtaylor> thats the issue I told you about a while ago
<jtaylor> + patch for it
<doko> hmm, can't remember
<jtaylor> should be fixed in 1.11 I think
<doko> yep, but that one is introducing more failures in autopkg tests
<jtaylor> in others I guess?
<doko> see ole's report for debian
<tjaalton> doko: is llvm-3.8 ready to replace 3.6 in main or do you prefer to wait for next rc or final? pondering where to push new mesa..
<doko> tjaalton, please check with 3.8
<tjaalton> check?
<tjaalton> I can push it to a ppa first
<tjaalton> at least mesa builds with it
<pitti> neither current desktop live system, nor ubiquity-only are currently booting in QEMU for me -- is that only me?
<davmor2> pitti: which are you saying is current?
<pitti> http://cdimage.ubuntu.com/cdimage/daily-live/ says it's from today, yes
<davmor2> pitti: give me 5 I'll see if I can confirm for you
<cjwatson> pitti: see #ubuntu-release
<cjwatson> apparently a missing video driver package
<pitti> ah, thanks!
<ogra_> finally ... headless desktop images !
<davmor2> ogra_: careful it'll overtake snappy if you are not careful :P
<ogra_> haha
<seb128> pitti, see #ubuntu-desktop backlog
<pitti> seb128: thanks
<seb128> it's a bit annoying that images manage to move to "current" despite having no xorg working
<seb128> "images to have passed any automatic testing"
<seb128> rrright ;-)
<sil2100> seb128, pitti: hey! I'm updating the xenial ubuntu-touch-meta packages as per the libjsoncpp transition - but it seems the ./update script doesn't use -proposed (it removes libjsoncpp0v5 but doesn't add libjsoncpp1) - is it ok for me to modify the seeds manually in the metapackage in this case?
<sil2100> I need to modify the seeds as part of the transition itself
<seb128> sil2100, don't know, I'm not the right person to ask about that
<cjwatson> I think that's reasonable if it's a necessary part of the transition.
<sil2100> cjwatson: thanks :)
<cjwatson> This is an unfortunate consequence of the touch seeds hardcoding particular ABIs.
<Nitrigaur> I'm trying to test Xenial 64 Bit in a VirtualBox (version 4.3.6) environment, but the installer crashes on the "piix4_smbus error" as described at: http://askubuntu.com/questions/298290/smbus-bios-error-while-booting-ubuntu-in-virtualbox
<Nitrigaur> The install crashes before I can get access to a proper terminal, so I'm unable to try the workarounds described there
<pitti> robru: ah! I finally found some time to investigate bug 1537866 again, and now I understand what's going on
<ubottu> bug 1537866 in britney "Britney flops back and forth between Running and Approved a lot" [High,In progress] https://launchpad.net/bugs/1537866
<damascene> leave Britney alone
<pitti> no way, she's working around the clock for us!
<damascene> :(
<pitti> ah, someone just published the d-i SRU for bug 1537136
<ubottu> bug 1537136 in systemd (Ubuntu Trusty) "ISST-LTE: no network after install due to interface order change" [High,Fix committed] https://launchpad.net/bugs/1537136
<pitti> but not systemd (where the chagne actually comes from)?
<xnox> pitti, people request package testing overrides in #ubuntu-release =) but you don't seem to be there at =)
<xnox> all
 * dholbach hugs seb128 
 * seb128 hugs dholbach back
<xnox> pitti, <apw> initramfs-tools is blocked for a test failure in linux (ppc64el).  this issue is a known intermittent failure which is kernel not initramfs-tools related
<xnox> <apw> i have asked for it to retry but the queue is really long, and the two fixes in this are blocking image generation and
<xnox> <apw> is preventing maas images from workgin, which is bleeding through to testing, preventing testing for the kernel
<xnox> <apw> i am therefore requesting we hint that test for initramfs-tools
<xnox> =)
<seb128> darkxst, I think you forgot to pilot out?
 * xnox wants kernel released too, to get d-i released, with bundled udebs with client fixes =)
<pitti> xnox: well, there's plenty of people who can add that override :)
<pitti> xnox: anyway, adding
<pitti> xnox: I can't influence the kernel, that gets controlled by the kernel team itself
<apw> xnox, the kernel hasn't been tested on baremetal in large part for the maas issues this initramgs-tools is attempting to fix
<xnox> pitti, but you are like the best and the most responsive =)
<pitti> hint added
<xnox> apw, hmm... you are running maas on s390x?
<xnox> apw, please ellaborate
<apw> xnox, we have been unable to test any as far as i know, and smosers fix is meant to be part of the solution there
<apw> xnox, my fix is related to alternate image builds failing
<apw> xnox, i don't think we are runnign maas on s390x, but its not me who does the automation there
<pitti> tjaalton: ah, did you release d-i? the systemd change should be released along then, as that's the actual change in d-i
<pitti> tjaalton: (udev-udeb)
<pitti> tjaalton: I didn't yet see confirmation from the reporter that it fixes the bug, but if it's still broken we can always re-open
<pitti> tjaalton: and I tested the -proposed netboot images to make sure they are okay
<tjaalton> pitti: the d-i one was just a rebuild, and there was another one needed which had to get in proposed
<pitti> tjaalton: right, a rebuild against the proposed udev-udeb
<tjaalton> pitti: so yeah the actual bug is still unverified by the reported
<tjaalton> -er
<xnox> doko, your "fixed" python3.4 looks "better" than the previous upload =/
<pitti> tjaalton: to make that change actually effective, as udebs get "collected" during d-i build
<tjaalton> yes
 * pitti releases
<sidi> Anyone ever programmatically mounted partitions? Trying to find a way to mount arbitrary partitions on top of an overlayFS partition (lower dir is root, basically I  wanna ensure that /dev, /run, etc are mounted as ro, and that /home is mounted as part of the overlayFS)
<marlinc> Is there a channel with people (trying) to run the latest development release as daily driver?
<xnox> marlinc, /j #ubuntu+1 i think
<xnox> marlinc, as long as you do not enable xenial-proposed it should be fine, unless you are talking about phone releases in that case #ubuntu-touch
<didrocks> doko: I guess you did see that https://launchpad.net/ubuntu/+source/python3.4/3.4.4-2ubuntu1 FTBFS, right?
<marlinc> Ah, thanks xnox. I'm not on proposed
<doko> didrocks, I guess you saw https://launchpad.net/ubuntu/+source/python3.4/3.4.4-2ubuntu2 before asking
<didrocks> doko: oh, launchpad didn't list it when I refreshed
<didrocks> great!
<didrocks> thanks doko :)
<marlinc> I've never in my life filled this many bug reports :P
<marlinc> I kind of like it
<seb128> hum
<seb128> Suppression de python3.4 (3.4.4-1) ...
<seb128> xargsÂ : l'option -s contient un nombre non valide
<seb128> Usage: xargs [OPTION]â¦ COMMANDE [ARGS-INITIAUX]â¦
<seb128> barry, doko, ^ known issue?
<seb128> Suppression de libpython3.4-stdlib:i386 (3.4.4-1) ...
<seb128> xargsÂ : l'option -s contient un nombre non valide
<seb128> dist-upgrading xenial
<barry> seb128: doko's had some recent uploads, but sorry i don't understand the french output ;)
<seb128> barry, it's close enough from the english words ;-)
<seb128> barry, invalid number used for the -s xargs option
<barry> seb128: ah.  i'm not aware of this problem, but doko is working on the package (i've seen a couple of uploads in the last day or so)
<seb128> while removing those python3.4 packages
<doko> seb128, which awk do you have installed?
<seb128> $ dpkg -l | grep awk
<seb128> ii  gawk                                                  1:4.1.3+dfsg-0.1                            i386         GNU awk, a pattern scanning and processing language
<seb128> ii  mawk                                                  1.3.3-17ubuntu2                             i386         a pattern scanning and text processing language
<seb128> doko, ^
<tjaalton> mterry: hi, do you have time to look at bug 1543659?
<ubottu> bug 1543659 in xserver-xorg-video-amdgpu (Ubuntu) "MIR: xserver-xorg-video-amdgpu" [High,New] https://launchpad.net/bugs/1543659
<seb128> doko, * 0            /usr/bin/gawk    10        mode automatique
<doko> seb128, well, try running the prerm/postrm manually and tell me what goes wrong
<mterry> tjaalton, sure
<doko> never saw this locally
<tjaalton> mterry: cool, it needs to move to fix images
<doko> pete-woods1, there is a duplicate package sphinx3 in the archive. can it be removed?
<seb128> doko,  libpython3.4-minimal install wants to remove findutils
<seb128> not sure I want to do that :p
<tjaalton> findutils breaks libpython3.4-minimal (<< 3.4.4-2)
<doko> pete-woods1, removed, no rdeps, pocketsphinx is the more recent package in the archive
<tjaalton> seb128: looks like python3.4 isn't needed anymore, so should be safe to let it go?
<seb128> tjaalton, yeah, it's just that I got " xargsÂ : l'option -s contient un nombre non valide" error on removal and doko asked if I could run the prerm manually to get debug info, so I tried to reinstall it
<tjaalton> yeah, the added breaks was related to that
<doko> anyway, afk now
<pitti> barry, slangasek: with the demise of the tech board I have lost the ability to approve https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only for xenial; slangasek, can you please do that? (I suppose you are in ~ubuntu-drivers somehow)
<Laney> RIP techboard
<barry> oh?
<pitti> barry: we all timed out about a week ago, it now needs sabdfl to pick candidates, then we can re-vote
<dholbach> pitti, shall I extend the members' terms by 3 weeks?
<barry> pitti: ah right, i remember seeing the call for candidates
<dholbach> that's probably the least amount of time required until we have a new TB
<dholbach> let me set it to 1st March
<dholbach> infinity, kees, mdeslaur, pitti, slangasek, stgraber: I extended your TB terms for another 3 weeks
<mdeslaur> dholbach: thanks
<pitti> dholbach: thanks!
<pitti> SIGSEGV
<Laney> $ gdb ./pitti
<nacc> slangasek: for a package that is in Debian experimental (e.g., libbson, libmongoc) that are not yet in Ubuntu, should I file a sync bug or a needs-packaging bug?
<xnox> Laney, maybe simply re-initialise matrix back to the known state of the 90s?
<xnox> nacc, request-sync from experimental.
<pete-woods1> doko: okay, I can't actually remember now, it's so long since we used it
<xnox> nacc, $ man requestsync
<nacc> xnox: thanks -- found more relevant documentation of the same on the wiki
<xnox> nacc, excellent =)
<dsmythies> The last couple of updates to the installation-guide package appear to have been done somewhere downstream from the Ubuntu master source at:
<dsmythies> https://code.launchpad.net/~ubuntu-core-dev/installation-guide/ubuntu
<dsmythies> When we publish the installation guide on help.ubuntu.com we prefer to work from the master source (we didn't the other day).
<dsmythies> Would be possible to get this situaiton corrected?
<xnox> dsmythies, i'm not sure what you mean. That branch is the master branch for packaging installtion-guide source package in ubuntu, which is then uploaded into the archive.
<xnox> and the generated pages are also published online. for a given series.
<xnox> that branch is now at xenial, and xenial guide is live now.
<xnox> dsmythies, what do you mean by "downstream"?
<xnox> dsmythies, and what would you like to be corrected?
<cjwatson> xnox: https://launchpad.net/ubuntu/+source/installation-guide/20160121ubuntu2 wasn't committed to bzr, nor were some previous uploads
<xnox> is there something wrong with the website vs the branch vs the .deb package?
<xnox> oh.
<dsmythies> The master bzr branch and the current package and the web site are not in sync
<xnox> sigh.
<xnox> dsmythies, yeap, i see that now.
<xnox> dsmythies, i don't have time to do this now, but i'll open a bug report to reconcile the lot.
<xnox> dsmythies, thanks for spotting this.
<dsmythies>  O.K. note: the web site is preliminary anyhow and with a disclaimer that stuff might be wrong.
<xnox> dsmythies, yeah. it's just there is a bunch of new stuff in it, and we do want as many eye balls on it as possible.
<dsmythies> See: https://help.ubuntu.com/
<dsmythies> xnox: O.K. I see bug 1543700
<ubottu> bug 1543700 in installation-guide (Ubuntu) "reconcile archive uploads with packaging branch" [Undecided,Triaged] https://launchpad.net/bugs/1543700
<xnox> dsmythies, yes.... i opened that bug.... and assigned to myself.
 * xnox is xnox
<xnox> dsmythies, but will not get to do it this week though =(
<xnox> -ENOTIME
<nacc> as I go through and file bugs for various PHP updates in anticipation of the PHP7.0 move (and removal of PHP5), is there a more efficient way to file the staged build bugs than using the launchpad web UI? apport seems to be more for reporting functional problems? I could script something using launchpadlib, but that seems like time I don't quite have right now :)
<cjwatson> if you want a scripted way of doing things with Launchpad, then launchpadlib is it
<nacc> cjwatson: ok :)
<nacc> cjwatson: i can c&p for most of the bugs, and it's probably good for me doing my due diligence, just wasn't sure if there was a more efficient way
<sabdfl> pitti, i have nominations, need to think through the short-listing, will ask TB for comments this weekend
<pitti> sabdfl: ah great, thanks
<nacc> slangasek: i assume it's ok for debian/tests/control to not understand staged dependencies (that is, i've only been modifying debian/rules and debian/control, since I figure during the bootstrapping, autopkgtest may be "known broken")?
<slangasek> nacc: yes
<pitti> nacc: it's indeed fairly easy; if you need some inspiration, http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L1745
<nacc> slangasek: great, thanks
<pitti> nacc: there are some oddities due to being bilingual, and you don't need the "blob" stuff
<nacc> pitti: thanks! i'll try and take a look at that!
<nacc> admittedly, doing it manually is making me consider each staged build and decide if it's really necessary :)
<nacc> which is probably good
<pitti> nacc: i. e. unless you have attachments, it's basically just the single createBug() call at http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L1778
<nacc> pitti: wonderful, that's probably exactly what i need
<pitti> nacc: https://launchpad.net/+apidoc/1.0.html#bugs-createBug
<nacc> pitti: thanks!
<roaksoax> 34/win 13
<pitti> cyphermox: hey, how are you?
<cyphermox> hey
<cyphermox> doing alright, you?
<pitti> cyphermox: I just found a little "one of these days" item on my list -- do you know about NM's captive portal detection by any chance?
<pitti> some Fedora guys mentioned that NM has done that for a long time already, but I've never seen it actually working
<pitti> did we disable that by any chance?
<cyphermox> it's not enabled by default
<pitti> it seems to be one of the values of the NM_CONNECTIVITY dbus properties
<cyphermox> but yeah, it's there, just it doesn't always work as well as some people would like... there was a rather long thread about this on ubuntu-devel@ some time ago
<pitti> cyphermox: well, having it in NM is one side, but I suppose that actually needs to be handled in nm-applet somehow, changing the icon and menu accordingly
<pitti> but I can't find anything with grep -Eri 'captive|portal' in n-m-applet
<cyphermox> not that much
<cyphermox> there has never been anything special for it in nm-applet
<cyphermox> not even in fedora
<pitti> like on Android you get a wifi notification symbol with a question mark
<cyphermox> yeah
<cyphermox> I suppose it could be added
<pitti> which opens some kind of randomly generated URL on google
<cyphermox> err
<pitti> I wonder what fedora uses for that then, this can hardly be a fedora patch to nm-applet?
<cyphermox> I don't think there is any special patch for that
<cyphermox> they might only enable it and let applications deal by itself with the actual DBus API value
<cyphermox> ie. CONNECTED_GLOBAL, or CONNECTED_LOCAL, or whatever
<pitti> NM also doesn't have a switch for it
<pitti> oooh! https://lists.fedoraproject.org/pipermail/desktop/2014-July/010061.html
<pitti> that says that it's handled in gnome-shell, not nm-applet
<pitti> bah! why would you put that there..
<cyphermox> because they use gnome-shell?
<pitti> yeah, I figure
<pitti> js/ui/status/network.js:        let isPortal = this._client.connectivity == NetworkManager.ConnectivityState.PORTAL;
<pitti> cyphermox: ah, got it, grepped gnome-shell now
<pitti> cyphermox: ok, nevermind then
<cyphermox> well, it could well be added to nm-applet
<cyphermox> it just isn't there yet, and I'm not sure what it could look like?
<mwhudson> infinity: ping
<pitti> wifi symbol with a question mark?
<cyphermox> ahh
<cyphermox> I wish we didn't need to create new icons :P
<pitti> I thought one could put an emblem on a standard icon
<pitti> like nm-applet does with the lock when you are on VPN?
<cyphermox> that's no longer composited together
<cyphermox> that used to be the case, but at some point I had to put the icons together, since indicators didn't support the necessary composited / passing a pixbuf
<cyphermox> or something to that extent
<pitti> cyphermox: as background, this came up when we quickly discussed how to enable DNSSEC on desktops, and apparently this was a necessary part (I forgot the details, though)
<pitti> cyphermox: oh, a shame
<cyphermox> well, perhaps that has changed
<cyphermox> or someone more knowledgeable might want to have a crack at it
<cyphermox> but yeah, before you do DNSSEC you might want to do some checking to know whether you really are online, or trapped behind a portal of some sort
<cyphermox> even though that won't get you that much more security either, since that portal could fake whatever it wants :)
<ginggs> doko, i  managed to get petsc to build on powerpc porterbox by skipping the 2 MPI process test (the 1 MPI process tests run fine)
<darkxst> pilot out
<darkxst> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<nacc> slangasek: question about what to do with a package for code that is EOL upstream? and we carry the supported upstream version of the same code in a different package
<slangasek> nacc: hmmm, request the package's removal?
<slangasek> nacc: which is 1) bug report against the package, 2) subscribe ubuntu-archive
<nacc> slangasek: i'm tempted to do that (and is what i did during my side build)
<nacc> slangasek: ok, thanks!
<nacc> slangasek: and i think the upstream versions of the deps that exist, ahve updated to use the new libs ... will note that in their bugs
<jderose> random question: any one able to get UEFI vms working with qemu? previously i used "-bios /usr/share/ovmf/OVMF.fd" for UEFI, but there seem to be problems booting into the install afterward
<cyphermox> jderose: yes, it does work well here
<jderose> cyphermox: you happen to have an example command line that works for you?
<cyphermox> sure
<jderose> cyphermox: in my case, it boots to the correct drive with the -cdrom option is supplied, but wont boot to it from subsequent calls that don't include the -cdrom option
<cyphermox> ah, I'm not changing the options from one boot to the next
<jderose> hmm, maybe i can work around it by always including -cdrom
<cyphermox> qemu-system-x86_64 -name efi-test-x86_64 -cpu core2duo -enable-kvm -monitor stdio -serial pty -boot menu=on -usb -m 1024 -vga qxl -m 1024 -bios /usr/share/qemu/OVMF.fd -net user -net nic -drive file=../iso/xenial-desktop-amd64.iso,media=cdrom -drive file=disks/efi-testdisk1.qcow2
<pitti> jderose: I regularly use that for testing, yes
<pitti> jderose: but I grabbed the OVMF.fd from upstream, not the packaged one (but that was a while ago, perhaps the packaged one works too now)
<cyphermox> jderose: this is what I'd use ^
<cyphermox> the packaged one did indeed have issues before, AFAIK they are fixed now
<jderose> cyphermox: pitti: thanks! yeah, i've been using the pre-build ovmf package since trusty or so, seems to work well
<cyphermox> jderose: I put my vm spawning commands in scripts that I published on bzr too: https://code.launchpad.net/~mathieu-tl/+junk/vm
<jderose> oh yeah, i'm only having trouble since upgrading from wily to xenial, forgot to include that bit
<jderose> cyphermox: i didn't realize you could emulate 4k logical sector size with qemu... very handy, thanks!
<cyphermox> jderose: that's... special
<cyphermox> it *used to work*
<cyphermox> now I mucked with it some earlier this cycle and it didn't seem to, but I may have been doing something wrong
<jderose> cyphermox: with what qemu version did it stop working?
<cyphermox> I don't know
<jderose> no worries, just curious :)
<cyphermox> :)
<mwhudson> taaalking of ubuntu-archive bugs ... https://bugs.launchpad.net/ubuntu/+source/golang-go.tools/+bug/1534313
<ubottu> Launchpad bug 1534313 in golang-go.tools (Ubuntu) "RM superseeded by golang-golang-x-tools" [Undecided,Confirmed]
<jderose> cyphermox: pitti: my hunch is my Xenial problem might be related to this - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918
<ubottu> Debian bug 764918 in ovmf "Please split into OVMF_VARS.fd and OVMF_CODE.fd" [Wishlist,Fixed]
<rharper> jderose: sudo qemu-system-x86_64 -enable-kvm -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash  boots the uefi bios in xenial;
<jderose> rharper: awesome, thanks! i think that's what i was looking for :)
<rharper> jderose: cool, though the bug you referenced is good background;  I was somewhat aware of this split but reading more to see if we need to make any changes,
<jderose> rharper: so you don't use the -bios option in how you set this up? that's how i always used to do this, but perhaps that's been outdated for a while
<nacc> slangasek: in the process of updating a package's explicit deps (e.g., php5-mongo -> php-mongodb) and also adding staged builds, can I do that in one bug (i.e., "php-monolog: bootstrap for PHP7") or would it be preferred to do it via two bugs?
<slangasek> nacc: one bug is fine with me
<nacc> slangasek: ok, thanks!
<nacc> mwhudson: thanks for the tweaks to a few of those bugs, apologies you needed to do that. Any advice for me on fields to check are generally correct? Don't want to make more work for anyone!
<mwhudson> nacc: i've entirely forgotten context
<nacc> mwhudson: all the php bugs going by you probably
<mwhudson> nacc: or alternatively you didn't mean to direct that at me :-)
<mwhudson> nacc: ah no definitely not me then :-)
<nacc> mwhudson: ah sorry!
<mwhudson> hodson vs hudson?
<nacc> yep :)
<nacc> and not paying close enough attention on my part :)
<sarnold> feel free to ignore what he does on bugs; most of the time it's just noise
<jderose> rharper: quick question: in your example, are you using sudo because you need write access to /usr/share/OVMF/OVMF_VARS.fd? as in the debian bug, not sure i totally understand the purpose of OVMF_VARS.fd. sort of seems like something that might need a per-VM writable copy
<rharper> jderose: yeah, temporarily;  you are free to copy that template and put that in per-user writable space and can drop the sudo and use kvm group
<rharper> the _VARS is a UEFI write space for pre-boot configuration (like which device to boot and a bunch of other stuff)
<rharper> still reading the bug, but in general we'll need to switch over and figure out of apparmor profiles and other things need to change
<teward> has the process for requesting FeatureFreeze exceptions changed, or is still relatively the same process?
<jderose> rharper: so just OVMF_VARS.fd needs to be writable by the process, not OVMF_CODE.fd?
<teward> been an eon since i've had to req. an FFe, so i'm prepping ahead of needing to, making sure I know what I need ;)
<rharper> jderose: that's my understanding
<rharper> the _CODE.fd is the runtime read-only UEFI code, the VARS are writable settings that the UEFI runtime inside a guest can modify
<jderose> rharper: okay, thanks! seems few on the internets yet know how to work with this new way of doing things
<rharper> it looks like libvirt will DTRT for you w.r.t making copies and keeping things per-user
<rharper> if you use qemu directly, then you'll need to make that copy yourself
<rharper> jderose: virtual uefi adoption goes just about as slow as physical uefi adoption =/
<jderose> rharper: yeah, i'm using qemu-system directly, but this should be a pretty minor change once i get it figured out
<jderose> hehe :D
#ubuntu-devel 2016-02-10
<roaksoax> pitti: so I looked further into this, and have found the following:
<roaksoax> pitti: http://pastebin.ubuntu.com/15006344/
<roaksoax> pitti: so, maas-proxy is squid3 being run by MAAS. So it seems squid3 does not have a systemd service file, but does have an upstart job. So I wonder if that's causing everything to disable things?
<roaksoax> pitti: correct myself. In maas-proxy postinst we disable squid3, and I wonder if that's affecting maas-proxy being enabled?
<roaksoax> pitti: ok, I think I may have found the issue: http://paste.ubuntu.com/15006739/
<roaksoax> pitti: i had to change ordering to get maas-proxy to work, however, maas-dhcpd and maas-dhcpd6 still show:
<roaksoax> maas-dhcpd.service is a disabled or a static unit, not starting it.
<roaksoax> maas-dhcpd6.service is a disabled or a static unit, not starting it.
<roaksoax> pitti: and my guess is because there's 2 for service units for the same binary package.
<roaksoax> pitti: i wonder if there's a bug in the processing that's not correctly processing both entries? Or should a binary package nver have 2 service units ?
<pitti> Good morning
<pitti> roaksoax: binaries can have as many services as they want; and the order of calling dh_* should beo completly irrelevant
<jrwren> are there any plans to update packaging guide to use git? http://packaging.ubuntu.com/html/packaging-new-software.html
<jrwren> man dh_make
<dholbach> good morning
<doko> did something recently change with alsa headers/libs?
<doko> https://launchpadlibrarian.net/237700070/buildlog_ubuntu-xenial-amd64.simon_0.4.1-0ubuntu7_BUILDING.txt.gz
<xnox> pitti, ubiquity uses http://start.ubuntu.com/connectivity-check
<xnox> and checks the checksum of that highly available file =)
<xnox> pitti, very similar to microsoft's connectivity check. apart from our text is longer =) and uses lorem ipsum
<pitti> xnox: right, but we don't seem to do that at all under unity
<xnox> pitti, yeah, i know. nor phone i don't think.
<xnox> pitti, conman will solve everything.
<xnox> =)
 * xnox giggles
<caribou> xnox: did anything on s390x enablement for makedumpfile ?
<caribou> xnox: I see that you marked the lp bug fix released
<xnox> commited
<xnox> caribou, failing to parse first question
<caribou> xnox: a bit fast, I was about to prepare the upload to debian,
<xnox> =)
<xnox> caribou, i am happy to sync things when they are built in debian. but that like takes close to 24h =)
<xnox> and today is my last working day for the week.
<caribou> xnox: that's fine, I'll do the debian bits & resync
<xnox> caribou, i'm sure there will be more work needed. cause e.g. bootloader on s390x doesn't prepare any devices for dumps =/
<caribou> or maybe wait a bit to see if it builds correctly
<xnox> does build https://launchpad.net/ubuntu/+source/makedumpfile/1:1.5.9-4ubuntu1/+build/8991792
<Mirv> can someone help me parse the problem at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-032/xenial/amd64/c/cantor/20160210_064645@/log.gz ?
<Mirv> I was thinking maybe the python-numpy that's breaking other tests in proposed, but then again the silo autopkgtests shouldn't be using proposed anymore
<doko> hmm, some -dev package dropped a dependency on libasound-dev
<Mirv> locally I don't have a problem installing the test dependencies on either xenial or xenial-proposed
<LocutusOfBorg> yofel, hi! I actually uploaded jreen in Debian a while ago, and got accepted yesterday
<LocutusOfBorg> I looked at the ubuntu package, and if agree I would like to fakesync it
<LocutusOfBorg> but I would like to ask you to give a quick look if possible
<LocutusOfBorg> the debian package is more complete, e.g. providing qt4 and qt5 packages
<Mirv> ah, not, if I've up-to-date xenial
<LocutusOfBorg> multiarch support
<Mirv> python3.4 is being removed
 * Mirv reads backlog in search of python3.4 breakage in xenial non-proposed
<xnox> Mirv, findutils has breaks on python3.4, thus if you have python3.4 from release installed, and try to install findutils that will fail.
<xnox> Mirv, and there is new enough python3.4 built in proposed, which i'm waiting to migrate over (autopkgtests are running)
<xnox> it's a subtle "Breaks: python3.4 (<< version in xenial-release" in findutils.
<Mirv> xnox: ah... so I need to wait for that since the silos don't use proposed. thank you.
<xnox> Mirv, yes. and cloud-images are broken, and doko has been fixing this with yesterdays uploads.
<xnox> just need to migrate now.
<pitti> meh, armhf test machines are still Qt'ed, after they've gotten perl'ed all yesterday and night
<xnox> Mirv, also it's a bug if silos do not use proposed.
<xnox> slangasek, ^
<pitti> they shouldn't use -proposed for running tests
<pitti> (for builds, yes)
<xnox> Mirv, do you see bugs in tests or builds?
<xnox> ah looking up i see it's tests.
<Mirv> xnox: tests, and yes that was just implemented
<xnox> Mirv, yeah, just wait =)
<Mirv> good things come to those who wait
<doko> Mirv, fix a ftbfs or two while waiting ;p
<Mirv> everyone should have one http://www.einval.com/~steve/DebianT/guinness-debian-open.gif th-shirt
<Mirv> I'll work on this breaking test script...
<LocutusOfBorg> Logan, ^^^^ (jreen pacage)
<doko> coreycb, pandas still fails its tests
<seb128> xnox, you said you might be able to help on porting aptdaemon to packagekit 1 ... any chance you find some time for that next week? ;-)
<xnox> seb128, like the night before feature freeze? =)
<seb128> xnox, if you like it this way, why not ;-)
<damascene> Hi, how much time Midori browser maintainers have before they can not switch to WebKit2 because of feature freeze?
<seb128> damascene, the feature freeze is on feb 18th
<seb128> they can still ask for an exception after that
<damascene> ok thank you seb128, I'll tell them to hurry up before feb 18th
<pitti> apw, stgraber: FYI, lxc/trusty/ppc64el is green again, I just found out why trusty/ppc64el didn't work (http://autopkgtest.ubuntu.com/packages/l/lxc/)
<pitti> apw: so you can un-mark this as known failure
<bdrung_work> cjwatson, i saw your ITP for git-build-recipe. cool!
<_hc> hey all, I'm a DD working on getting the Android SDK into Debian.  I want to make sure that these packages are also included in Ubuntu 16.04, so we're working to get everything in Debian before Feb 18th.  Its mostly there already, but for some reason, the packages are not getting auto-imported into Ubuntu.  I just wanted to check whether I'm missing something that's blocking them.  Here's the list: https://qa.debian.org/developer.php
<dholbach> _hc, "Not found"?
<sladen> presumably truncated by IRC at just the wrong point
<_hc> https://qa.debian.org/developer.php?login=android-tools-devel%40lists.alioth.debian.org
<_hc> dholbach: ^^
<cjwatson> I'm sure I've seen several of those getting imported
<cjwatson> bdrung_work: yw :)
 * cjwatson looks
<_hc> is debian qa just out of date?
<bdrung_work> cjwatson, is there an ETA when in can be used on launchpad?
<_hc> all of the android-platform-* source packages should be at version 6.0.0 now
<mitya57> _hc, android-platform-external-libunwind FTBFS on arm64 and thus stuck in xenial-proposed
<cjwatson> bdrung_work: Two weeks ago.
<cjwatson> https://blog.launchpad.net/cool-new-stuff/beta-test-git-recipes
<bdrung_work> cool
<dholbach> https://launchpadlibrarian.net/236936154/buildlog_ubuntu-xenial-arm64.android-platform-external-libunwind_6.0.0+r26-3_BUILDING.txt.gz
<mitya57> _hc, android-platform-system-core needs old binaries removed because it dropped some archs
<mitya57> And other packages depend on these two
<_hc> thanks for the info
<cjwatson> yeah, looks like some archive admin unwinding to be done here, I'll look
<_hc> looking at the FTBFS, its an odd one. is 16.04 using gcc 6?
<cjwatson> the arm64 build of android-platform-external-libunwind doesn't block anything in itself
<mitya57> No, gcc 5
<cjwatson> unless something build-depends on that
<_hc> yeah, some stuff bds on that
<cjwatson> let me clarify, unless something build-depends on that and would be a regression if not built on arm64
<_hc> also, we had to do two of these as staged uploads since there are circular dependencies, so we might need to do the staging in ubuntu too
<bdrung_work> cjwatson, is nest-part implemented?
<cjwatson> bdrung_work: not yet, that's the one major missing piece of the format
<cjwatson> on my list
<cjwatson> _hc: details?
<bdrung_work> cjwatson, rough ETA for that?
<cjwatson> _hc: we can inject build-dependencies if we need to do a bootstrap step
<bdrung_work> i use nest-part for audacity and vlc
<bdrung_work> i am curious to switch to git for vlc
<cjwatson> bdrung_work: don't have an ETA yet, need to sit and rewrite the code
<_hc> we have a ~stage1 version of two packages that only build certain libs.  Then we can build the other packages against that, then we upload the full version of the first package
<cjwatson> William brought up reasonable objections to my initial implementation attempt
<bdrung_work> cjwatson, can you ping me once it is there?
<cjwatson> bdrung_work: can you just watch blog.launchpad.net instead?  I'm not going to remember to ping individuals :)
<cjwatson> bdrung_work: or subscribe to the bug
<cjwatson> bdrung_work: (https://bugs.launchpad.net/git-build-recipe/+bug/1537579)
<ubottu> Launchpad bug 1537579 in git-build-recipe "nest-part not implemented" [High,In progress]
<cjwatson> _hc: which packages?
<_hc> seamlik: which packages needed the staged uploads?
<bdrung_work> cjwatson, I'll subscribe to the bug. thanks.
<cjwatson> _hc: and can you point me to the staged versions?  (ideally it would be possible to build those just by using DEB_BUILD_PROFILE=stage1)
<seamlik> android-platform-system-core and android-platform-build
<_hc> cjwatson: ^^^   seamlik actually did most of the work :)
<_hc> cjwatson: we are using git-buildpackage, so its all in git, if that is useful, or I guess debian-snapshot is another option.  in what form do you need those packages?
<cjwatson> _hc: really don't care
<cjwatson> whatever you have
<_hc> they are all here: https://anonscm.debian.org/git/android-tools/
<cjwatson> _hc: android-libunwind and android-libunwind-dev are intentionally no longer built for armhf, is that right?
<_hc> that is correct
<_hc> Google only supports building the SDK on i386 and amd64
<_hc> it could be ported without a lot of effort, but we want to start with i386 and amd64
<_hc> and get the whole thing in their first
<cjwatson> _hc: and android-libcutils, android-libcutils-dev, android-liblog, android-liblog-dev, android-libzipfile, android-libzipfile-dev, android-system-dev are now intentionally built only on amd64/i386?
<_hc> yeah
<seamlik> All of them are x86 only now
<cjwatson> I don't think any staging is needed; both android-platform-system-core and android-platform-build have built
<_hc> cool, that simplifies things :)
<seamlik> That easy?
<cjwatson> except for android-platform-build/arm64
<_hc> seamlik: did you see the FTSBS error? Its odd https://launchpadlibrarian.net/236936154/buildlog_ubuntu-xenial-arm64.android-platform-external-libunwind_6.0.0+r26-3_BUILDING.txt.gz
<cjwatson> because it b-ds on binaries from android-platform-system-core/arm64 that you just told me you were intentionally no longer building
<seamlik> Yeah I prepared an update
<_hc> ah, ok, we uploaded things in a different order
<_hc> so we'll fix that one
<seamlik> Oh, I mean an update for android-platform-build
<cjwatson> it's not a problem anyway, we don't really care if android-platform-build is harmlessly dep-waiting somewhere
<_hc> oh, I see, that FTBFS for libunwind is on arm64, I keep seeing that as amd64
<seamlik> I need to separate out Build-Depends-Indep
<seamlik> So that the B-D won't be uninstallable
<xnox> Laney, i hear vila wants to get brand new bzr into xenial =)
<Laney> we spoke
<cjwatson> _hc: should all be cleared out in a bit
<_hc> awesome, thank you
<_hc> also, at some point, we'll need to coordinate with Ubuntu people on the android-tools source package, since that is maintained separately in Ubuntu
<_hc> we've entirely replaced it in Debian
<_hc> it is ok if that is unresolved in 16.04
<_hc> they just Conflict:
<cjwatson> Yeah, I imagine you'll want to talk to the Ubuntu phone people, I don't know who's currently most relevant there
<_hc> I emailed a list of people I found in the changelog
<cjwatson> sil2100 would probably at least have an idea who to direct you to for that
<seamlik> I bet there's a channel for Ubuntu Touch?
<cjwatson> It has a surprising name
<cjwatson> #ubuntu-touch
<sil2100> _hc: we do use android-tools for our flashing tools for ubuntu-touch from what I know
<_hc> right
<sil2100> _hc: how did it get replaced in Debian?
<_hc> the android-tools source package is pretty out of date
<sil2100> i.e. what's the new package name?
<_hc> android-tools is a custom bunch of code grabbed from various git repos
<_hc> we've been packaging it so that there is one source package per git repo
<_hc> https://wiki.debian.org/AndroidTools
<_hc> the binary packages are now adb, fastboot, etc instead of android-tools-adb, android-tools-fastboot
<sil2100> _hc: ok, good
<sil2100> Let me fetch this doc and try to either start thinking about migrating our tools to use the new approach or at least forwarding it to the right people
<_hc> the one thing we will not be packaging is adbd, since that is meant to run on the Android device not on Debian/Ubuntu
<_hc> but of course Ubuntu Touch is the "android device", so it needs adbd
<_hc> but we welcome patches to our packages if they want to maintain adbd in this whole setup
<seamlik> adbd is a "device" program which uses "device" version of libraries, which means a lot efforts to make
<_hc> I gotta say, this room has always been quite responsive when I've brought issues here.  good to get stuff done :)
<seamlik> Is anyone making a tool to automate the translation of Android.mk to a usable Makefile? That really simplifies the maintenance
<sil2100> _hc: ok, noted :) Let me put that on my TODO list and try to take care of it in the nearest time-cycles
<cjwatson> pitti: Could you retry the various haskell-hoogle autopkgtests but in such a way that they use haskell-hoogle from -proposed?  They're all part of the same transition so won't land without the version in -proposed anyway
<xnox> cjwatson, is debconf's Default[armhf]: a thing, or is it some magic pre-processing?
 * xnox is failing to find authoritative document on how debconf templates can look like.
<pitti> $ run-autopkgtest -s xenial --trigger=jquery/1.11.3+dfsg-4 --trigger=haskell-conduit/1.2.6.1-1build1 --trigger=haskell-uniplate/1.6.12-4build1 --trigger=haskell-resourcet/1.1.7-1build1 --trigger=haskell-case-insensitive/1.2.0.5-1build1 --trigger=haskell-http-types/0.9-2 --trigger=haskell-vector-algorithms/0.7.0.1-3build1 --trigger=haskell-src-exts/1.17.1-1build1
<pitti> --trigger=haskell-blaze-builder/0.4.0.1-3build1 --trigger=haskell-parsec/3.1.9-4build1 --trigger=haskell-text/1.2.2.0-1 --trigger=haskell-vector/0.11.0.0-1 --trigger=haskell-wai/3.0.5.0-1 --trigger haskell-hoogle/4.2.43-3 haskell-hoogle
<pitti> cjwatson: ^ done
<asac> hmm. fresh xenial schroot hosted on a trusty box gives me: W: No sandbox user '_apt' on the system, can not drop privileges ... i think i heard chatter about brokenness due to sandbox user, but thought it was fixed by now.
<pitti> yay, armhf queue is mostly over the hump
<asac> or is this different?
<xnox> asac, on xenial hosts it is.
<pitti> asac: yes, first apt 1.0 it was broken, but that got fixed in apt pretty quickly
<pitti> this is now just a warning
<xnox> asac, either create _apt user on your host, or stop copying users from host inside the chroot.
<xnox> asac, or upgrade host apt to xenials one.
<xnox> right "trusty box".
<cjwatson> xnox: documentation is in debconf-devel(7); pretty sure your example is preprocessed.  what package is that in?
<cjwatson> pitti: thanks
<asac> hehe
<cjwatson> xnox: e.g. base-installer has a preprocessing script for this
<xnox> cjwatson, well choose-mirror uses that, and it has pre-processing. i was hoping to use same elsewhere.
<xnox> cjwatson, and it's all in perl... whatever happened to using m4 to preprocess things +)
<cjwatson> xnox: yeah you have to preprocess
<cjwatson> xnox: I thought you were under 30
<xnox> cjwatson, i shall use groovy script then.
 * xnox has weird m4 fetish i guess.
<asac> xnox: how do i best create the user so it will not hurt me when upgrading to xenial in april?
<pitti> asac: really, it should not hurt
<pitti> asac: if that actually breaks anything, it's a bug
<asac> pitti: do you have the current passwd line for that user in xenial?
<pitti> asac: yes
<pitti> cjwatson: green again
<pitti> libfile-slurper-perl/armhf too, that should be the last thing that blocks perl
<cjwatson> pitti: great, thanks
<pitti> emtpy armhf queue!
<cjwatson> $ grep -A1 adduser /var/lib/dpkg/info/apt.postinst
<cjwatson>         adduser --force-badname --system --home /nonexistent  \
<cjwatson>             --no-create-home --quiet _apt || true
<cjwatson> asac: ^- do that
<xnox> asac, adduser --force-badname --system --home /nonexistent  \
<xnox> 	    --no-create-home --quiet _apt
<xnox> pitti, right queue empty, but will still take hours to finish python3.4 tests =)
<asac> cool... /me runs that command
<pitti> xnox: yes, around 2.5 hours
<asac> cjwatson: pitti: xnox: thanks a lot. works perfectly!
<pitti> asac: OOI, what didn't work before?
<pitti> this really ought not to be necessary
<asac> pitti: i am on trusty box, created a  fresh xenial chroot, and then running apt-get update in the schroot i got:
<asac> W: No sandbox user '_apt' on the system, can not drop privileges ...
<cjwatson> pitti: hm, did you do that on all arches?  (hoogle)
<asac> i think that makes sense... maybe schroot could get a patch in trusty to do the magic
<xnox> ... which is a mostly harmless warning
<cjwatson> not seeing it in either http://autopkgtest.ubuntu.com/packages/h/haskell-hoogle/xenial/s390x/ or http://autopkgtest.ubuntu.com/running.shtml
<cjwatson> pitti: oh never mind, I apparently can't read
<asac> oh ok it wasnt an error. i was confused because i couldnt find the package that was in universe :P
<xnox> asac, did that warning prevent you from doing anything? or simply distaste of seeing it?
<asac> anyway. warning gone is even better
<asac> i thought it prevented me from using apt
<cjwatson> it's running on armhf, but maybe not on s390x?
<asac> but it didnt
<xnox> cjwatson, it could have completed on s390x and then there is 5 minute sync gap where one can see it nowhere
<pitti> cjwatson: I did, but it ran a bit later on armhf
<cjwatson> yeah, that just occurred to me
<xnox> not running, not in queue, and results are being "uploaded" =)
<pitti> :q
<pitti> cjwatson: looking on s390x
<cjwatson> pitti: fancy being a techboarder for me?  I'd like to enable https://bugs.launchpad.net/launchpad/+bug/1517510 for xenial, since the necessary LP support has been rolled out now
<ubottu> Launchpad bug 1517510 in Launchpad itself "Add xz-compressed archive indexes" [High,Fix committed]
<pitti> cjwatson: ah, how can I help with that?
<cjwatson> in "lp-shell production devel":
<cjwatson> xenial = lp.load('/ubuntu/xenial')
<cjwatson> xenial.index_compressors = ['gzip', 'bzip2', 'xz']
<cjwatson> xenial.lp_save()
<pitti> >>> print(xenial.index_compressors)
<pitti> [u'gzip', u'bzip2']
<pitti> current value looks expected
<cjwatson> yeah, that's the default
<pitti> cjwatson: ok, done
<cjwatson> excellent, thanks
<pitti> re-ran it with the print() and it's in
<pitti> \o/
<cjwatson> I think we can remove bz2 pretty soon, but I want to check that nothing obviously explodes, and I think I need to add xz handling of Translation-* to debmirror
<cjwatson> conveniently I adopted debmirror recently
<pitti> cjwatson: can precise already read xz, or does that not even use bz2?
<cjwatson> pitti: well, we shouldn't change existing stables here
<cjwatson> pitti: I think it could read xz though
<pitti> oh, *slaps forehead*, I did that on _xenial_
<cjwatson> we're a bit late in doing this
<pitti> cjwatson: i. e. let it bake on xenial for a bit, and bit by bit enable it on older releases after testing?
<pitti> I mean, merely building those in addition shouldn't break much, it's disabling bz2 which could
<pitti> right?
<cjwatson> I wasn't planning to change older series at all
<pitti> ok
<cjwatson> not least because for it to be useful we'd have to republish the release pocket
<pitti> I thought you wanted to get rid of the bz2 compression in LP
<cjwatson> which generally we try not to do
<pitti> ah, good pointn
<cjwatson> oh, no, that's negligible code, I don't care about that
<cjwatson> I just don't want to keep three compression methods around for a series for very long - if nothing else it slows down publication
<cjwatson> pitti: While you're doing me favours :-), could you add ~ubuntu-archive-robot to ~launchpad-buildd-admins?  That bot already has fairly comprehensive privileges, and it would be convenient to be able to cron a thing to stab the arm64 build farm
<apw> pitti, lxc> ack though the adt-matrix hints work the same way, they are for specific combinations only
<pitti> cjwatson: http://autopkgtest.ubuntu.com/packages/h/haskell-hoogle/ â all green now, all arches caught up
<pitti> apw: right; I meant, you should drop any hint for "lxc", we shouldn't have known regressions there any more
<cjwatson> pitti: Great, thanks.  Will keep an eye on excuses
<apw> pitti, ack
<pitti> cjwatson: added u-a-robot
<cjwatson> pitti: thanks
<coreycb> doko, saw that about pandas, I'll take a look
<seb128> Noskcaj, hey, your blueman update is still on top of e.u.c reports for xenial, do you plan to handle it/looks at the issue?
<seb128> bdmurray, do you have any news on getting the xenial retracers fixed?
<pitti> yay, perl landed
<cjwatson> pitti: oh good
<pitti> ~ 6000 tests, ugh :)
<caribou> xnox: makedumpfile built for s390x on debian
<doko> LocutusOfBorg, you synced x11-apps, but now it ftbfs on ppc64el: https://launchpadlibrarian.net/235789778/buildlog_ubuntu-xenial-ppc64el.x11-apps_7.7+5+nmu1_BUILDING.txt.gz
<LocutusOfBorg> I didn't sync it :)
<LocutusOfBorg> anyway, seems unrelated to my debian upload and I can't even retry the build
<LocutusOfBorg> ENOPERMISSION
<doko> meh
<juliank> sarnold: What's going on with #1531923 - it's getting really annoying now
<juliank> bug #1531923
<ubottu> bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed] https://launchpad.net/bugs/1531923
<juliank> silly ubottu
<LocutusOfBorg> doko, maybe the reason is the missing -std=gnu99?
<LocutusOfBorg> I have no access to porterboxes in ubuntu, and not core-dev
<juliank> The missing lz4 in main is preventing some serious APT bugs from being fixed
<mdeslaur> tyhicks: ^
<LocutusOfBorg> doko, going to sync mpi-defaults, changes are in debian
<LocutusOfBorg> mapreri, ^^^
<cjwatson> pitti: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-037/excuses.html - I'm looking at the bulk of this, but the "test in progress" thing on unity-scopes-api/ppc64el, how can that be cleared?
<pitti> cjwatson: ah, I had to purge the ppc64el queue this morning as ppc64el got two kinds of breakages
<pitti> I temporarily disabled it in bitney, but that doesn't apply to the train configs
<cjwatson> pitti: also, is there some equivalent of http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/amd64/ that also shows PPA runs?
<pitti> cjwatson: essentially, they need to be re-queued (using retry.cgi), I can deal with that
<cjwatson> ok, thanks
<pitti> cjwatson: no, there's no web UI for those results, that's suposed to be on ci-train
<cjwatson> pitti: it is eventually, but there's a lag
<cjwatson> which is annoying if one is trying to iterate on necessary triggers
<pitti> cjwatson: I took the i386 regression retry.cgi link next to it and changed the URL
<pitti> not that it'd help much, with this amount of red
<cjwatson> pitti: yeah, it needs some wider triggers in order to pass, I'm just trying to figure out what
<pitti> bbl, lunch
<Mirv> fun, systemd update on 14.04 caused screen to lock (I mean just normal screenlock, enter password to unlock)
<mdeslaur> Mirv: hrm, perhaps similar to bug 1543883 that sarnold experienced
<ubottu> bug 1543883 in systemd (Ubuntu) "screen blanked during systemd-logind upgrade" [Undecided,New] https://launchpad.net/bugs/1543883
<coreycb> doko, can we drop pandas 0.17.1-3ubuntu1 that is stuck in proposed?  I'd prefer to hold off until their next release.  too many intermittent test failures for big endian arches.
<cjwatson> pitti: ok, please could you disable xz on xenial again?  it's causing apt-ftparchive to crash, reason as yet undetermined
<pitti> cjwatson: ok, done
<cjwatson> thanks
<cjwatson> I have a big strace to stare at as time permits
<cjwatson> might just be that we need to build without liblzma for precise, but I need to work out why this didn't turn up on dogfood first
<cjwatson> maybe just an insufficiently large test case
<marlinc> Does anyone know if its possible to make the name specified with --bootloader-id when installing GRUB static? I set it when I installed GRUB but when the next GRUB update comes it gets overwritten
<marlinc> I use UEFI to boot between multiple operating systems
<LocutusOfBorg> hi xnox can I ask you the rationale for disabling mir on s390x (xorg-server?) I ask because I enabled mir on s390x for libsdl2-dev
<LocutusOfBorg> I don't get why libmir is built everywhere, but packages using it shouldn't use on some architectures
<xnox> LocutusOfBorg, because there is no mir on s390x.
<LocutusOfBorg> mmm and the library is built?
<cjwatson> hmm?
<cjwatson> libmircommon5                    | 0.19.1+16.04.20160204-0ubuntu1 | xenial          | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<LocutusOfBorg> libsdl2 has been built correctly there with mir support
<LocutusOfBorg> cjwatson, does this mean mir is available everywhere?
<cjwatson> it would seem to be but what do I know
<cjwatson> (it may well not work ...)
<LocutusOfBorg> exactly my point
<LocutusOfBorg> I would avoid to use it if it is broken
<LocutusOfBorg> and probably bother the maintainer about not building everywhere
<LocutusOfBorg> https://launchpadlibrarian.net/236307381/mir_0.19.1+16.04.20160204-0ubuntu1.diff.gz
<LocutusOfBorg> no mention in changelog
<LocutusOfBorg> infinity disabled it in 0.13.1+15.10.20150520.1-0ubuntu1
<LocutusOfBorg> so I presume now the porting is complete
<LocutusOfBorg> +  * Disable testsuite on powerpc until big-endian porting is complete.
<LocutusOfBorg> somebody re-enabled it and the testsuite is disabled now on big-endian
<LocutusOfBorg> http://bazaar.launchpad.net/~mir-team/mir/0.19/revision/2617.2.2
<cjwatson> pitti: is there any way at all that I can see the output of a ci-train test before bileto updates, maybe via snakefruit or something?
<cjwatson> doesn't have to be a web UI
<pitti> cjwatson: you mean more than the logtail on running.shtml?
<cjwatson> pitti: yeah, one that has finished
<pitti> cjwatson: CI train's britneys update every 30 mins  AFAIK; if you use staging, those update every 5
<cjwatson> pitti: it's more like every 60+ at the moment
<pitti> cjwatson: ah yes, you could look at the swift directory
<pitti> cjwatson: which silo is that?
<cjwatson> pitti: 37
<pitti> cjwatson: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-037?format=plain
<cjwatson> pitti: ah, perfect, thanks
<pitti> cjwatson: there's "xml" (but not clickable either) and "json" too if you prefer that
<cjwatson> pitti: yeah, this is fine
<pitti> cjwatson: welcome to the comfortable web 3.0 ! :)
<pitti> cjwatson: more seriously, it shouldn't be too hard to slap together some wgets or urlopen()s to map a silo, package, and arch to a nice and small "show status and log link" CLI output
<pitti> if that happens often
<pitti> you can show results for a particular package with e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-037?format=plain&prefix=xenial/amd64/u/unity-scopes-api/
<pitti> append "&delimiter=@" and you get only the results; the last line, with /log.gz and /results.tar gives pretty much everything one would want to know
<cjwatson> pitti: All right, I need deeper help here.  Can you see why my trigger in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-037/xenial/amd64/u/unity-scopes-api/20160210_150405@/log.gz is apparently insufficient?  Or do you have a convenient way to test complex sets of triggers like this?
<pitti> cjwatson: the triggers are fairly irrelevant for silos
<pitti> cjwatson: one idea is that this depends on something in xenial-proposed which hasn't landed yet
<cjwatson> pitti: In this case it needs a combination of all the stuff in the silo plus some things that are in -proposed
<cjwatson> Indeed, that
<pitti> cjwatson: PPA tests run against xenial plus the silo, not against xenial-proposed as well
<cjwatson> pitti: It needs at least libjsoncpp and capnproto, plus probably ubuntu-touch-meta
<pitti> as that is in many cases unintended and led to too many blockings
<cjwatson> pitti: So how do we disentangle this, since this stuff is needed in order to land those bits from -proposed?  Copy them into the silo?
<pitti> cjwatson: ah, so cleanes would probably be to land those first?
<cjwatson> pitti: We can't, the bits in the silo are part of landing those things :-/
<pitti> ah, tricky
<pitti> so we land one transaction via both a silo and regular -proposed uploads?
<pitti> yeah, would be better to land that all in one silo
<cjwatson> Well, part of it was an auto-sync from a month and a half ago
<cjwatson> So you know
<cjwatson> And then phone people never land anything other than via silos
<pitti> copying the -proposed packages into the silo  actually ought to work
<cjwatson> All right, I'll give that a go
<cjwatson> thanks
<jdstrand> pitti: hi! looking at excuses, I see that ubuntu-core-launcher is a valid candidate for 14 days, but it didn't migrate
<pitti> cjwatson: or I restart the tests manually with enabling -proposed on those
<pitti> cjwatson: might be easier?
<jdstrand> pitti: I didn't do that upload, but was planning one on top of that. is there anything special I/we should do?
<cjwatson> pitti: I think either way would work.  I can copy the packages, so let me try that first
<pitti> jdstrand: it breaks ubuntu-snappy, as per http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> jdstrand: so it won't land until ubuntu-snappy gets fixed/rebuilt/whatever to work with that ubuntu-core-laucher version
<pitti> jdstrand: presumably there are some Breaks:/versioned Depends:/library transition or something such?
<jdstrand> oh, I was unaware of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<jdstrand> pitti: thanks for the info. I'll let the snappy team handle that transition then
<pitti> jdstrand: to examine, start a xenial-proposed schroot (or chdist) and try to install ubuntu-snappy
<jdstrand> kyrofa: fyi, ^
<pitti> ack
<seb128> pitti, jdstrand, I think mvo was trying to get snappy binaires removed on powerpc/s390x so the new version migrates, unsure what's the status of that though
<jdstrand> I suspect that xenial needs a 1.7.3 upload of ubuntu-snappy
<jdstrand> but I'll let them handle it
<seb128> jdstrand, there is an update, it's blocked in proposed though because fails to build on powerpc/s390x
<seb128> it has been this way for a while though
<jdstrand> yeah, interesting. but the previous upload did build
<seb128> like since novembre, I guess nobody in the snappy team has slots to look at those archs
<jdstrand> based ontheir ppa (which doesn't include s390x, it looke like 1.7.3 will ftbfs on arm64
<seb128> :-/
<jdstrand> I know that is a target arch-- maybe they'll fix it all up in one go
<jdstrand> ok, I'm not touching that
<jdstrand> pitti, seb128: thanks again! :)
<bdmurray> seb128: The new version of gdb is running on them but we have had some issues with the Error Tracker. Things are running again though.
<seb128> yw!
<seb128> bdmurray, so we should start seing valid signatures/stacktraces for new retraces?
<bdmurray> seb128: I hope so but let me know if you see something amiss.
<tyhicks> juliank: sarnold has been tied up in other MIR security reviews
<tyhicks> juliank: there's still one MIR security review before it
<tyhicks> juliank: the good news is that it'll happen very soon
<xavigarcia> jhodapp: Hi! I think you pinged me yesterday, while I was already off...
<xavigarcia> jhodapp: was it about that focus and sound indicator bug?
<seb128> bdmurray, k, the daily view still has mostly backtraces without symbols but let's see if that improves in the next days when retracers do new ones
<bdmurray> seb128: we do have a queue of things to retrace at the moment due not accepting crashes for a bit
<seb128> k
<tmartins> hey guys! Anyone here is experimenting Neutron 8.0.0 b2 on Xenial ?
 * pitti re-enables ppc64el in britney
<LocutusOfBorg> ginggs, I'm gonna sync mumps
<LocutusOfBorg> debian has the delta
<slangasek> xnox: what silo was not using -proposed? AFAIK that would've required someone to manually change the setting
<xnox> slangasek, false alarm. for built proposed was used, it's just for autopkgtest proposed is not used, by default.
<xnox> well, magic is done there to try things, with -release only bias.
<ginggs> LocutusOfBorg: sure, go ahead
<LocutusOfBorg> thanks
<LocutusOfBorg> doko, stealing your tomahawk rebuild, because of the new jreen multiarch, I'm not sure it  is needed, but since a lot changed I prefer to be safe
<infinity> LocutusOfBorg, xnox: the Mir big-endian issues only affect the display server, not the client libs, so it's perfectly fine to *link* to Mir on ppc/s390x, even if an s390x mir display probably wouldn't work right if someone tried.  And having arch-specific deltas is a bit of a pain to maintain.
<LocutusOfBorg> so the next xorg-server can drop the delta? (that bit)? wonderful
<LocutusOfBorg> tjaalton, ^^^
<jderose> rharper: turns out qemu wants to open /usr/share/OVMF/OVMF_CODE.fd read-write also, so it seems you need per-instances copies of both OVMF_CODE.fd and OVMF_VARS.fd
<rharper> jderose: can you confirm that it made changes to the _CODE.fd ?
<rharper> that doesn't seem correct, maybe we can run it with a readonly parameter
<rharper> -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd
<rharper> jderose: try that
<rharper> should force a ro open on the CODE.fd instead of default rw open
<jderose> rharper: still working through my VM install, but thus far it hasn't modified OVMF_CODE.fd
<jderose> ah, good idea... i'll try the readonly option
<rharper> ok, it shouldn't so should be safe to run with ,readonly
<jderose> rharper: no luck... with the readonly option for OVMF_CODE.fd, it seems to break UEFI mode... it tries to PXE boot in BIOS mode instead of booting from the ISO in UEFI mode
<rharper> hrm
<rharper> that can't be right;  can you open a bug for that ?
<rharper> I'd like to track the right thing here
<jderose> yeah, not what i was expecting. oh, and after my previous VM install completing and rebooting, my per-instance OVMF_CODE.fd copy still hadn't been modified
<jderose> rharper: sure. think i should file it against qemu or ovmf?
<rharper> jderose: either, and we'll add an affects the other package
<rharper> it feels like ovmf
<rharper> as qemu did what you asked (readonly)
<jderose> true
<rharper> but it's also possible something funking is going on with the pflash emu ?
<jderose> rharper: i still haven't read through the entire thing yet, but this was linked in that debian bug, is quite useful - http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
<jderose> rharper: could be, although everything seemed to work fine when i used a per-instance writable copy of both OVMF_CODE.fd and OVMF_VARS.fd... which to my kinda suggests it isn't a general problem with pflash emulation
<rharper> jderose: well, I mean, the _CODE.fd is _supposed_ to be read-only; and when we mark it that way, the code doesn't behave the same
<rharper> that was the reason for the split in the first place
<rharper> someone misplaced a write in there somewhere =)
<jderose> gotcha
<rharper> jderose: did you order the pflash arguments with readonly first and then the writable ?
<rharper> that whitepaper mentions order mattering due to how it;s mapped into ram
<rharper> "This way qemu configures two flash chips consecutively, with start addresses
<rharper> growing downwards, which is transparent to OVMF."
<jderose> rharper: i used "-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd"
<rharper> and then the second one for vars
<jderose> oh, and i put the OVMF_VARS.fd -drive argument after the OVMF_CODE.fd" one
<jderose> yeah
<rharper> that seems correct
 * rharper tries locally
<jderose> just minus "readonly" onthe 2nd
<rharper> jderose: oh, can you reset your local _VARS.fd and try again ?
<jderose> sure
<rharper> I've seen "boot" behavior change after UEFI has updated the _VARS.fd
<rharper> qemu-system-x86_64 -enable-kvm -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,readonly,format=raw -drive file=local_vars.fd,if=pflash,format=raw -cdrom /home/rharper/work/iso/ubuntu-14.04.3-desktop-amd64.iso
<rharper> jderose: for a fresh _Vars file, that boots the iso fine for me
<nacc> slangasek: so, how worth it is it for me to reduce the number of packages needing to be altered in the bootstrap to the smallest set possible? I can do it, I think, just requires kind of starting over and vetting the process out again, to some extent
<slangasek> nacc: how big is the bootstrap set currently?
<jderose> rharper: ah yeah! it works for me now too. i guess some change in _VARS.fd caused something screwy before i tried the system-wide _CODE.fd with readonly
<rharper> jderose: yeah!
<jderose> rharper: thank you very much for your help on this! want me to still file a bug?
<rharper> no
<jderose> cool, thanks again
<rharper> you may need to run efibootmgr in the guest
<rharper> IIUC, you successfully installed
<rharper> the default boot device is going to be set to a disk after install
<rharper> you'd need to either use efibootmgr to control what to boot next time
<jderose> right. i believe efibootmanager is always installed in UEFI desktop and server installs
<rharper> or manually interrupt
<jderose> yeah
<rharper> and use shell to fix up
<rharper> jderose: thanks for testing =)
<jderose> np :)
<nacc> slangasek: I believe around 73
<nacc> slangasek: 73 packages, that is, including the eventual targets of the bootstrap
<slangasek> nacc: not sure what you mean by "eventual targets" :)  do you mean there are 73 builds total to be triggered, or 73 source packages that need to be built uncleanly for the bootstrap?
<nacc> slangasek: sorry, so the need for the bootstrap is circular dependencies between phpunit, doctrine and symfony (roughly). so 3 of the 73 src packages in that list are those ones. 70 src packages have to be built uncleanly, in order to get to that point (the way I did it originally)
<cjwatson> uncleanly as in against feature-reduced versions of their dependencies, or uncleanly as in source modifications?
<nacc> the former
<cjwatson> that's mildly vexing but not a huge problem
<nacc> i.e., staged builds
<cjwatson> source modifications are the main hassle
<cjwatson> can the starting three be built using just what's in the Ubuntu archive, or do they need binaries injected from somewhere to satisfy build-deps?
<nacc> yeah, that makes sense, there are some new packages and updated versions needed too, not sure if that would be in the same boat as "source modifications"?
<cjwatson> I only count source modifications that would not end up in the Ubuntu archive
<nacc> ah then there are zero of those -- in the cases i had to do source modifications for bootstrap during my ppa builds, i reverted them in the final version
<nacc> (above was necessary since i can't do staged builds in the ppa)
<cjwatson> I thought you just said there were three of those, phpunit, doctrine, symfony
<cjwatson> I mean source modifications for staged builds
<nacc> oh sorry, i misread!
<nacc> *not* end up in the archive
<nacc> even that, i think, is pretty small ... but i'd need to go look at my list again
<nacc> let me start over, though
<nacc> i was looking at removing php5 from the archive and moving php7 to main
<nacc> but that requires making sure everything can still build :)
<nacc> so there was a "tight" b-d loop between symfony, phpunit and doctrine ... and phpunit in turn is a b-d of many php packages so they can run their unit tests
<cjwatson> so, basically we want a sequence of operations that can take us from the current Ubuntu archive to the desired state.  it's fine to use a PPA for staging (though anything we use for this we'll want to be devirtualised and specially privileged, if the end result is going to be copied into the archive)
<nacc> right, that's what i'm working on doing now via bugs and debdiffs and then i'll provide in the bug my explicit sequence
<cjwatson> but the more that can be straight source copies and the fewer manual uploads need to happen, the less effort it is
<nacc> yep
<cjwatson> if necessary, we can also bootstrap from binaries in Debian
<cjwatson> the way we do that would be to do one build cycle in an Ubuntu environment where the first build takes Debian binaries as its build-deps, and then use the output of that build as build-dependencies for builds that end up in Ubuntu
<cjwatson> to make sure everything is clean and we aren't including stuff we can't rebuild
<cjwatson> so if the bootstrap is already done in Debian (I haven't checked) and we can save a lot of effort by starting there, that's legitimate
<nacc> I think I follow -- the issue here is that because we need to re-spin the binary packages so they refer to php7 as their deps (dh_php, dh_phpcomposer, dh_phppear updates) which hasn't been done in Debian
 * cjwatson nods
<nacc> but for many packages that occurs by updating pkg-php-tools and php-pear and then rebuilds
<cjwatson> I assume this isn't all architecture-independent code?
<slangasek> nacc: yeah, 70 packages that I can throw at the wall with no source modifications, not worth a lot of your time to reduce the size of this set
<nacc> slangasek: ok, that's good to hear :/ i was starting to get a little stressed trying to rework the flow
<cjwatson> slangasek: BTW do you know about bootstrap-package in u-a-t?
<cjwatson> from the sound of things may not be useful for this particular case, but it's newish and can be handy for things of this type
<nacc> cjwatson: well, the core php code (bits of the interpreter) is arch-specific, as it's compiled. But i think all the php pear/pecl modules are arch-independent
<nacc> cjwatson: in this bootstrap that means roughly i think 5-10 packages that are arch-specific
<nacc> cjwatson: but i'm not sure if that's what you were asking
<cjwatson> right, more than 0 was what I was asking
<cjwatson> since that definitely means it needs to go in a devirt ppa :)
<slangasek> cjwatson: I had not heard of this, I'll look thanks :)
<slangasek> devirt ppa> ah good point
<teward> for those with knowledge of sbuild, can sbuild run armhf builds on non-arm (amd64) host infrastructures?  does it use some type of virtualization to achieve it?
<cjwatson> teward: (a) yes (mk-sbuild --target=armhf can help) (b) it uses qemu-user-static
<cjwatson> teward: this is basically what LP did for virtualised armhf PPAs until last week, so same reliability issues apply
<teward> indeed...
<teward> cjwatson: so, --target=armhf is needed alongside --arch=armhf, or...?
 * teward knows how to make a 32bit schroot by passing --arch=i386, but isn't sure how to achieve this for arm
<nacc> cjwatson: slangasek: if you read the spec at https://wiki.debian.org/BuildProfileSpec, specifically, the example in "Build-Depends syntax extension (restriction formulas)" ... I believe the way to specify that a b-d should not be enforced in either build profile nocheck or stage1 is 'Build-Depends: foo <!nocheck !stage1>' rather than 'Build-Depends: foo <!nocheck> <!stage1>'. Does that seem correct to y
<nacc> ou? The phrasing in their example confused me, which led me to do it the wrong way for some packages, I think (and I'll go fix up the debdiffs now)
<teward> blah i should just read wiki pages
<teward> cjwatson: thanks
<slangasek> nacc: your reading seems intuitive to me, but I don't know what the code itself does
<cjwatson> nacc: That would mean "not nocheck or not stage1", which is unconditionally true - I think you want "<!nocheck !stage1>"
<cjwatson> hm, but they have a contrary example
<nacc> slangasek: yeah, i tested just now and i think i'm right and the wiki text of "if neither the profile stage1 nor the profile cross are active" is not exactly right. It should read: "In the example above, the package would depend on foo for i386 or arm, unless both the profile stage1 and the profile cross are active."
<nacc> cjwatson: right, so what you wrote is what i think it should be too
<nacc> but their example is wrong, i think :)
<nacc> or the english is off
<cjwatson> I'm not sure.  Run each one through sbuild -Pstage1 and see what happens?
<nacc> just tested it
<cjwatson> Er, --profiles=stage1
<nacc> yeah, it should be <!nocheck !stage1>
 * nacc spent some time just now thinking in english in CNF ... or trying to
<cjwatson> It would be less surprising to me to find that the example was wrong, than to find that the logic was dramatically different for negated restrictions
<nacc> yeah
<slangasek> yeah. my understanding is that conditions within a <> are ANDed, and separate <> blocks are ORed
<slangasek> glad to hear that the code agrees with our intuition ;)
<cjwatson> nacc: oh, and I've just realised that I was in fact agreeing with you above where I thought I was disagreeing with you.  As you were ...
<nacc> cjwatson: :) np
<nacc> i'll send an update to the wiki and see if debian picks it up
<teward> cjwatson: i have a very evil question - I have an RPi2, with Ubuntu on it; would it be possible to create an armhf build environment *on* that armhf infrastructure, so crosscompiling isn't necessary?  And if so, is that as simple as doing --arch=armhf instead of --target=armhf since it's native there?
<slangasek> teward: you don't even need to specify --arch in that case
<teward> slangasek: nice.  force of habit to do that though :)
<teward> i guess i'll start poking my rpi then to turn it into an (albeit really slow) builder
<slangasek> teward: just to be clear: mk-sbuild --target=armhf on amd64 gives you a cross-builder, which works for many things but not all, and is really fast.  mk-sbuild --arch=armhf gives you a cross-architecture, native builder (running everything under qemu), which is slower than a cross-builder and probably works for more things but still has various known failures (including anything using Qt).  And a na
<slangasek> tive chroot on RPi2 is probably about as fast as the ...
<slangasek> ... cross-chroot option, maybe faster, and should be able to build everything.
<teward> slangasek: most of the stuff being sent to the builder is headless, so meh
<teward> but yeah i'm likely going to pursue using the RPi as a builder.  Though, i have to make sure it's on a supported distro first, I think the RPi2 I have had MATE 15.04 on it, which EOL'd.
<sarnold> hey teward; my pandaboard destroyed an sd card under what felt like a light write workload.. setting up a cross-compile environment may give faster builds and be more robust..
<teward> sarnold: well it's a good thing i have a lot of SD cards, but we're talking one build a month on this thing ;)
<teward> i'm building the cross-compile env anyways
<sarnold> ah okay :)
<teward> sarnold: most of my stuff goes to the PPAs for arm building, after amd64/i386 builds fine, anyways, but in this case the PPAs arent a valid option (internal private builds that incorporate private repo sources that only exist here and can't get included in the PPAs)
<sarnold> teward: interesting, I hadn't heard that before.. I don't step much outside the simple and easy center :)
<teward> indeed
<teward> i've got a couple RPis here that rely on certain 'all' packages to be available from an internal private repo here ;)
<teward> because it's not publicly released yet
<teward> blah slow internet is slow
<cjwatson> er, yes, I conflated --target=armhf and --arch=armhf earlier
<dobey> sarnold: might be better to use an actual ssd/hdd if using the device as a builder, than relying on an SD card :)
<sarnold> dobey: yeah; of course that would go through a usb-sata interface.. also not ideal ;)
<sarnold> I was just using mine for irssi and occasional rtorrent use; now it's only irssi. heh.
<dobey> sarnold: well, if you have usb 3, it's not too bad
<sarnold> dobey: I must admit I never looked but ijust sort of assumed the pandaboard didn't have usb3 :)
<dobey> sarnold: well, yeah, pandaboard probably doesn't have much. but rpi2 has usb3 doesn't it? :)
<sarnold> dobey: ooh? nice. yeah. that'd be the way to go :)
<dobey> well not sure now. their web page doesn't have any actual specs
<teward> dobey: last I checked it's USB2
<dobey> it just says "4 USB ports"
<teward> USB3 would be blue I think?
<dobey> teward: it doesn't have to be blue, but they commonly are
<teward> i'll check once I replace the RPi2 image I have with the latest Ubuntu MATE one ('cause I like the GUI there, and need the GUI to make wifi config easier heh)
<dobey> engadget says 2.0 though
<teward> pretty sure it's 2.0
<hallyn> ok, so if package x (let's say numa :) has dh_makeshlibs -V, and package y (oh, let's say qemu) build-deps on that;  the implication is what?  Just that any *build* qemu from (say) y serious can't be installed on xenial without rebulding?
<hallyn> (which with ppas and backports isn't *really* an issue for us?)
<hallyn> or is it more?
<dobey> usb 2/sata bridge might still be faster than the sd card. not sure
<tmartins> Hey guys, any chance to have the latest Enlightenment LibEFL on Xenial ?
<dobey> tmartins: is it in debian already?
<tmartins> nop
<dobey> tmartins: seems the version in xenial is just a sync from debian; would probably be bets to get it into debian first. and hopefully it doesn't break e17
<tmartins> But, for example, DPDK is only available on Ubuntu...   =P
<tmartins> Mmm...
<hallyn> sarnold: ^ do you know offhand?  (about dh_makeshlibs -V implications)
<sarnold> hallyn: sorry, no, I rarely make changes that large to packaging
<hallyn> ok thx
<hallyn> stgraber: ?
<dobey> hallyn: in your example, it means if numa is newer in y than in x (assuming all the other libs are bin compat), that qemu built against the version in y, will indeed need rebuilt against the x numa, to install on x
<dobey> or both newer versions will need to be installed, to satisfy the deps
<dobey> at least, that is my understanding from what man dh_makeshlibs says
<doko> barry, why is the setuptools wheel not necessary anymore?
<dobey> i don't think that's an issue though, because we tend to maintain the "things must be rebuilt anyway" mindset
<hallyn> dobey: right;  it was an issue in debian bc they couldn't put the qemu packages into wheezy after a numa upgrade, but we don't do that.
<hallyn> so yeah i think we can just do it.
<hallyn> thanks!
<dobey> right, we always rebuild when sticking things in -updates or -backports, and generally try to keep version numbering which won't break the upgrade path
<hallyn> yay, so i'll enable :)  thx
<doko> ginggs, please could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html, removing the libdcmtk2-dev references, or verifying that these are obsolete (e.g. there are alternatives or provides)
<ricotz> doko, hi, could you pick up this aptitude merge -- https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6059699/+listing-archive-extra
<ginggs> doko, i'm looking, but i'm not sure what i'm looking at :)
<doko> ginggs, libdcmtk2-dev is a package which only exists as a binary package, without a source being built from. the other packages reference this package, so these references must be removed before we can remove the libdcmtk2-dev binary
<barry> doko: because we create the wheels at pip build time using the dirtbike rewheeling tool
<doko> that's dirty
<barry> well
<barry> not really
<ginggs> doko, so odin, for example has build-depends on libdcmtk-dev | libdcmtk2-dev | libdcmtk1-dev
<doko> sure, you can ignore this
<ginggs> the latest upload of dcmtk has libdcmtk-dev
<doko> ricotz, please could you ask a lp question to enable this ppa for s390x and ppc64el, and show the results for all these archs?
<ginggs> odil has libdcmtk-dev | libdcmtk2-dev
<ginggs> dcmtkkpp has libdcmtk-dev | libdcmtk2-dev
<ginggs> doko, ok libinsighttoolkit4-dev still depends on libdcmtk2-dev
<ginggs> LocutusOfBorg: do you feel like doing another merge of insighttoolkit4? 4.9.0-1 was uploaded
<hallyn> hey - so bug 1541736 requests bacula in x demotion to universe;  i could sync, but is a manual step needed for demotion, or will that happen automatically due to build-deps on universe pkgs?  (I assume it won't, and rather it will hang in -proposed)
<ubottu> bug 1541736 in bacula (Ubuntu) "Sync bacula 7.0.5+dfsg-4 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1541736
<ginggs> LocutusOfBorg:  except 4.9.0-1 in debian still depends on libdcmtk2-dev
<hallyn> nacc: I trust you've built+tested bacula from debian and found no problems in x?
<nacc> hallyn: right, i found no issues and our delta was all fixed upstream or due to being in main
<hallyn> nacc: cool - then we just need an archive admin to edumacate us on how to demote to universe
<ginggs> LocutusOfBorg, doko: but libdcmtk-dev provides libdcmtk2-dev https://anonscm.debian.org/cgit/debian-med/dcmtk.git/tree/debian/control#n73 so i think we a re all good
<ricotz> doko, can do, ppc64el is possible already
<sarnold> hallyn: I think I've heard before that they make a final pass through the bugs to look for "demote to universe" a week or so before release
<sarnold> hallyn: probably assign or subscribe to the ubuntu archive admin team to make sure it's on their list when they look :)
<hallyn> sarnold: does that mean we shoul djust do the sync and leave the result in proposed, or just leave the bug open wiating for them?
<hallyn> nacc: ^
<sarnold> hallyn: I like the idea of the sync and -proposed, and also leaving a bug open ;)
<hallyn> sounds good.  nacc: pls assign the bug to ubuntu archive team, i'll initiate the sync
<nacc> hallyn: will do
<hallyn> thx
<doko> ginggs, ta, thanks for the analysis. removing libdcmtk2-dev
<ginggs> doko: yw
<doko> mwhudson, please could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html ? packages referencing golang-testify-dev, not built anymore
<infinity> hallyn: I don't understand why that bug requests demotion to universe.
<infinity> hallyn: There's literally no explanation, and it's seeded in supported for all flavours (including ubuntu).
<infinity> nacc: ^
<jtaylor> infinity: is glibc update stillon the schedule?
<infinity> jtaylor: Yep.
<smoser> hey.
<smoser> i need some help
<smoser> i have a system that is up.
<smoser> ssh running
<smoser> xenial
<smoser> another system attempt ssh in.
<smoser> another system attempt ssh in.
<infinity> Password or key auth?  If the latter, using insecure keys which are disabled by default in Xenial?
<smoser> ssh client looks like this:
<smoser>  http://paste.ubuntu.com/15010918/
<mwhudson> doko: i don't know anything at all about any of those packages
<mwhudson> but i can try and figure stuff out i guess :-)
<mwhudson> infinity: how's the head today?
<doko> mwenning, that would be appreciated
<doko> mwhudson, ^^^
<sarnold> smoser: similar-looking bug report https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1534792
<ubottu> Launchpad bug 1534792 in openssh (Ubuntu) "unable to connect" [Undecided,Incomplete]
<infinity> mwhudson: Wobbling about atop my neck, more or less as it's meant to.
<mwhudson> infinity: shall we talk go toolchains vs lts releases then?
<smoser> sarnold, even telnet 22 i get just dropped immediately
<smoser> Connection closed by foreign host
<smoser> i *can* ssh from that system to itself either by localhost or by ip address
<mdeslaur> xnox: wow, 35%!! /me hugs xnox
<nacc> infinity: i apologize, still learning and was told to simply put it in the bug report. Will work on the seed changes
<sarnold> smoser: actually that's pretty good -- that's a -way- simpler problem to debug :)
<smoser> oh . yeah. the telnet.
<nacc> smoser: how do i go about updating the seed to not refer to bacula?
<infinity> mwhudson: Will you be around in an hour?  I need to get some paperwork out of the way today before the east coast of the US takes off.
<mwhudson> infinity: yes
<infinity> mwhudson: Shiny.
<rcj> slangasek, xnox: I have an upstart/mountall question.  Trying to fix up a container environment that has replaced mountall and isn't getting timing for upstart emits correct (cloud-init jobs start out of order as a result).
<smoser> nacc, you can make a change to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.xenial/files
<smoser> and submit a merge proposal
<rcj> they have http://paste.ubuntu.com/15011062/ for mountall.override.  Talking with smoser I learned that 'filesystem' shouldn't be emitted until after '/' is rw and that doesn't occur until after all jobs depending on '/' (when RO) complete.  So without 'mountall(1M)' in the picture, what is the right way to emit signals to replace it?
<mwhudson> xnox: https://bugs.launchpad.net/ubuntu/+source/golang-github-aws-aws-sdk-go/+bug/1534346 links to your ppa but you've deleted all the packages (and so build logs)?
<ubottu> Launchpad bug 1534346 in unity-scope-snappy (Ubuntu) "FTBFS with golang-go 1.6 beta2" [Undecided,New]
<mwhudson> doko: oh, golang-testify-dev is now golang-github-stretchr-testify-dev
<mwhudson> is there a similar nbs page for debian?
<nacc> smoser: thanks
<mwhudson> because i'd be really surprised if any of these packages had a delta
<hallyn> infinity: the demotion is just so that we can drop all delta with debian;  i.e. recommend mt-st - really that's the only one i see offhand
<infinity> hallyn: Is that worth dropping support?
<mwhudson> er but golang-github-stretchr-testify-dev Provides: golang-testify-dev
<mwhudson> doko: i think golang-testify-dev can in fact be removed safely
<mwhudson> doko: because the new golang-github-stretchr-testify-dev package has "Provides: golang-testify-dev"
<mwhudson> doko: is that the sort of conclusion you wanted me to reach? :-)
<doko> mwhudson, please file an isss
<doko> mwhudson, please file an issue even
<mwhudson> doko: on https://launchpad.net/ubuntu/+source/golang-testify ?
<doko> yes, please
<hallyn> infinity: as in security fixes i guess?
<hallyn> (imo yes, but i neither use nor know anyone depending on bacula)
 * hallyn does wonder why mt-st is not in main
<mwhudson> doko: https://bugs.launchpad.net/ubuntu/+source/golang-testify/+bug/1544291 (i subscribed ~ubuntu-archive, anything else needed?)
<ubottu> Launchpad bug 1544291 in golang-testify (Ubuntu) "please remove golang-testify-dev package" [Undecided,New]
<hallyn> only bugs against htat baby are requests for syncing
<hallyn> nacc: was there anything other than mt-st that was cause for demoting bacula?
<hallyn> kirkland: what is your view on bacula support for server?  do we care whether it is in main?
<nacc> hallyn: we don't want to support it anymore, afaict, kirkland has already acked demoting it
<hallyn> kirkland: could add a comment to https://bugs.launchpad.net/ubuntu/+source/bacula/+bug/1541736 acking demotion?
<ubottu> Launchpad bug 1541736 in bacula (Ubuntu) "Sync bacula 7.0.5+dfsg-4 (main) from Debian unstable (main)" [Wishlist,Fix released]
<smoser> ok. for my ssh bug above.
<smoser> if i am pinging the remote host or have ssh'd to it, then i can initiate an ssh connection fine.
<infinity> smoser: Broken stateful firewall?
<smoser> i'm guessing its got something to do with
<smoser>  From 10.7.10.1: icmp_seq=11 Redirect Host(New nexthop: 10.7.2.103)
<smoser> http://paste.ubuntu.com/15011341/
<smoser> what i have is a flat network 10.7.0.0/16
<smoser> and on that is a maas system. when it installs nodes it tells them that it is their gateway (10.7.10.1) and that they have a /26 network under 10.7.10.0/
<smoser> i've another host with almost idential networking (10.7.10.62 instead of 10.7.10.61) but running trusty.  i've also run other ubuntu with this fine.
<rharper> working on the strongswan merge for xenial, adding virtual packages to handle the dist-upgrade, when I debuild -S the source, lintian spews many of these: https://lintian.debian.org/tags/not-binnmuable-any-depends-all.html  ...  I found this discussion: http://comments.gmane.org/gmane.linux.debian.devel.mentors/72433 and not sure what, if anything I should do in my debian/control file to address the warning/errors
<smoser> running sshd in the foreground with :sudo /usr/sbin/sshd -D -d -d -d -e
<mwhudson> rharper: i thiiiiiiiiiink but hardly know for sure that those warnings don't really apply for ubuntu
<smoser> basically doesn't see it getting a connection
<smoser> but tcpdum pdoes show some data.
<smoser> tcpdump port 22 -vv shows:
<smoser>  http://paste.ubuntu.com/15011373/
<rharper> mwhudson: yeah, I tried the suggestion (using (= ${source:Version}) instead but that didn't seem to help; but I _really_ don't understand what's going on w.r.t the warning
<rharper> the package builds fine in my sbuild and works when installed etc;  but there are enough of the warnings (due to all of the virtual packages) that it fills the screen and demands some attention
<mwhudson> rharper: i think the warning is about something that will go back in a situation that does not occur in debian
<mwhudson> errr
<mwhudson> *does not occur in ubuntu*
<mwhudson> rharper: https://wiki.debian.org/binNMU
<rharper> thanks
<mwhudson> rharper: we don't have binary uploads at all
<rharper> btw, google says no when I tried to search with "${source:Version}"
<rharper> which I thought was funny
<rharper> trying to google to find out why google does't like source:Version
<rharper> was also fun and fruitless
<rharper> searching for ource:Version, got google to auto search for source:Version for me
<rharper> did you mean this? (yes, I did, but you wouldn't let me search for that!)
<mwhudson> lolz
<rharper> mwhudson: ok, yes, I'll ignore those and go back to wondering why ppa build of the successful sbuild fails
<cherylj> Is there someone around who could help me with an ssh issue on xenial?  I'm seeing that when I run ssh  <host> <command> I get the correct output, but if I run ssh -t <host> <command>, I get nothing
<cherylj> See:  http://paste.ubuntu.com/15011347/
<smoser> cherylj, that is interesting.
<smoser> as i was just above typing ssh issues too
<smoser> fun
<mwhudson> cherylj: fwiw i can't reproduce that sshing into a xenial lxd
<mwhudson> but i don't really know what that indicates
<smoser> although mine fail with connection closed even on telnet 22
<cherylj> mwhudson: yeah I provisioned a new xenial machine and couldn't recreate.
<cherylj> mwhudson: this is a machine that was provisioned through juju
<mwhudson> cherylj: oh awesome
<rharper> well
<rharper> hehe
<rharper> obviously it was *jujus* fault =P
<cherylj> I have no idea what to look at that could cause the difference
<cherylj> :P
<smoser> cherylj, and mine was provisioned with maas
<mwhudson> i guess you could diff /etc/ssh/sshd_config on the machines
<mwhudson> and check the package versions are the same
<smoser> admittedly i have kind of funky networking. but funky  networking that works fine with trusty.
<cherylj> mwhudson: the package versions are the same
<mwhudson> cherylj: can you log in ok with ssh?\
<rharper> wouldn't ssh client complain somewhere about failed psuedo-tty allocation ?
<cherylj> mwhudson: yes
<rharper> -t requests one
<mwhudson> hmm
<mwhudson> cherylj: ssh -vvv ?
<smoser> yeah. add some -vvv
<cherylj> I did that, let me paste the diff
<mwhudson> and look for logs on the server?
<smoser> or run the daemon in the foreground with '/usr/bin/sshd -D -d -d -d -e'
<rharper> different port though
<rharper> don't mess with the working one =)
<smoser> i'm stil kind of hoping cherylj has my problem too. and just doenst know it.
<smoser> does telnet 54.179.131.88 22
<slangasek> rcj: replaced mountall> aigh it burns
<smoser> give you a ssh prompt ? or just drop it.
<cherylj> mwhudson: the /etc/ssh/sshd_config is the same for the two machines
<mwhudson> cherylj: i guess that's not very surprising but oh well
<mwhudson> cherylj: -vvv?
<cherylj> mwhudson: success case:  http://paste.ubuntu.com/15011479/
<cherylj> mwhudson: failed case:  http://paste.ubuntu.com/15011482/
<mwhudson> cherylj: huh it almost looks like a race between output and exit status?
<cherylj> mwhudson:  yeah, I was wondering about that
<mwhudson> cherylj: have you tried silly things like tacking "; sleep 1" on the end, or running some command that has side effects on the system so you can see if it's being executed at all?
<cherylj> mwhudson: ha!
<cherylj> $ ssh -t ubuntu@54.179.131.88 "lsb_release -c; sleep 5"
<cherylj> Codename:	xenial
<cherylj> Connection to 54.179.131.88 closed.
<rharper> hrm, why might i386 build fail when x86_64 succeeds  (failure in linking)
<mwhudson> cherylj: i'm fairly sure that's supposed to be impossible :(
<cherylj> mwhudson: sounds like it's time to open a bug?
<mwhudson> yeah, i guess
<cherylj> but I have no idea why it's different on this machine vs another
<mwhudson> is it reproducible at all>?
<cherylj> mwhudson: yes, we hit it in CI consistently
<mwhudson> cherylj: oh, it's simple then: CI is infested with malicious demons
<cherylj> of course, why didn't I think of that!
<rharper> mwhudson: hehe
<rcj> slangasek, it's a container environment that runs linux in a opensolaris (joyent smartos) zone
<mwhudson> cherylj: still at least a reproduction case makes actually fixing the bug feasible
<mwhudson> cherylj: when did the bug start?
<cherylj> mwhudson: I need to look at the CI logs to see when we started hitting it
<cherylj> give me a few
<mwhudson> last openssh upload was about three weeks ago
<rcj> slangasek, I have asked if they can stop diverting around the real mountall but that may not be possible in the current environment
<slangasek> :/
<rcj> I've tried rewriting their mountall override but haven't found something that works (as I'm taking shots in the dark) so mostly I end up with a container that doesn't boot (deadlock?) and I have to start again.  Thus the question to someone that knows what's going on with upstart/mountall and could say if it's even possible to do this in an upstart job without mountall
<nacc> slangasek: ok, i'm on my last 3 packages1
<nacc> s/1/!/ ;)
<nacc> slangasek: need some help/advice on one of them, if you have a second, though
<slangasek> nacc: hit me
<slangasek> rcj: so I believe it is possible and the devil is in the details
<nacc> slangasek: ok, so php-doctrine-cache-bundle BDs on php-symfony-doctrine-bridge ... php-symfony-doctrine-bridge BDs on php-doctrine-bundle which BDs on php-doctrine-cache-bundle. In my PPA I made an alternative autoload.php.tpl (which i can do with the staged build), but basically i need to have the stage1 php-doctrine-cache-bundle binary not depend on php-symfony-doctrine-bridge
<nacc> slangasek: oh ... i wonder if i could have two version of the binary package in the ocntrol file, toggled by Build-Profiles?
<slangasek> nacc: profile qualifiers can be applied to hard-coded dependencies listed in debian/control, not just to build-dependencies
<nacc> slangasek: oh! that's not mentioned on the wiki page :)
<nacc> easy enough then
<slangasek> nacc: I don't know that you can toggle the whole stanza, but it should work for the evaluation of the binary control files
<nacc> ok, i'll test that now
<slangasek> nacc: obviously, test this to make sure I'm not blowing smoke :)
<nacc> slangasek: :)
<slangasek> nacc: if that fails, option 2 is to not hard-code this dependency in debian/control at all, but move it into a substvar that's generated from debian/rules in a profile-dependent manner
<rcj> slangasek, I'll pursue the details through a bug rather than IRC.  Thanks.
<nacc> slangasek: sigh, it *does* work, except this package is also using dh_phpcomposer and composer.json specifies the same dependency :/ would it be appropriate for me to not use the var in stage1 and list out the other deps manually in the control file?
<slangasek> nacc: for stage1, hack it any way you like that gets you the proper result ;)
<nacc> slangasek: heh
<slangasek> nacc: and if the Debian maintainer has an opinion about the ugliness of the hack, you can negotiate with them later.  But I absolutely don't care :-)
<mwhudson> infinity: how's the paperwork?
<mwhudson> infinity: i'm going to disappear in 2.5 hours or so and i need to do some afk stuff before then
<nacc> slangasek: ok, I think I have my list of bootstraps filed as bugs and sequenced. WOuld it be worth us interlocking on that list now, or do you want me to only ping you or another admin once i have the full list written out?
<nacc> full list = 400+ packages, that is
<infinity> mwhudson: I'm aroundish now.
<mwhudson> infinity: \o/
<mwhudson> infinity: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1536882 https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15InTrusty
<ubottu> Launchpad bug 1536882 in golang (Ubuntu) "upload golang1.5 package for trusty" [Undecided,New]
<infinity> mwhudson: Right.  Want to mumble or something?
<mwhudson> infinity: sure, although i don't think i actually have mumble installed
<infinity> mwhudson: Or a hangout...
<mwhudson> would be easier
<infinity> mwhudson: Not picky.
<mwhudson> hangout then
 * mwhudson can't remember how to start a hangout
<mwhudson> oh there
<mwhudson> infinity: i've invited the canonical you, i think
#ubuntu-devel 2016-02-11
<nacc> slangasek: actually, for those packages that only require sed, you mentioned i can hve one bug that lists them all. Should it have a debdiff for each package?
<slangasek> nacc: I don't remember discussing sed... we talked about no-change rebuilds, not quite the same thing?
<nacc> slangasek: right, so there's one set of packages that are nochange
<nacc> but then once the bootstrap is done for phpunit/symfony/doctrine, there's a few hundred pakcages that at least on first view build with a  simple sed of their d/rules and d/control files to go from php5-* to php-*
<slangasek> ah
<nacc> i can do a bug per package, but we talked about that being overkill probably
<slangasek> nacc: I'm happy with a flat list of those packages in a single bug, provided you have already tested on your side that running the sed over those packages gives a result that's both buildable and installable
<nacc> alright, i'll work on that next
<slangasek> and I'll put your name in the changelog for all of these uploads ;)
<nacc> slangasek: 100% on board with that :)
<robert_ancell> how often does the proposed migration run?
<slangasek> robert_ancell: "as often as it can"; it's on a 1 minute cron, but individual runs take longer than that and can take /much/ longer depending on what all is clogging up -proposed
<slangasek> the current britney run started 1 minute ago, however
<robert_ancell> slangasek, ok, cool. The excuses showed it last ran ~25 mins ago, was wondering when the next run would be
<robert_ancell> :( missed that run. Maybe in another 25mins...
<cjwatson> Laney: I forgot to say, the improved uncompressed index files stuff is on LP production now.  Could you please retry your DEP-11 client?
<cherylj> mwhudson: just FYI - I think the juju env I was in was using old xenial images
<cherylj> mwhudson: I rebootstrapped specifying "daily" images, and I don't see the same ssh -t problem
<alexlist> some context to https://bugs.launchpad.net/debian/+source/squid3/+bug/1544400
<ubottu> Launchpad bug 1544400 in squid3 (Ubuntu) "squid3: systemctl reports squid is running when there is a bungled squid.conf and it has exited." [Undecided,Confirmed]
<alexlist> 1) install squid3 (wily)
<alexlist> 2) systemd is able to start/stop squid3
<alexlist> 3) change the config to make squid startup fail
<alexlist> 4) neither manual nor systemd startup of squid3 work
<alexlist> 5) fix the config
<alexlist> 6) manual startup works, but systemd is not able to start squid again
<alexlist> This is really hard to reproduce and find. The bug report contains a link to the respective Debian bug...
<sarnold> alexlist: please paste that into the bug report ;) that's far from obvious..
<chiluk> are any launchpad ops awake?
<chiluk> if so i'd appreciate a launchpad op take a look at getting https://launchpad.net/ubuntu/+source/ceph/0.80.11-0ubuntu1.14.04.1  published..
<alexlist> sarnold: done
<dholbach> good morning
<Mirv> pitti: ppc64el autopkgtests seem stuck, same 16 "in progress" as in the evening at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-032/excuses.html
<pitti> Mirv: ppc64el was down Tue and yesterday, I had to kill a few jobs; I'll put them back
<pitti> Good morning
<pitti> meh, the workers are all down again
<doko> kirkland, https://launchpad.net/ubuntu/+source/ssh-import-id/5.0-0ubuntu1  ftbfs, now for nearly two weeks
<pitti> ok, this new cron job should revive the ppc64el workers every night until the images get fixed for good
<mwhudson> cherylj: oh ok
<mwhudson> cherylj: i guess that's a good-ish outcome
<pitti> doko: err @ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gccgo-6
<pitti> doko: I don't think gcc-go is supposed to build gcc-6-base or libgcc1?
<Mirv> the autopkgtest queues seems respectably big again
<doko> pitti, it is
<pitti> Mirv: yeah, due to ^
<doko> split-stack support for s390x
<pitti> doko: but won't they flip between gcc6 and gccgo-6 sources then?
<doko> we won't have a gcc-6 source in xenial
<pitti> well, still
<doko> ?
<pitti> we do have libgcc1, and it should come from our default C compiler, not from a non-default Go  compiler
<LocutusOfBorg> ginggs, wilco
<doko> same thing as for gcc-4.8 / gccgo-4.9 in trusty
<pitti> doko: so why is this?
<doko> pitti, libgo9 needs libgcc1 (>= 6)
<doko> pitti, if you would like to spend time on toolchain maintenance, maybe better work on demoting gcc-4.8 and gcc-4.9?
<pitti> well, I just asked a question, as this is by far not obvious..
 * pitti adjusts britney's hack for not triggering $world on gccgo-6 then
<doko> I even verified that the new libgcc1 is not empty ;p
<pitti> ok, hack in place and queues flushed
<Laney> cjwatson: Oh yes, I noticed - and it tickled a bug in the client which I fixed - thanks!
<pitti> Laney: sigh @ workers dying again -- what is it now, auth failure towards swift??
<pitti> plus the usual acting up of lcy01 during image rebuilds, but that's known
<Laney> pitti: BadStatusLine?
<pitti> some network glitch I presume
<pitti> swift list works fine on wendigo, I'll just restart and pretend I didn't see it the first time
<Laney> la la la
<Laney> hmm, how do I get debmirror to mirror Components and icons?
<ricotz> doko, hi, I am not allowed to get more archs enabled for this aptitude builds -- https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6059699/+listing-archive-extra
<doko> ricotz, ok, that looks fine
<ricotz> doko, thanks
<ricotz> doko, ah, do you mind making me admin too in https://launchpad.net/~libreoffice/+members
<doko> please ask Sweet5hark
<ricotz> yeah did so too (let's when isn't away anymore)
<doko> pitti, please ignore the ruby-rjb autopkg test failure; now reported to debian as well
<ricotz> doko, also could you delete the superseded "gcc-6 - 6-20160117-1ubuntu1" from https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+packages
<doko> when I have a new version, yes
<pitti> doko: ok, adding a hint; OOI, do we aim for jdk8 in xenial? i. e. ignore some packages which get broken by it?
<pitti> doko: (asking because of jsurf-alggeo
<pitti> doko: ah, that's already hinted
<ricotz> doko, there is a new version "gcc-6 - 6-20160206-0ubuntu11"
<pitti> doko: libo/s390x is unrelated, I'll ignore that
<ricotz> doko, this is to avoid overriding some exclusive libs from gcc-5
<doko> pitti, yes. it's unfortunate to add 8 with 9 on the horizon, but 5 more years 7 ... no thanks
<pitti> doko: ack
<ricotz> doko, libmpx0 and lib32mpx0
<pitti> doko: ruby-rjb is a leaf package; should we remove it then, if it's known to not work with jdk8?
<pitti> doko: I'll let java-common in then
<doko> pitti, works on amd64
<pitti> doko: ok; "don't care" then :)
<doko> but yes, we could remove it on i386
<pitti> (i386 on a server â not really a thing)
<pitti> doko: ok; I'll remove the binary; once Debian gets a new version, it'll come back automatically
<pitti> doko: *flush*, removed
<Laney> laney@cripps> dpkg-architecture -qDEB_HOST_ARCH                                                                                                                                                     ~
<Laney> i386
<pitti> Laney: do you use ruby-rjb there? :-)
<Laney> no, that's not the line I was challengeing
<Laney> -e
<Laney> It's we don't care about server things for i386 because that doesn't exist
<doko> pitti, barry, jtaylor, tumbleweed: so either we make some progress fixing python-numpy related autopkg tests, or we push it ...
<pitti> doko: I hinted a few more broken tests, but numexpr and pyresample look real
 * pitti currently runs them locally to confirm
<doko> pitti, numexpr is weired. tests depend on python-pkg-resources, but it's not installed
<pitti> indeed; I thought I already fixed that the other day, but maybe that was a different package
<pitti> debian bug 812726
<ubottu> Debian bug 812726 in numexpr "[PATCH] Fix autopkgtest" [Normal,Open] http://bugs.debian.org/812726
<pitti> ... clearly not, I'll reopen and upload a fix
<pitti> ah, it works when enabling all of -proposed
<mardy> pitti: hi! I'm getting this error when running tests with libqtdbusmock (qt wrapper for python dbusmock): http://paste.ubuntu.com/15015374/
<mardy> pitti: it doesn't happen all of the time, just sometimes, maybe 50% of the times
<mardy> pitti: is it anything familiar?
<doko> pitti, and openmpi maybe has two more to ignore ...
<pitti> doko: ok, numexpr should go green
 * pitti runs pyresample
<pitti> doko: yep, already hinted during my daily "go through excuses" sweep
<Unit193> Is it just me or is https://launchpadlibrarian.net/235789470/buildlog_ubuntu-xenial-amd64.ruby-rest-client_1.8.0-2_BUILDING.txt.gz only failing due to no network during tests?
<LocutusOfBorg> Unit193, also https://launchpadlibrarian.net/237839768/buildlog_ubuntu-xenial-amd64.ruby-omniauth-azure-oauth2_0.0.6-1_BUILDING.txt.gz
 * LocutusOfBorg is looking to see gitlab migrate
<Unit193> Fun times.
<doko> pitti, and maybe hint jquery? test failures don't look like jquery related (usually used in the docs only)
<pitti> doko: jquery is already a valid candidate
<pitti> (landed 4 mins ago)
<ginggs> pitti, doko: i think python-scientific should be removed
<Mirv> pitti: an optimization question that might be silly: couldn't a package be declared Valid Candidate already when the only remaining running tests are a) either always failed or b) overridden?
<pitti> Mirv: that's already the case
<Mirv> pitti: oh, ok, great! and right, I now found one claimed regression, unity-scope-click - https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-032/excuses.html
<pitti> Mirv: it's the ... that
<pitti> Mirv: I just retried that
<Mirv> :)
<pitti> just> maybe some 15 mins ago
<pitti> http://autopkgtest.ubuntu.com/running.shtml#pkg-unity-scope-click
<pitti> 11 mins :)
<Mirv> pitti: wonderful, anyway. as train is naturally heavier with more testing, it's great to know it's pretty smooth overall despite the machinery that runs.
<pitti> Mirv: -gles is already a valid candidate
<Mirv> it's really rocking now, aside from the noticed issue yesterday with proposed/release clashing
<pitti> Mirv: hoping that the u-s-c one succeeds after a few retries; I think that one has always been flaky, right?
<Mirv> pitti: my memory says that red has been seen earlier in various excuses lists, yes
<pitti> Mirv: ... or when the ppc64el ones go AWOL :)
<Mirv> (regarding u-s-c)
<pitti> http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/armhf/
<pitti> it's a fairly hard gambling :/
<Mirv> yes, poor ppc64el machines, almost like our jenkins' phone hardware
<pitti> well, as long as they work they are actually quite fine
<doko> ginggs, https://bugs.launchpad.net/ubuntu/+source/python-scientific/+bug/1542928
<ubottu> Launchpad bug 1542928 in python-scientific (Debian) "python-scientific should be removed" [Unknown,Confirmed]
<pitti> but our current images are broken, so everytime we get a new cloud image they all fail until I manualy build a newer one with a hack
<pitti> I cronned that now, so should hopefully not hit so hard any more
<ginggs> doko, i saw that.  can we do it?
<pitti> Mirv: please prod me if it's still broken this afternoon, then I'll hint it
<pitti> I mean, fix your tests or silently get broken by other packages :)
<doko> ginggs, can you fix debian-med and debian-science?
<ginggs> lemme look, if they are what i think they are, they just have recommends not depends. but let me confirm
<doko> ginggs, you have to adjust tasks/*
<doko> reverse-depends tells you which ones
<Mirv> pitti: ok, I can retry a couple of times as well. was it that there is no way to find links to past silo autopkgtests at http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/ ? I mean, I haven't found where to find test result after it disappears from running.shtml, before the hourly silo excuses page update
<pitti> Mirv: silos aren't on a.u.c.
<pitti> Mirv: the logs are still there, but a bit buried on swift
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-032?format=plain&prefix=xenial/armhf/u/unity-scope-click
<pitti> foor example
<pitti> I think that's the one you want to look at
<Mirv> pitti: thank you for the url! I tried experimenting from the final log url but didn't find anything useful
<doko> sil2100, fyi, just mad no-change uploads for unity-scopes-api, unity-scope-mediascanner, unity-scope-click
<pitti> ginggs: replied to the p-scientific removal bug
<sil2100> doko: for the libjsoncpp transition? Those are in a silo
<ginggs> ok doko, i see science-distributedcomputing, science-engineering-dev, science-meteorology, science-nanoscale-physics, science-viewing and science-viewing-dev but they are all reverse-recommends so i think no action is required.  I recall discussing a similar situation with cjwatson some months ago
<sil2100> Waiting for sign-off since normal no-change rebuilds in the archive won't cut it, as their ABI checks will cause the scopes-api package to FTBFS
<sil2100> doko: anyway, all of those are ready in the train and will be landed soon
<doko> sil2100, ok, I'll let the builds fail
<Mirv> pitti: ok I can indeed now real time monitor unity-scope-click both during and after a run, thanks. rerunning a few times over the afternoon.
<pitti> Mirv: as I said, if it's that flaky, we can also hint it
<Mirv> I'll ping if it seems too flaky. hmm, and seeing about a bug report
<sil2100> doko: the CI Train silo with those is in QA testing now, so we should hopefully have it landing in the xenial archive in the nearest hour
<cjwatson> Laney: Excellent, I'll mark my card for that done then.
<doko> LocutusOfBorg, are you looking at https://launchpad.net/ubuntu/+source/insighttoolkit4/4.9.0-1ubuntu1 ?
<cjwatson> Laney: debmirror> you could file a bug for the new debmirror maintainer to look at *coughcough*
<doko> pitti, is this one easy to fix, or should we just remove it? https://launchpad.net/ubuntu/+source/orthanc-postgresql/2.0-1build1
<LocutusOfBorg> doko, refreshing each minute or so
<LocutusOfBorg> I did revert amd64 slowliness
<Laney> cjwatson: I tried hacking it in where it deals with i18n stuff but it wasn't that straightforward :)
<Laney> cjwatson: new maintainer> good idea, he seems full of enthusiasm
<LocutusOfBorg> if amd64 builds it should build in less than one week now, I'm not sure why you disabled parallel builds
<pitti> doko: no response to debian bug 811141 in almost a month, so I'd say demote-to-proposed (removed from Debian testing)
<ubottu> Debian bug 811141 in orthanc-postgresql "FTBFS: CMake Error: The following variables are used in this project" [Serious,Open] http://bugs.debian.org/811141
<pitti> doko: doing
<LocutusOfBorg> and for i386 failure we have a fix in gccxml, waiting for Gert to upload it on debian
<ginggs> LocutusOfBorg: iirc parallel builds were disabled because of a lack of memory
<cjwatson> doko: You can ignore the unity-scope-click/unity-scopes-api etc. build failures in the primary archive - that's being sorted out in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-037/+packages
<cjwatson> doko: Oh, sorry, sil2100 already said that
<pitti> smoser: did we talk about merging open-iscsi? or was that someone else? either way, https://tracker.debian.org/news/747283 took a lot of our changes, I think the remaining delta is just the autopkgtest addition
<pitti> apw: hm, just started looking at bug 1542833
<ubottu> bug 1542833 in Auto Package Testing "running.json queues not populated" [Undecided,New] https://launchpad.net/bugs/1542833
<pitti> apw: I stopped all workers and submitted a few tests, so that http://autopkgtest.ubuntu.com/running.shtml has 5 queued tests now
<pitti> apw: and http://autopkgtest.ubuntu.com/running.json has those too
<pitti> I first tried to reproduce in juju-local, but running.json looks good there too
<pitti> apw: can you exclude the possibility of having looked at an older running.shtml, i. e. you didn't reload or something such?
<pitti> apw: erk, ignore me
<pitti> apw: fixed
<apw> pitti, yay
<smoser> pitti, we have talked. and that is great.
<smoser> i had plan to merge it. i want to get an dep8 test that would pull ubuntu image and iscsi root boot it.
<doko> pitti, could you have a look at the failing tests triggered by mpi-defaults? do these messages come from adt?
<doko> same messages for all three packages
<Mirv> pitti: got unity-scope-click to pass, once. then I accidentally reloaded the retry page and it failed again :) but meanwhile excuses page updated with a pass and QA's script picked the silo into their queue so primary goal achieved.
<Mirv> also needed to rerun amd64 kwindowsystem, that passed too then
<doko> pitti, ahh, no. this is the updated openmpi
<barry> doko, pitti did you get the numpy stuff sorted out?
<pitti> Mirv: yes, if it passes once, that's good enough for excuses
<pitti> Mirv: ah, valid candidate
<pitti> barry: no, pyresample still regresses in -proposed, and that's reproducible locally; the others are sorted out
<barry> pitti: ah.  not sure i can help much but i saw the while-i-was-asleep-ping :)
<pitti> doko: no, "adt" is just the hostname; something is writing those "2 more processes have sent help message" strings to stderr
<pitti> curiously only on md64
<doko> ginggs, so you verfied that all these are recommends?
<ginggs> i'm going by what reverse-depends reported
<ginggs> do i need to doublecheck?
<doko> no, ok
<ginggs> but i've confirmed in the control files https://sources.debian.net/src/scitools/0.9.0-2/debian/control/ and the science-* metapackages  https://sources.debian.net/src/debian-science/1.4/debian/control/
<doko> barry, cjwatson: six autopkg tests fail
<barry> doko, cjwatson i'll look.  it's probably my fault
<barry> looks like a pytest related build failure.  iirc that's because of a ubuntu delta on pytest which i believe i fixed in debian.  i'm working on sync/merges from debian today so i'll drill down on it
<ginggs> doko thanks for cleaning up python-scientific
<doko> ginggs, do you have news about openmpi on powerpc?
<ginggs> i replied to debian bug #814183
<ubottu> Debian bug 814183 in src:openmpi "openmpi 1.10.2 is broken on powerpc" [Serious,Open] http://bugs.debian.org/814183
<ginggs> petsc failed on the powerpc porterbox with 2GB RAM, but built successfully on a buildd with 5GB RAM
<ginggs> how much RAM do the ubuntu powerpc buildds have?
<cjwatson> ginggs: sagari has 15GB, the others are VMs and I actually can't remember how much they have but it should be at least 4GB
<cjwatson> ginggs: (infinity would know exactly)
<ginggs> any chance we could schedule a rebuild of petsc on sagari?
<cjwatson> ginggs: looking
<cjwatson> ginggs: will have to wait, there's a gcc-5 build there at the moment
<ginggs> kick it off, doko won't mind :)
<cjwatson> (this isn't something I can schedule in advance - the way to force a build onto a particular builder is to put all the other builders on manual and then get it to start)
<cjwatson> ginggs: history does not agree with you :P
<cjwatson> I get sad every time we have to schedule things on a particular builder, but if this is just memory then by the time powerpc is in scalingstack I guess guests will have adequate memory
<pitti> cjwatson: the "ppa" nova flavor has 8 GB, but I suppose that's somehow not applying here?
<cjwatson> pitti: that's ppc64el, not powerpc
<cjwatson> pitti: and only upgraded to 8GB last night :)
<cjwatson> pitti: powerpc scalingstack isn't a thing yet
<pitti> oh, manual VMs
<pitti> that explains it
<cjwatson> yeah
<pitti> I thought we ran powerpc on ppc64el instances somehow
<cjwatson> no no
<cjwatson> the plan is eventually to run it on the same hardware, but it requires different instances because you can't do the endian switch at run-time
<cjwatson> and there are some complications with the current scalingstack infrastructure
<ricotz> hi, which llvm versions will be kept around in xenial?
<doko> I hope, 3.8 only. if we have to, maybe the current default
<ricotz> doko, syncing clamav would be nice, but it doesnt like 3.8 yet
<ricotz> doko, the current default is 3.8, isnt it?
<doko> when it migrates, yes
<rbasak> caribou is merging clamav at the moment.
<rbasak> Is doko/recotz 's conversation relevant?
 * rbasak isn't sure so he thought he'd check
<ricotz> rbasak, hardcoding 3.7 should be enough
<doko> rbasak, I thought you (server) wanted to port to the default version
<doko> but now explicitly using 3.7, where mesa just dropped it?
 * rbasak isn't sure
<ogra_> hmm, if my kernel properly supports cgroups and is at a recent version, should i still see cgmanager run on my system (i thought it is a fallback thing only)
<pitti> ogra_: cgmanager needs cgroups to work, otherwise it's useless
<ogra_> pitti, yes, i know
<pitti> ogra_: it's mostly a d-bus API for managing those, so that unpriv processes (like user LXC) can create those
<pitti> plus the "fake" cgroup/proc/sys fs with lxcfs for containers
<ogra_> pitti, but i thought there is another in--kernel mechanism to manage them and cgmanager is only used if thats missing
<pitti> no, not really
<ogra_> ok
<pitti> the in-kernel mechanism is mkdir()/open()/write() :)
<pitti> hmm, it seems ligo.org is currently being DDoSed ..
<ogra_> heh
<pitti> I guess it got hit by a gravitation wave
<ogra_> haha
<ogra_> trying to watch the stream live ?
<pitti> I didn't find a stream URL before -- I'd be content with a live ticker
<marlinc> Any chance of getting htop 2.0 in Xenial? http://hisham.hm/htop/
<marlinc> :D
<caribou> rbasak: doko: ricotz: that's a question I had; which version of llvm should we use; it currently explicitely uses 3.5
<doko> caribou, 3.8
<ricotz> caribou, please drop all ubuntu patches and use the debian package as base
<ricotz> clamav is checking for llvm <= 3.7
<caribou> ricotz: I removed a few delta
<ogra_> pitti, see pm
<ricotz> caribou, e.g. libmspack is in main
<caribou> ricotz: yes, that got dropped in the merge
<ricotz> caribou, alright, looking forward to the update
<ginggs> marlinc: subscribe to debian bug #814401
<ubottu> Debian bug 814401 in htop "htop: new upstream 2.0 release" [Wishlist,Open] http://bugs.debian.org/814401
<gatisp> hey, anyone knows whats up with "udisks" binary missing from Ubuntu 16 ?
<cjwatson> It's there, in the udisks package, though in general it's been superseded by udisksctl in the udisks2 package
<cjwatson> (as I understand it)
<cjwatson> also, Ubuntu 16 isn't a thing, you probably mean Ubuntu 16.04
<cjwatson> oh, wait, the udisks package was in fact removed
<gatisp> yeah 16.04
<cjwatson> so it's just udisksctl in udisks2 now
<gatisp> cjwatson, will try, thanks for the feedback
<cjwatson> https://bugs.launchpad.net/bugs/1288253 <- removal log
<ubottu> Launchpad bug 1288253 in guymager (Debian) "Eliminate udisks 1 from Ubuntu" [Unknown,Confirmed]
<marlinc> Cool ginggs
<cjwatson> barry: pytest doesn't have an Ubuntu delta.  The problem appears to be that the python3-pytest in -proposed doesn't install any modules: see near the end of https://launchpadlibrarian.net/237085197/buildlog_ubuntu-xenial-amd64.pytest_2.8.7-1_BUILDING.txt.gz
<cjwatson> barry: so that's kind of busted :)
<barry> cjwatson: yeah, i know what's going on but i don't have a fix just yet
<cjwatson> barry: all right, can you retry python-click (not click) as well once a fix is in?
<barry> cjwatson: yep
<cjwatson> ta
<marlinc> cjwatson, did boot=ZFS= support go into the ZFS packages in Xenial? Saw 'Require root=ZFS= syntax.  rpool= and bootfs= are no longer supported.' in the changelog on my laptop
<cjwatson> marlinc: I only do GRUB, I don't know about the rest of the ZFS stuff
<cjwatson> (and even then I'm only really doing what other people tell me to do)
<cjwatson> I think there's still a patch to the update-grub stuff outstanding
<marlinc> Ah, okay :)
<marlinc> cThanks anyway
<marlinc> cjwatson, do you know of a place where I can define the value of bootloader-id when installing GRUB? I want to create multiple boot entries in my UEFI for the OSes that I run
<marlinc> The issue is that when I manually run grub-install using --bootloader-id it works just fine but then when a GRUB update comes it creates another entry with the default entry called 'ubuntu'
<cjwatson> marlinc: GRUB_DISTRIBUTOR in /etc/default/grub.d/<something>.cfg (e.g. local.cfg).  Note that that will override the presentation in menus as well
<marlinc> Ah, that's what that's for
<marlinc> Is it rather strange that the entry in UEFI is all lowercase and that is Ubuntu with the uppercase U
<cjwatson> debian/postinst.in:        bootloader_id="$(config_item GRUB_DISTRIBUTOR | tr A-Z a-z | \
<marlinc> Ah
<cjwatson> sorry to be terse, am trying to understand the internals of some web service authorisation code which is quite a different headspace
<marlinc> No problem at all, I'm glad you guys here answering questions
<marlinc> I'm a web developer so I can understand its something completely different :p
<nacc> slangasek: would it be better for me to run update-maintainer and refresh my debdiffs (to include the bug #s) throughout?
<slangasek> nacc: well, one of us will have to do it before upload ;)  if you do it, it speeds up my part
<nacc> slangasek: ok, i can do that for sure
<nacc> i'm trying to spend some time on swig right now just to see if i can get it done by next week
<nacc> i'll refresh the debdiffs in teh bugs after that
<slangasek> nacc: does one of the bugs you've opened point me towards what I need in order to start bootstrapping, and is that ready to happen?  that's the part that needs an archive admin, so I'd like to start on that sooner rather than later if possible
<nacc> slangasek: sorry! let me upload that to the first bug in a text file
<nacc> slangasek: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4569477/+files/php7-archive-admins.howtov2
<ubottu> Launchpad bug 1522422 in php5 (Ubuntu) "Update to php 7.0" [Wishlist,Triaged]
<nacc> slangasek: let me know if that's not written in a way that makes sense
<doko> ginggs, cjwatson: looks like mpi isn't any better on sagari: https://launchpad.net/ubuntu/+source/esys-particle/2.3.3+dfsg1-2ubuntu2/+build/8999028
<ginggs> doko, i don't recall the exact place where esys-particle was failing, but yeah that doesn't look good. if giving it more ram did help, we would still be asking why openmpi 1.10 suddenly needs more ram on powerpc.
<dobey> doko: oh, are you still here?
<dobey> guess not
<doko> dobey, ust ask
<bdmurray> happyaron: There are no Launchpad-Bugs-Fixed in your open-gram upload in the trusty proposed queue
<dobey> doko: ah, i need a core dev to copy some packages from a silo ppa to xenial-proposed; we already had a silo in the works to resolve the scopes api issues with new capnproto and jsoncpp, and was being tested by QA today, but i saw you uploaded some no-change packages to proposed this morning, as i went to publish the silo after QA approved it. wondering if you can copy the xenial packages over to xenial-proposed (which will clobb
<sarnold> dobey: you were cut off at "(which will clobb"
<doko> dobey, which silo? are there special scripts for silo copies?
<dobey> doko: wondering if you can copy the xenial packages over to xenial-proposed (which will clobber the changelog from your uploads this morning)
<dobey> one second, let me find my tab
<dobey> doko: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-037/+packages
<dobey> doko: if you can coy the unity-scope-click, unity-scope-mediascanner, unity-scopes-api, and unity-scopes-shell packages for xenial there to xenial-proposed, it should get things rolling again
<doko> dobey, done
<dobey> doko: great, thanks
<Saviq> slangasek, I think we have another britney situation like we had for qtmir/mir http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-scope-click - old -click tested with new -api â regressions, do we know how to deal with those properly, yet?
<slangasek> Saviq: you deal with it by flagging it to the release team for override.  However, I'm not seeing here the issue; which failing test are you saying is a false positive?
<Saviq> slangasek, http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-scope-api
<Saviq> the unity-scope-click test here
<slangasek> Saviq: there are no failing tests there that are blocking anything.  Maybe you mean http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#libjsoncpp ?
<doko> ginggs, cjwatson: openmpi success \o/  building with -Og lets the rdeps build.  I'm not going to investigate why ...
<Saviq> slangasek, humm, I did ask mterry to restart them, just in case, but in http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-scopes-api I can still see three reds for unity-scope-click Â¿?
<tumbleweed> doko: :/
<slangasek> Saviq: oh, sorry - I missed the unity-scope-api vs. unity-scope-click :)
<slangasek> let's see
<Saviq> slangasek, but yeah, the libjsoncpp looks like it's going to block it as well?
<doko> tumbleweed, always happy to keep a dead arch alive :-/
<slangasek> Saviq: the libjsoncpp one is blocking; but I don't know that this is related to any api/click skew
<slangasek> needs investigating/confirming
<Saviq> slangasek, right, that's a separate issue, and it isn't looking great, all the three failures are just segvs or abrts
<slangasek> right
<Saviq> so unlikely to be flaky or anything
<slangasek> so if you can sort that out, then I can address the unity-scopes-api/unity-scope-click skew
<slangasek> but both packages are blocked by the new libjsoncpp so that needs to be addressed first
<Saviq> slangasek, yeah thanks, will likely have to wait until tomorrow, then
<jderose> rharper: i wrote a blog post summarizing what i learned - http://blog.system76.com/post/139138591598/howto-qemu-w-ubuntu-xenial-host-uefi-guest thanks again for the help!
#ubuntu-devel 2016-02-12
<doko> meh, just molds built. anything else fails on powerpc
<nacc> slangasek: ok, i think i updated all the debdiffs
<nacc> slangasek: also posted a v3 of my sequence
<sarnold> slangasek,cyphermox, 1544809 is currently filed against 'linux' but grub or grub2 may be more appropriate
<cyphermox> ack reassigning to grub2... I'll look tomorrow
<sarnold> thanks cyphermox :)
<happyaron> bdmurray: the open-gram upload is for LP: #1361764
<ubottu> Launchpad bug 1361764 in open-gram (Ubuntu Trusty) "Update sunpinyin-data to >=20130220" [Medium,In progress] https://launchpad.net/bugs/1361764
<PovAddict> who do I contact regarding blatant misuse of the ubuntu logo?
<PovAddict> https://twitter.com/actoresargok
<sarnold> wow
<sarnold> that's not even close to right ;)
<PovAddict> they have absolutely nothing to do with software, they found something that looked nice and slapped it there
<PovAddict> they even put it on all photos they upload, so it's not just a matter of changing the twitter profile picture
<slangasek> lolwut
<slangasek> I think there's a contact address for Canonical Legal you can use to report this
<slangasek> though fwiw, trademark law in most countries limits trademarks by field of endeavor; so /because/ it's not for software, it probably doesn't infringe Canonical's trademark
<slangasek> PovAddict: http://www.ubuntu.com/legal/terms-and-policies/contact-us
<slangasek> ok that's meant to be requests to use the trademark instead of requests to enforce the trademark, but I think it'll get to the right people ;)
<PovAddict> could still be a copyright violation if they didn't draw the logo from scratch
<tumbleweed> looks like they've been misusing it for a few years (based on the vintage of that ubuntu logo)
<PovAddict> tumbleweed: or what their random logo search found happened to be old?
<tumbleweed> yeah, or that
<PovAddict> "Are you making the request on behalf of a company?" "No" and then the company website and street are required fields, wonderful
<sarnold> haha
<slangasek> PovAddict: how would it be a copyright infringement when the logos are under a free license?
<PovAddict> what license lets them get away without even attribution?
<slangasek> yes, perhaps there's an attribution problem
<sarnold> I'll mail the lawyers, i can't find them on irc (go figure..)
<PovAddict> just sent the form
<sarnold> ah, thanks PovAddict, then i'll skip the email :)
<kirkland> doko: thanks for the heads up;  I think (hope?) I just uploaded the right fix
<pitti> Good morning
<ginggs> doko:  well done! getdp failed because petsc hasn't built yet, which others did you try with -Og ? pochu add some info to the bug, could be a PPC970FX vs POWER7/8 thing
<highvoltage> 9/win 27
<dholbach> good morning
<slangasek> nacc: sorry, I've just now had a chance to look at your guide.  what's not clear to me in this is what the sequence points are.  I don't want to be building one package at a time, waiting for completion before starting on the next; I want to be able to throw these packages out there in parallel as much as possible.  Do you have this kind of information available?
<doko> ginggs, <doko> meh, just molds built. anything else fails on powerpc
<doko> liggghts built on a porter box
<ginggs> doko: anything special about that porterbox?  BTW i did try petsc 3.6.3 but not change.  I  did get petsc 3.6.2 to build by patching the tests to only run on one process (but that's defeating the point of MPI)
<doko> ginggs, it's a POWER7+ machine, running qemu
<ginggs> I did find this issue upstream that sounded vaguely similar https://github.com/open-mpi/ompi/issues/874
<ginggs> endianness, -np 1 works, -np 2 fails - but apparently those patches have been included (and i can't even find those files)
<doko> the test cases really should be turned on in the openmpi package itself
<ginggs> doko: i think they are
<ginggs> at least it says so in the changelog for 1.10.2-6
<doko> ginggs, hmm, the files in the patch don't exist :-/
<opny> hello, I would like to run xenial armhf on qemu. Do you think is feasible?
<doko> kirkland, I hope you saw the build failure yourself this time ;p
<ginggs> doko: btw should https://launchpadlibrarian.net/237705769/vtk6_6.2.0+dfsg1-7ubuntu1_6.2.0+dfsg1-7ubuntu2.diff.gz go to debian?
<doko> ginggs, wouldn't hurt, I assume
<ginggs> ok, i'll forward it, gladk's going to include our other delta as well
<doko> pitti, http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/amd64/   looks like a valid test results is superseded by an invalid one ...
<doko> sil2100, ^^^
<sil2100> doko: yeah, I actually re-ran those in the morning, I see 2 of them still fail
<doko> hmm, looks like some autopkg test results are not picked up since midnight
<Laney> doko: what's the actual problem?
<doko> sil2100, no wonder if the tests are run with the wrong versions... I'm wondering where pitti even gets this version from
<Laney> Tests try to minimise their use of proposed
<Laney> the order of things on autopkgtest.u.c doesn't really matter, britney doesn't just take the latest
<rbasak> caribou: o/
<caribou> rbasak: o/
<caribou> rbasak: so I rebuilt a new repo starting from the original merged version
<rbasak> So for when Ubuntu pull in a new upstream, I'm breaking down the logical commit as follows. For each Ubuntu upload, there will be one commit that pulls in the new upstream, but no changes in debian/*, and subsequent commits only change debian/*
<rbasak> Then one commit per logical change, which is generally one per changelog entry but a little subjective.
<rbasak> That should be it.
<rbasak> Before I get there the reconstruct stage additionally has one commit for all of debian/changelog changes per upload, and potentially another commit for update-maintaner/ubuntu-meta.
<rbasak> Sorry, that's really the reconstruct.
<rbasak> The logical then drops the upstream changes, changelog and ubuntu-meta.
<rbasak> So you end up with logical only changing things in debian/* that are logical parts of the Ubuntu delta, so excluding upstream changes and meta-changes in debian/changelog, update-maintainer, etc.
<doko> Laney, well, for a transition, this assumption is wrong
<rbasak> caribou: here's a summary I wrote yesterday, but haven't finalised yet: http://paste.ubuntu.com/15023270/
<doko> Laney, http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/i386/  shows a successful test, which is overridden by a bad one
<Laney> it is not overridden
<Laney> you need to look on excuses
<doko> Laney, I did, libjsoncpp still lists these as fail
<pitti> doko: WDYM with "invalid version"? 0.1.1+16.04.20160210-0ubuntu1 is -proposed
<Laney> I think I retried those with the new -scope-click now
<rbasak> caribou: minor updates in http://paste.ubuntu.com/15023288/ - I clarified logical/<version> wrt. your new upstream case.
<Laney> pitti: It's a transition but retried with the non rebuilt -scope-click I think
<caribou> rbasak: looking
<pitti> Laney: ah, that again -- they don't have versioned Depends:, thus they need the old "rerun with both triggers" trick again?
<Laney> well they have Depends on the old and new versioned packages
<caribou> rbasak: so basically, when a new upstream is merged in as an ubuntu delta (my 0.98-7 case), you would lump all of the 'upstream' changes in one commit & the debian specific things in other logical commits ?
<rbasak> caribou: right. And then for the "logical", I drop the commit containing all of the upstream changes.
<caribou> rbasak: ah ok, got it. I'll rebuid my git repo according to this (mostly done) & will resubmit
<rbasak> Since when later rebasing, the upstream changes will be present anyway, since we'll always be rebasing onto a newer upstream.
<rbasak> caribou: OK. Thanks!
<Saviq> pitti, hey, got two Qs about silo 51 excuses; 1: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html (just updated a few minutes ago) says "in progress" for a lot of items, but running.html shows none of them... 2: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-051/excuses.html has â» for qtmir-gles that tell sil2100 that it has no tests, so can't re-run Â¿?
<pitti> Saviq: hm, I had to kill ppc64el runs this morning as the lcoud was broken again
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-051?format=plain does have a qtmir result from this morning, though
<pitti> Saviq: for 2. indeed http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/ does not yet have any results for vivid
<pitti> Saviq: we currently check that to determine whether a package name is valid and has tests, to fend off invalid retries
<pitti> (we need to be rather strict there as this quickly becomes a resource DoS)
<pitti> Saviq: can you please file a bug report about that, with a summary of that (against auto-package-testing)
<Saviq> pitti, ok, thanks
<pitti> I need to think about how we can allow that without openign the floodgates
<pitti> Saviq: I'll retry the tests in the meantime
<Saviq> pitti, thank you
<pitti> does anyone else than robru have access to the production CI train?
<pitti> would be much easier to rm pending.json for that xenial silo than crafting the retry commands by hand
<Mirv> I don't think sil2100 has either the access
<Mirv> I don't at least
<Saviq> pitti, I could toggle the lander ack there, that (I *think*) would retry the whole suite?
<pitti> vivid retried
<Saviq> pitti, bug #1544917
<ubottu> bug 1544917 in Auto Package Testing "Retry says "does not have any test results" on reported Regressions" [Undecided,New] https://launchpad.net/bugs/1544917
<pitti> Saviq: thanks, updated
<pitti> robru (CC: Saviq): Can you please remove pending.json for this silo? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html
<pitti> to get the tests re-ran?
<pitti> run
<robru> pitti: nope you need webops
<pitti> (scalingstack glitch this morning, sorry)
<robru> pitti: would be like /tmp/britney_data/landing-051-xenial/autopkgtests/pending.json or so
<pitti> robru: what does "webops" translate to?
<robru> pitti: talk to the vanguard in #webops
<Saviq> pitti, re: qtmir-gles - it has tests since October, and somehow britney has decided that it was a regression, so Â¿?
<pitti> Saviq: within the silo, yes, but apparently it never ran in Ubuntu in vivid?
<pitti> Saviq: xenial-051 sohuld now retry the missing tests on the next run
<Saviq> pitti, hmm right, that makes sense
<LocutusOfBorg> ginggs, I syncd scalapack and blacs-mpi from Debian
<LocutusOfBorg> mapreri fixed all the delta there
<ginggs> LocutusOfBorg: thanks
<LocutusOfBorg> just a little change has been left out (adding fort to the linker flags), because he is pretty sure the fix has been in another package (pkg-config wasn't giving all the flags)
<LocutusOfBorg> so that delta has been removed
<LocutusOfBorg> don't remember where, but in a package I remember I syncd yesterday
<LocutusOfBorg> let me know if I broke anything, and I'll bother mapreri to fix it :)
<LocutusOfBorg> actually I think powerpc is the most important problem
<caribou> doko: remember the reason why clamav was 'forced' to use LLVM 3.5 ?
<doko> caribou, because it needs porting?
<caribou> doko: yeah, I get clamav build failures with 3.7 & 3.8
<doko> caribou, yes, the server team told me that they will port it
<doko> rbasak, ^^^
<caribou> doko: hmm, that means me
<doko> caribou, forwarding you email
<caribou> doko: thanks
<doko> caribou, you might ask ScottK; he once cared about clamav
<LocutusOfBorg> caribou, according to debian logs it should build fine with 3.6
<caribou> LocutusOfBorg: yes, that's what they build with
<rbasak> doko: when did we say that? Or did you just ask us to port it?
<doko> rbasak, see email
<ScottK> caribou: Every single llvm update seems to need a new patch for clamav.
<ScottK> rbasak: If you are going to port it, you also really want to update to 0.99 first.
<ScottK> Please send us (Debian) the patch if you come up with something.
<pitti> Mirv: vivid is ok now (except for the unity8 NBS), xenial re-ran and now just has one regression
<ricotz> hello developers
<ricotz> doko, hi, please don't forget aptitude
<caribou> ScottK: porting would be part of the 0.99 merge
<ScottK> OK.
<caribou> ScottK: right now, it doesn't like the fact that I'm using 3.8 (testing for 3.7)
<caribou> ScottK: configure complaining
<ScottK> I'm sure it doesn't.  The only reason it works with 3.6 is a Debian patch.
<ScottK> I'm sure it'll need additional something for newer.
<caribou> ScottK: ok, I'll look at what was done on the debian side
<doko> ricotz, would like to wait until apt gets in
<ScottK> Specifically debian/patches/add-LLVM-3.6-support.patch
<Mirv> pitti: you mean Saviq?
<pitti> Mirv: yes, I do, sorry :)
<Mirv> np :)
<ScottK> caribou: You can discuss what needs doing on pkg-clamav-devel@lists.alioth.debian.org.
 * ScottK isn't the right person to answer any details.
<caribou> ScottK: ok, thanks
<cjwatson> pitti: could you add an "easy click/0.4.43+16.04.20160203-0ubuntu2 python-click/6.2-2ubuntu1" hint for me?  it's not going to work yet because of reverse dependencies, but those two will eventually need to go in together
<ricotz> doko, alright
<cjwatson> pitti: (renaming python3-click -> python3-click-package and also python{,3}-click-cli -> python{,3}-click)
<Mirv> Saviq: rerunning the one remaining failed at http://autopkgtest.ubuntu.com/running.shtml#pkg-qtmir
<Saviq> Mirv, thanks!
<Saviq> Mirv, we should be rid of these soon, hopefully
<Saviq> (flaky ones I mean)
<pitti> cjwatson: committed (without knowing what I'm doing :) )
<cjwatson> heh, thanks
<rbasak> doko: thanks
<doko> rbasak, also saw that the merged ntp is dep-wait
<rbasak> doko: I emailed ubuntu-devel about that. I guess we'll MIR pps-tools.
<rbasak> caribou: can I suggest that you merge and build against llvm 3.6 for now, since that's the easiest path? Then we'll at least be further forward.
<caribou> rbasak: that was my idea
<rbasak> If we can fix in a later upload to use a newer llvm then we can do that separately, but that realistically sounds unlikely to me to happen before FF.
<rbasak> doko: ^
<caribou> ScottK: the only delta left with debian then would be an override for armhf tests
<caribou> ScottK: would that be accepted in Debian ?
<seb128> doko, slangasek, would foundation like to subscribe to fonttools bugs (bug #1538173)? graphite2 is depwaiting on it and you probably know better about fonts than us
<ubottu> bug 1538173 in fonttools (Ubuntu) "[MIR] fonttools" [Undecided,Incomplete] https://launchpad.net/bugs/1538173
<cyphermox> good morning!
<seb128> hey cyphermox, happy friday!
<cyphermox> hey, you too
<ginggs> doko: are the powerpc openmpi builds working now?
<cjwatson> ginggs: https://launchpad.net/ubuntu/+source/aces3/3.0.8-5build2/+build/8974836 managed to pass, which is a good sign I guess
<doko> ginggs, cjwatson yes, this one and molds. the others still stuck, however there seems to be a bit more output
<doko> seb128, isn't font stuff desktopish? ;)
<seb128> doko, I don't think so ;-)
<seb128> you have fonts on command lines as well :p
<Mirv> mterry: LP chat is slow, would you want for me to consider another team for the foma or create a new team?
<ginggs> doko, cjwatson: weird, aces3 is one that failed on the debian buildds.  aster, getdp and slepc all depend on petsc, so if we can shoehorn petsc in, it would be good
<mterry> Mirv, creating a new team seems like a hassle, is there another good team fit?  It just seemed odd to have a team responsible that was really just you  :)
<Mirv> mterry: I responded to the bug now once though, explaining how the team was the best fit of the existing teams I could think of - that is, it has at least two other active Ubuntu (technical) contributors that care about the package or the functionality it provides
<ginggs> this should make petsc build https://launchpadlibrarian.net/237387369/petsc_3.6.2.dfsg1-3_3.6.2.dfsg1-3ubuntu1~ppa1.diff.gz (it skips the 2 process test)
<ginggs> although the changelog entry is rubbish, i think we've established it isn't about ram
<mterry> Mirv, oh didn't read bug comment
<mterry> Mirv, that's fine then.  I just wanted to raise the point.  If you like that team, it's good enough for me
<Mirv> mterry: ok then. thank you for raising it, it's always good to ask.
<doko> ginggs, disable the tests on powerpc ;p
<ginggs> doko: this version worked on a porterbox, shall i just upload it and see what happens?
<doko> ginggs, how does it differ?
<ginggs> err look at the diff? what do you mean?
<doko> cjwatson, thanks for fixing the click mess =)
<cjwatson> doko: Rather belatedly :)
<cjwatson> I think it's mostly out of the way now but will probably require an adjustment to the p-m hint.
<doko> pitti, python-numpy/pynfft is red, but the test is green
<ginggs> doko: just to be clear, shall i upload petsc with the 2 process test disable? it is ready to go
<doko> ginggs, but just disable it on powerpc. I fear at some point we'll have to remove the powerpc builds again
<doko> pitti, looks like adt doesn't understand "Test-Command" on it's own? see python-pywcs
<ginggs> doko: i can't think of an easy way to selectively apply a patch by arch.  i did post a link to the diff if you scroll up a bit.  this version i have tested on a porterbox, any big changes and i'd need to start from scratch
<doko> ginggs, repaste?
<ginggs> doko: [17:01:01] <ginggs> this should make petsc build https://launchpadlibrarian.net/237387369/petsc_3.6.2.dfsg1-3_3.6.2.dfsg1-3ubuntu1~ppa1.diff.gz (it skips the 2 process test)
<pitti> doko: pynfft> I'll try to re-run proposed nfft against proposed numpy
<doko> ginggs, is it really limited ram?
<GunnarHj> mapreri: Hi Mattia, any thoughts on my latest comment on bug #1510198?
<ubottu> bug 1510198 in libreoffice-dictionaries (Ubuntu) "Rebase/Reimplement Ubuntu changes upon Debian (possibly upstream them)" [Low,Triaged] https://launchpad.net/bugs/1510198
<ginggs> doko: no no, i explained earlier the changelog entry is rubbish, it is fixed in the version ready to upload (along with removal of ~ppa from the version)
<doko> ginggs, then go ahead
<ginggs> doko: roger roger
<pitti> doko: adt does understand Test-Command:; but as the log says, python-pywcs does't have any tests in xenial-release
<pitti> that's indeed a nasty case which britney can't detect by herself, re-running
<caribou> rbasak: I can't push my new clamav git repo to the previous one, the tags will collide
<caribou> rbasak: want me to delete the previous one & recreate ?
<bdmurray> happyaron: I figured out what bug it fixes my point was the upload was generated incorrectly, probably not on Ubuntu, so there is not a Launchpad-Bugs-Fixed field in it. Subsequently, the SRU report won't link to the bug, tools won't comment on it and the LP janitor won't close it.
<nacc> slangasek: let me rewrite it in a better form for you!
<nacc> slangasek: i apologize, i'll break it up by where the sync points are
<rbasak> caribou: feel free to force push the tags. I would just do that.
<rbasak> caribou: it only matters to those following the tags, and that's just us right now.
<rbasak> Or if you like append .v2 onto the collided tags or something.
<nacc> slangasek: cjwatson: infinity: for the purposes of php5 -> php7, are you ok if i send a merge proposal to demote/promote appropriately in the seeds now (as opposed to once the bootstrap and side builds are done) (with an eventual bug to altogether remove php5* from the archive?)
<caribou> rbasak: want me to push it to a new branch ? or just force overwrite everything ?
<rbasak> caribou: you can force overwrite everything if that's easiest.
<caribou> rbasak: since I restarted from scratch
<nacc> rbasak: can you (i should have emailed, sorry!) put up git trees for numactl and logwatch (so i can send the former's merge request and eventually logwatch's)?
<rbasak> caribou: or just push to a new "repo". Anything you want :)
<caribou> rbasak: fine
<nacc> slangasek: also, i probably will need to update all the debdiffs to have the latest pkg-php-tools and php-pear versioned deps (to force the php7 versions)
<rbasak> nacc: sorry, I'll do that now.
<nacc> rbasak: no need to apologize!
<rbasak> nacc: I've done numactl, I think. Please could you check that my tags and branches match our current expectations? I've also documented what I think is our current status in https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION
<rbasak> I haven't imported the Ubuntu branches. I could, but I think it'd be easier if you did that. It won't matter that we won't have an official import/... tag for our process I think.
<nacc> rbasak: looks right to me
<caribou> rbasak: I pushed a new merge-v2 branch & updated the tags towards it
<rbasak> Argh, I just screwed it up.
<rbasak> Will fix in a moment.
<rbasak> (numactl)
<rbasak> nacc: numactl fixed, and I've pushed logwatch. I can't delete the master branch (as it's HEAD, and there's no protocol way for me to change that), but pretend it doesn't exist.
<rbasak> nacc: apart from that I updated logwatch to fit our workflow for merge number 2 - you should be able to rebase the old logical delta as expected.
<doko> pitti, openmpi/esys-particle: again, the version from testing is tested, not the fixed one in proposed. what's the rationale for testing with the release pocket first?
<doko> openmpi/liggghts the same
<doko> openmpi/lammps the same
<doko> I assume, just retrying won't help here
<doko> sil2100, please could you chase https://bugs.launchpad.net/ubuntu/+source/libgee/+bug/1502094  we really should that get fixed before the release. now having two versions ...
<ubottu> Launchpad bug 1502094 in unity-scope-home (Ubuntu) "libgee-0.8-dev should be used, libgee-dev will be removed from the archive" [Undecided,New]
 * rbasak figured out out to delete master
<doko> sil2100, also https://bugs.launchpad.net/ubuntu/+source/unity-lens-video/+bug/1545078
<ubottu> Launchpad bug 1545078 in unity-lens-video (Ubuntu) "unity-lens-video fails to build from source (using deprecated vala)" [Critical,Confirmed]
<rharper> it is considered bad form to leave an ADT test program (shell) with execution tracing on?  when/if the test fails the log with the trace would be most useful to avoid having to run it again to debug the failure
<rharper> jderose: thanks!  Nice write up
<sil2100> doko: hmmm, thanks, let me pick that up
<doko> sil2100, attaching patches
<jderose> rharper: my pleasure, thanks again for the help!
<rbasak> rharper: I think it's good to leave it on. Similarly we try to do builds with (reasonable) verbosity on.
<rbasak> rharper: you may need "allow-stderr" defined on the test though. I don't remember if "set -x" writes to stdout or stderr.
<rharper> rbasak ok;  I do have that
<rbasak> (IMHO, allow-stderr should have been the default)
<rharper> one more todo on strongswan; dropping lfcgi and clearsilver-dev
<rharper> oh, another question
<rharper> a few of the plugins extend /usr/lib/ipsec/charon binary's required access to files and capabilities that aren't in the default apparmor profile
<rbasak> We've hit this sort of thing before. It seems to be acceptable to add stuff to the default apparmor profile even if it isn't used by default.
<rharper> the plugin that does this isn't installed by default;  how best to append these additional requests in the apparmor profile for only when the plugin is installed
<rharper> rbasak: ok
<rharper> one other thought was the include a #include libstronswan-plugin
<rbasak> (it might be worth leaving a comment or two explaining the use though)
<rharper> hrm
<rharper> rbasak: right, in the changelog as well as the profile
<rbasak> That might work too. I've done it the former way. I'd ask the security team for their thoughts on the latter way.
<rharper> ok, I'll likely follow the former with comments in the profile; they may suggest the alternative then
<tyhicks> I wouldn't add a new libstrongswan-plugin abstraction if the default strongswan profile is going to be the one and only consumer of that abstraction
<tyhicks> just document that the group of added rules are for certain plugins
<rbasak> Thanks tyhicks!
<tyhicks> no problem
<rharper> tyhicks: thanks!
<rbasak> lamont: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-February/016214.html
<cjwatson> pitti,infinity: Could you apply http://paste.ubuntu.com/15027019/ to my hint file?  Won't quite work yet but hopefully will soon
<infinity> cjwatson: Sure.
<ginggs> doko, cjwatson: petsc, slepc and aster built successfully, now retrying getdp
<doko> ginggs, you have to wait until it's published
<ginggs> doko, itchy trigger finger :)
<cjwatson> infinity: thanks
<infinity> cjwatson: I assume this is the "rename click, so we don't have to keep renaming click" transition?
<cjwatson> Yay, that worked.
<infinity> cjwatson: If so, thanks!
<cjwatson> infinity: Yup
<ginggs> how can i tell when something is really published?  I must be looking in the wrong place on launchpad.  Also, why don't things fail with dep-wait any more?
<cjwatson> ginggs: rmadison is the safest check; LP itself can only tell you when something is committed at the start of a publisher run, not when it hits disk
<cjwatson> ginggs: and things do dep-wait, but there have always been exceptions that are hard to analyse correctly.  do you have an example?
<ginggs> cjwatson: thanks - well i'm looking at https://launchpad.net/ubuntu/+source/getdp/2.7.0-0ubuntu2
<nacc> rbasak: ok, thanks!
<ginggs> powerpc shows the red failed build icon
<ginggs> i seem to recall a yellow icon for dep-wait, or am i just confused?
<cjwatson> ginggs: right, that's a case where we can't dep-wait; libslepc3.6.1-dev is available on powerpc but uninstallable, and as far as LP knows that could be resolved in any of various ways
<cjwatson> ginggs: you get a dep-wait if the build-dep is just outright missing
<ginggs> ah ok, that explains it
<lamont> rbasak: yeah yeah
<nacc> slangasek: how do i do the versioned dep for php-pear? the old binary package (built from src:php5) had versions like 56.11+dfsg-1ubuntu3. The new package (built from src:php-pear) has versions like 1.10.1. Should I do an exact match (meaning only in the 1.10.1 family? >= won't work, because i think the older package will match, if I understand it right?
<lamont> rbasak: amusingly, that's what I'm working on right now
<lamont> nacc: I suspect that the new version is actually 1:1.10.1, since the archive would reject it if it had a binary package of a higher version in the archive...  (without looking at the details myself)
<nacc> lamont: ah! that's what i was missing. so they bumped, the epoch, basically?
<nacc> lamont: and the old package had an implicit 0: epoch?
<lamont> if not specified, it's (effectively) 0:.  and the UI hides it most everywhere
<nacc> lamont: does that mean i can specify my build-dep as 'php-pear (>= 1:)' ?
<lamont> generally, one would want >= 1:1.10.1 or such
<nacc> i guess that's true, the first officially released version
<nacc> lamont: thanks!
<lamont> apt-cache policy php-pear <-- shows epoch, and there are other ways to see
<lamont> heh.  starting with dpkg -l :(
<bdmurray> kenvandine: Will you have a look at https://code.launchpad.net/~vorlon/lxc-android-config/apport-job-cleanup/+merge/285016?
<kenvandine> bdmurray, i have that in a silo
<kenvandine> haven't had a chance to test it though
<kenvandine> bdmurray, but i should have it ready for qa early next week
<bdmurray> kenvandine: okay, thanks!
<kenvandine> bdmurray, thx for nagging me :)
<kenvandine> i don't pay much attention to lxc-android-config, not sure if anyone is these days
<Pharaoh_Atem> nacc: have you been updating the etherpad on the php stuff that's succeeded/failed?
<Pharaoh_Atem> I don't see anything there
<nacc> Pharaoh_Atem: no, i need to go and do that
<nacc> the bug has been where i've been trying to document
<slangasek> seb128: ummmm. I'm maintainer of freetype because it was a library that needed attention, I know almost nothing about fonts ;)
<slangasek> nacc: MP for the seeds> fine to have that in advance.  php-pear versioned deps> the 1: at the front of that version number shown in the changelog is called an epoch, it matters for versioned comparisons and is a reset button on the version numbering.  So you want >= 1:1.10.1 for your versioned dep
<nacc> slangasek: great, thanks!
<nacc> slangasek: i put out a debdiff for pkg-php-tools, if that looked right to you, i'll update the other debdiffs to version php-pear and pkg-php-tools correclty
<nacc> and i apologize for that, nuance i missed in working with just my PPA
<slangasek> nacc: pkg-php-tools is already uploaded; I didn't think any further changes were needed on that one? it's already dep-wait in xenial-proposed
<nacc> slangasek: ah ok, you're right, sorry ...
<nacc> slangasek: but if i do the versioning right, then, they will all just dep-wait in -proposed until php-pear gets fixed?
<nacc> "they" => the other packages
<slangasek> nacc: yes
<nacc> slangasek: can i ask you to review the seed merge for the php migration?
<slangasek> nacc: juggling a couple of other critical things at the moment; if you drop me the URL to the MP I'll pick it up
<nacc> slangasek: sure, i can also ask smoser or someone else, but figured you'd have the most context right now
<nacc> slangasek: https://code.launchpad.net/~nacc/ubuntu-seeds/ubuntu.xenial/+merge/285931
<smoser> nacc, i just loaded that page and it says conflicts all over it
<smoser> i assume that is not intended
<nacc> smoser: hrm!
<nacc> no not intended at all!
<nacc> let me look at what i did wrong
<nacc> smoser: argh! lp automatically chose to use platform.xenial again! fixing up
<smoser> :)
<nacc> smoser: slangasek: https://code.launchpad.net/~nacc/ubuntu-seeds/ubuntu.xenial/+merge/285932
<nacc> sorry again!
<smoser> well, that one looks better
<nacc> :)
<smoser> it looks generally sane to me. i'd really rather hvae slangasek do it, although its jsut about as straight forward as could be. s/5//
<nacc> smoser: right, and i think the result (if i understand it right) is that both php-defaults and php7.0* will be in main ... but not sure how that all works (it's all still in the realm of 'magic' to me)
<lamont> when did we change it so that non-root can reboot the box with simply 'reboot'
<nacc> slangasek: ok, updated instructions posted at: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4570466/+files/php7-archive-admins.howtov4
<ubottu> Launchpad bug 1522422 in php5 (Ubuntu) "Update to php 7.0" [Wishlist,Triaged]
<nacc> slangasek: i'll work on updating the debdiffs to version the deps now
<nacc> slangasek: hrm, should i be submitting debdiffs even for the "rebuild" packages? since they will only rebuild properly if we use the version of pkg-php-tools and php-pear that support php7?
<infinity> lamont: I think physical console users have been able to do that for quite a while.
<lamont> ok
<lamont> I guess I've always thrown an sudo in front of it...
<slangasek> lamont, infinity: that would have to be when we switched to systemd, because the upstart implementation didn't hook into policykit etc
<rharper> non-root on systemd says permission denied to /dev/initctl
<rharper> when attempting reboot
<rharper> ssh login; but doubt that local console will give access to /dev/initctl ;  which is a link to/run/systemd/initctl/fifo; which is prw------- 1 root root 0 Feb 12 21:29 /run/systemd/initctl/fifo;
<cjwatson> I think that's only if it can't contact systemd using dbus
<cjwatson> on a local console, I'd expect dbus to be available
<rharper> huh
 * rharper doesnt' really want to try on his laptop 
<rharper> but I'm terribly interested
<cjwatson> /dev/initctl is definitely fallback code in systemd
<rharper> it tries others
<rharper> first, Interactive authentication, logind, and then reboot.target; which all require interactive authentication;
<infinity> Anyhow, it makes sense as a console policy, given we let people reboot from the display manager and the desktop sessions.
<rharper> yeah
<lamont> slangasek: ah!
<infinity> Though I think we also block users from rebooting if *other* users are also logged in.
<infinity> IIRC.
<lamont> this was a window on the desktop
<nacc> infinity: i think i need to transfer my discussions of the php5 -> php7 migration from slangasek to you or another admin :)
<infinity> nacc: Indeed, slangasek is about to be attacked by babies.
<nacc> infinity: :) i'm working on updating my debdiffs to version depend on the right pkg-php-tools package (which is already in dep-wait in proposed)
<teward> cjwatson: can I pick your brain on sbuild, for a minute, in case you know the answer to my question?  I'm happy to go to an offtopic channel or PM to ask if you'd prefer, as it's not 100% an Ubuntu-related question
<nacc> infinity: so i have a couple of questions i posed to slangasek earlier, that i'd like to ask you if you don't mind?
<ilhami> hey guys.
<ilhami> when will Ubuntu allow non-canonical apps to run in the background?
<sarnold> ilhami: try #ubuntu-touch
<ilhami> sarnold, I can't.
<sarnold> ilhami: why not?
<ilhami> banned.
<infinity> nacc: Sorry, a bit in and out right now.
<infinity> nacc: If you're around later, perhaps.  Or tomorrow?  Or Monday?
<nacc> infinity: sure, i'll do my best. it's a holiday here on monday, but i might be able to check in at least a bit
<nacc> infinity: i've done my best to update the instructions at https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4570466/+files/php7-archive-admins.howtov4
<ubottu> Launchpad bug 1522422 in php5 (Ubuntu) "Update to php 7.0" [Wishlist,Triaged]
<nacc> which should get the b-d loops closed off in a side build (with sequence points)
<mapreri> GunnarHj: my thoughts are that most of the requests are reasonable.  I'll consider them better once the last upload of a couple of days ago get out of NEW (due to new dictionary=>new binary).
<mapreri> I'd really love if Sweetshark (=> BjÃ¶rn, current owner of that bug) would comment on #1510198 :\
<mapreri> ginggs: btw, if you have something to say about stuff I do in debian and then get synced here feel free to nag me ;) (though I'm not connected on freenode as often as on OFTC, I have my bouncer here too :P)
<GunnarHj> mapreri: Sounds great. I think that some of the proposed changes in debian/control are important to allow for a pure sync, while others are 'negotiable'. I'm not an expert on the exact meaning of those fields.
<GunnarHj> Yeah, a comment from Sweetshark would be great. OTOH I can't think of a reason why he would keep hesitating.
#ubuntu-devel 2016-02-13
<cjwatson> teward: I don't feel it necessary for people to ask before /msging me, but I'm also about to go to bed, so how about I answer when I'm next around
<teward> cjwatson: sounds good, though I think I solved the issue for now
<happyaron> bdmurray: I see, it was generated on a debian box
<happyaron> bdmurray: should I re-upload it?
<bdmurray> happyaron: please
<happyaron> will do
<ioanm> hi, a few legal question about rolling IoanOS a ubuntu based distro
<ioanm> is it okay if I keep the ubuntu dash logo?
<ioanm> and replace Ubuntu Desktop with IoanOS Desktop, and change the default unity theme to Numix?
<ioanm> and add my PPA
<ioanm> what do I type in lsb-release?
<alkisg> Hi, I'm trying to enable popularity contest in xenial, and the ***server***-side python script dies with:
<alkisg>  File "/srv/popcon.ubuntu.com/www/popcon-submit.cgi", line 30, in &lt;module&gt;
<alkisg>     mkdirs(hashDir,0755)
<alkisg> NameError: name 'hashDir' is not defined
<alkisg> If I try sending the data to debian instead, it succeeds
<alkisg> ...where would I report a server-side error?
<Unit193> shadeslayer: Can you sync libmygpo-qt from Debian?  Causing clementine to get stuck in depwait.
#ubuntu-devel 2016-02-14
 * ogra_ sighs ... phantomjs and arm64 wont really become friends :(
<infinity> ogra_: The phantomjs that was removed from the archive because it sucks? :P
<ogra_> infinity, well, i could live with an npm module from upstream (i need to build snappys webdm package for arm64 ... that needs nodejs' gulp ... which in turn needs phatomjs) ... but they have nno arm64 binaries
<ogra_> ( i dont even konw if gulp actually needs it, but it makes it non-installable apparently)
<infinity> Dear lord, phantomjs vendors Qt5 and Webkit.
<ogra_> building the upstream source gets me lots and lots of ICEs ...
<ogra_> the source package from wily is now building since ~1h on my dragonboard ... didnt fail so far
 * ogra_ crosses fingers
<ogra_> that thing is quite insane though ...
<ogra_> bah ... and indeed it fails the same way
 * ogra_ gives up
#ubuntu-devel 2017-02-06
<anon^_^> everyone must be watching the pooper bowl
<cpaelzer> good morning
<mitya57> Laney: thanks, Sphinx migrated now! \o/
<Laney> mitya57: someone skipped it ...
<tjaalton> doko: hi, just a heads up that mesa et al will migrate to llvm-4.0 for zesty, probably post-ff as llvm-4.0 is still at rc1
<Mirv> tjaalton: will you be the guy to switch the verification tag in bug #1641017? I see a community testing is mentioned, so I didn't dare to tag it as done just based on my testing.
<ubottu> bug 1641017 in mesa (Ubuntu Yakkety) "Mesa 12.0.6 - multiple important fixes, stable branch" [Undecided,Fix committed] https://launchpad.net/bugs/1641017
<Mirv> I did tag the other two bugs, especially as I happen to have Radeon 7750 mentioned in the other bug
<tjaalton> Mirv: yeah, guess I should
<rbasak> cpaelzer: could versioning the symbols be a solution?
<lolek> hello everybody, I hope this is not wrong channel for this question, I'm trying to understand how the global menu in ubuntu is being done as I'm trying to fix one application behavior
<lolek> so far I thought it's taking the app menu that's not hidden and is using it as a menu, but it seems it's not working like this, so my question is how can I have multiple global menus and switch between them?
<juliank> I'm thinking about just pushing ndiswrapper 1.60-3 from yakkety/zesty to xenial to make it build with newer kernels (bug 1625089). Opinions on that?
<ubottu> bug 1625089 in ndiswrapper (Ubuntu Xenial) "ndiswrapper <= 1.60-2 ADT test failure with linux 4.8.0-11.12" [Undecided,New] https://launchpad.net/bugs/1625089
<juliank> It's a very leaf package in universe, the changes (https://anonscm.debian.org/git/collab-maint/ndiswrapper.git/diff/?id=debian/1.60-3&id2=debian/1.59-6) are fairly tiny, and I don't really want to bother rolling custom updates for stable series for a project that's on basic life support.
<juliank> apw: ^ basically ready to go
<juliank> AKA package built, not signed yet...
<juliank> Uploaded now, but oh well, 1.60-3~ubuntu16.04.1 might not have been the best versioning choice - I think it should have been 1.60-3~ubuntu0.16.04.1?
<juliank> or well, it's a ~, so it does not really matter
<cpaelzer> rbasak: could work, but then how much more symbols would it be
<cpaelzer> rbasak: that is part of the "it might be an upstream bug, but I have to fix packaging for now" story IMHO
<rbasak> cpaelzer: it would be the same number of symbols per shared library still though, no?
<rbasak> IIRC, libmysqlclient20 does this.
<juliank> There's an ndiswrapper 1.61 now, but it failed to build or something, so no upload of that one ...
<juliank> If we can just upload the new uploads to xenial (assuming neither I nor upstream do anything except basic life support), we can even continue having working ndiswrappers in xenial with new kernels.
<juliank> We have the same problem with new kernels in precise and trusty, but they never got an update for ndiswrapper (but they probably also have no automated testing of dkms builds)
<juliank> Unfortunately, I cleaned up the packaging after trusty/vivid (wily?) [see 1.59-4 changelog], so these would require backporting quite some stuff which I'm not really fond of doing (it's up for grabs if someone is interested in that stuff)
<cpaelzer> rbasak: yeah I just meant this is a fix that I might propose upstream for the following versions
<cpaelzer> rbasak: do you have a pointer to the libmysql example to I can refer to it?
<rbasak> cpaelzer: I'm not sure, sorry. I'm not even sure how to confirm the symbols are versioned. I thought they were, but objdump/nm don't seem to think so.
 * rbasak 's linker-fu is weak.
<cpaelzer> rbasak: honestly I just think different versions of same so in the same exetubale space are doomed to cause trouble - the question for me is how to resolve that so that it won't happen
<apw> juliank, i can reject that for you if you want to change the version
<juliank> apw: Nah, I think it's normal for the ~ ones
<cpaelzer> rbasak: after I summarized I'm kind of leaning towards the symlink-compat-lib solution I described for now
<juliank> Only the non-~ ones have a 0. in front usually
<cpaelzer> rbasak: and starting the discussion upstream how they want it in the long term
<cpaelzer> rbasak: yet - I feel unsure enugh still that I'd really want some feedback from the more experienced packagers
<apw> juliank, i suspect they are either ubuntu0.16.04.1 or ~16.04.1, but as long as they are consistent between releases so they sort right it doesn't matter much
<rbasak> cpaelzer: I agree it's problematic, but I also think it's inevitable for complicated applications. libmysqlclient is an example - it may be that two different libraries need that for certain apps. If symbols are versioned, it should work correctly I think. The problem might come if the library breaks ABI only.
<rbasak> (breaks ABI without declaring it, that is)
<rbasak> Or, if the application wants to pass handles or data across different ABI versions of the same library. Then I'm not sure how to declare that relationship in dependencies in a clean way.
<juliank> apw: Right. It just felt kind of wrong without "ubuntu" in there IMO (that would be 1.60-3~16.04.1)
<juliank> pbuilder has 	0.227~ubuntu16.04.1 similar to my ndiswrapper upload, I think that looks nicer
<apw> juliank, then that is good enough
<juliank> apw: I accidentally have "(LP: ##1625089)" [two #] in the changelog, but the entry below it has the correct one, so the bug tracking works fine... :)
<apw> heh, it is one of those days isn't it
<juliank> apw: I love how you are talking to yourself in the semi-automated "please test" message :D
<apw> juliank, heh .. lovely isn't it
<apw> once the publisher gets caught up i'll wack that one and get the test rerun
<mapreri> juliank: that's proposed for xenial-backports, not xenial-updates though.
<juliank> mapreri: Ah, well. Both are technically backports, though, one is just tiny enough to SRU it
<mapreri> (but apparently in ubuntu the same versioning is used for all pockets)
<juliank> mapreri: Well, there's no clear rule on that anyway, except for the security rules.
<juliank> And these don't have ~ rules ...
<ogra_> pitti, oops ... http://planet.ubuntu.com/
<ogra_> i guess you're cached there ...
<pitti> ogra_: yeah, I got re-hacked after restoring everything, I permanently shut it down now
<pitti> so planet's cache needs to get purged
<ogra_> yeah, no idea who owns planet nowadays
<ogra_> or how one would purge it
<juliank> ogra_: maybe pitti's attacker can help :D
<ogra_> lol
<juliank> pitti: Your blog got hacked twice?
<juliank> that's incredible.
<pitti> two days ago already, so three times
<juliank> I did not know you were such a valuable target :D
<pitti> daily.2 looks good
<pitti> hugo looks pretty good, and https://github.com/SchumacherFM/wordpress-to-hugo-exporter seems to do quite an amazing job
<juliank> probably
<juliank> I'm thinking of converting my ikiwiki to jekkyl, dropping the host and just hosting my website on github ...
<smoser> bdmurray, when you arrive... were you looking at the xenial cloud-init sru ? (you requested SRU info on one of the bugs, i've added it). is there anything you need from me.
<nacc> rbasak: around?
<rbasak> nacc: o/
<rbasak> cpaelzer, nacc or maybe caribou: I'd appreciate a review of my squid3 merge please. https://code.launchpad.net/~racb/ubuntu/+source/squid3/+git/squid3/+merge/316496
<rbasak> I'll upload it in a week if nobody has had time to review by then.
<rbasak> Review workflow at: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow#Reviewing_Merges
<nacc> rbasak: I will try if I can find the cycles :)
<sarnold> it's 90% changelog, 90% QRT tests
<nacc> sarnold: yeah, because a lot of stuff is being dropped in the merge (afaict)
<rbasak> It's the total diff againt Debian you're seeing in the preview diff. It's a good sign when that's all that's remaining :-)
<rbasak> https://git.launchpad.net/~racb/ubuntu/+source/squid3/log/ may be more helpful in understanding what the delta actually is.
<rbasak> And https://git.launchpad.net/~racb/ubuntu/+source/squid3/log?id=logical/3.5.12-1ubuntu8 is what it was before.
<dobey> who knows anything about lubuntu?
<wxl> dobey: #lubuntu(-devel)
<dobey> wxl: well i just need to know if it depends on xdg autostart functionality for starting indicators, or if it uses upstart or systemd instead
<dobey> and if fossfreedom is around, i need to know the same about budgie
<wxl> dobey: the indicators are all within lxpanel which is started with autostart
<dobey> wxl: so indicator-messages and indicator-application are started with autostart?
<fossfreedom> dobey: same on budgie - budgie-desktop starts the indicator
<wxl> dobey: yep.
<dobey> hmm. :-/
<dobey> hmm, no, it looks like lxpanel is actually loading .so files for indicators? or am i reading this code wrong?
<wxl> yepp. that's what i'm saying. the indicators are plugins that are built into lxpanel.
<wxl> but lxpanel is loaded with autostart, which in turn loads those indicators.
<dobey> hmm, i wonder why indicator-messages and indicator-sound are seeded in lubuntu
<wxl> hm. maybe i'm wrong
<wxl> there's no -messages in a yakkety vm but -sound is there
<dobey> but indicator-sound doesn't provide libsoundmenu.so
<wxl> -application is there, too
<wxl> but not messages
<wxl> and this coincides with the manifest
<smoser> bdmurray, i've just uploaded cloud-init_0.7.9-0ubuntu1~16.04.2_source.changes
<smoser> which has a fix on the sru you let in earlier today.
<smoser> :-(
<smoser> would appreciate a quick review and let that into -proposd.
<bdmurray> smoser: accepted
<smoser> thanks
<wxl> dobey: libsoundmenu.so is provided by indicator-sound-gtk2 which lubuntu does have
<dobey> wxl: yeah, i see that now, but i don't understand why that depends on indicator-sound
<dobey> i also don't see any evidence that budgie is using ubuntu indicators at all
<smoser> bdmurray, can you reject the upload to yakkety-proposed
<smoser> for cloud-init.
<smoser> and i am uploading it again right now.
<wxl> dobey: well, i can't speak as to why indicator-sound-gtk2 depends on indicator-sound, if that's what you mean
<dobey> wxl: sure. was just pointing out what i discovered. i'm in this rabbit hole because i'm making changes to indicator-sound that could potentially break some of the other flavors, so trying to make sure i don't
<wxl> dobey: speaking for lubuntu, i appreciate your consideration :)
<Unit193> infinity: Howdy.  Is there something I can follow to track the progress of geoip-database getting an "automatic" backport?  Also, you seem to be the dpkg guy.  Know if that's getting merged for zesty, or is that held up on LP .buildinfo support?
<fossfreedom> dobey: in the case of Ubuntu Budgie - we do not make any use of any of the indicator-* packages.  So no impact on our side if you make changes to indicator-sound
<fossfreedom> cjwatson: just wondering if our (Ubuntu Budgie) merge request is nearing the top of your todo list?  TIA https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1659278
<ubottu> Launchpad bug 1659278 in debian-cd (Ubuntu) "Ubuntu Budgie does not boot directly to ubiquity try/install screen" [Undecided,In progress]
<wxl> cyphermox: caribou: if i understand this whole patch pilot thing correctly, you guys are on call to help with sponsorship, no? i've been trying for almost a week now to get my konversation in yakkety sponsored so i can pursue an sru https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/1635911
<ubottu> Launchpad bug 1635911 in konversation (Ubuntu Yakkety) "Konversation crashes on quit - please package latest version" [High,Triaged]
#ubuntu-devel 2017-02-07
<armourz> Can anyone teach me a few things about ubuntu dev?
<sarnold> irc works best with concrete questions :)
<Unit193> sarnold: How are you doing today?
<sarnold> Unit193: I'm great super, thanks for asking! :)
<sarnold> Unit193: how're you tonight?
<Unit193> Quite alive, though coffee gone now.
<sarnold> oh no! I too am without coffee
<sarnold> but tomorrow morning I shall get more
<cpaelzer> rbasak: FYI - I found prior art to my packaging problem in several other packages, libhwloc seems to be the closest to my case
<cpaelzer> rbasak: on that "template" I'll start to develop a solution for DPDK - except some feedback convinces me otherwise
<cpaelzer> I might reply to my own ubuntu-devel post once I have tested it successfully
<cpaelzer> it might be easier to ack/nack a proposed solution than to create a new one based on my description
<rbasak> cpaelzer: sounds good
<doko> nacc: so dropping everything from ldb is fine for now. I had a chat with jelmer at fosdem about python3 & samba, so we might re-introduce these packages again, but not yet for 17.04. about the s390x bits ... maybe drop those as well, and see what happens
<xnox> s390x ldb was fixed upstream, so recent upstream should be fine without any s390x delta
<xnox> nacc, ^
<xnox> doko, i missed both you and jelmer at fosdem =(
<doko> xnox: have you been there?
<xnox> doko, yeah i was at fosdem.
<cyphermox> wxl: looking
<cjwatson> fossfreedom: nothing debian-cd related is on my to-do list, nor do I intend for it to be; while I gave some initial advice, somebody else will need to review
<cyphermox> fossfreedom: fwiw that won't make the cd boot straight to maybe-ubiquity, it should just happen by default if you don't touch anything, unless what you want is a CD that behaves a bit like Kubuntu
<nacc> doko: xnox: ack, I'll refresh my merge and verify
<nacc> xnox: i'm guessing, though, debian has not picked up a recent enough upstream (1.1.27 is what is currently packaged, I see 1.1.29 at least on upstream tarball page). Looking for a changes/news to figure out which version included the fix
<nacc> xnox: hrm, upstream (in the bug) said it was fixed in 1.1.26, but we are carrying it currently as delta...
<xnox> debian is frozen, and will not take new point releases.
<xnox> nacc, if you want to can request ship newer release in ubuntu.
<Laney> experimental exists
<nacc> xnox: ack, i'll see if it is needed or not
<nacc> xnox: oh nm, we probably coudl have dropped it on last merge, it was added in 1.1.24, fixed upstream in 1.1.26, duly noted!
<nacc> doko: so the only two bits of delta that i'd like (double) verification on then are the "symbols for the extension" module and the encoding of the SOABI (which does have a hardcoded py3, so can probably also be dropped). So presuming neither of those are critical, would you suggest we sync ldb?
<rbasak> mterry: is the MIR in bug 1619239 approved then? I think so as you set Fix Committed, but I want to make sure.
<ubottu> bug 1619239 in tomsfastmath (Ubuntu) "[MIR] tomsfastmath (runtime dependency of clamav)" [High,Fix committed] https://launchpad.net/bugs/1619239
<mterry> rbasak: yeah -- now it just needs an archive admin to push the button to promote it
<rbasak> mterry: thanks. We need to sync clamav first to pull it in first I think.
<rbasak> caribou: ^
<mterry> rbasak: ah yeah
<rbasak> I just wanted to check we were good first, because otherwise our delta can stay.
<nacc> rbasak: do you have bugs filed for the two pkgs you looked at before that failed to import (and which were they?)
<rbasak> Yes, one moment.
<nacc> rbasak: thanks
<rbasak> nacc: bug 1661212 is one.
<ubottu> bug 1661212 in usd-importer "Importer crashes when ubuntu/<stable release>-devel branches do not fast forward" [High,Triaged] https://launchpad.net/bugs/1661212
<rbasak> I didn't note the package name :-(
<nacc> rbasak: yeah that's what i needed :)
<rbasak> I can dig it out I think.
<nacc> rbasak: can you update the headline with it onc eyou find it?
<rbasak> ack
<rbasak> nacc: the other was bug 1661092: snapd.
<ubottu> bug 1661092 in usd-importer "Import fails when debian directory is a symlink" [High,Fix released] https://launchpad.net/bugs/1661092
<nacc> rbasak: ok, just to check, was the other bind9?
<rbasak> nacc: it was ntfs-3g
<nacc> rbasak: ack
<rbasak> nacc: we want one bug per importer bug. Perhaps the importer failures should be separate bugs?
<nacc> rbasak: they are right now
<nacc> well, i'm filing them one at a time as we get them :)
<rbasak> nacc: trouble is, I'm turning the bug into "importer can't do X" where X is quite specific. Because that's what the importer bug actually is.
<rbasak> But then we'd end up duping multiple failures. Really catching up on old imports is a separate dimension.
<nacc> rbasak: yeah, i'm suggesting do that and eitehr also file a bug for a failed import
<nacc> rbasak: or put the specific case in the subject line as well
<nacc> rbasak: right now, i'm filing a bug per failed import, independent of bugs in the code
<rbasak> nacc: I think we should have separate bugs. One for the root cause, one per failed import.
<nacc> rbasak: agreed
<rbasak> Because otherwise as soon as the importer bug is fixed, the failed import notes disappear.
<nacc> rbasak: so you'll file two more? :)
<rbasak> nacc: I should be able to just import snapd. But yeah, I can file one for ntfs-3g.
<nacc> rbasak: sounds good
<nacc> rbasak: oh right, you have the fix for snapd ready, i guess (that's the symlink one right ?)
<rbasak> nacc: right
<nacc> rbasak: thanks
<rbasak> nacc: snapd imported and pushed
<rbasak> (successfully)
<nacc> rbasak: awesome, nice work
<rbasak> nacc: and I filed an import bug for ntfs-3g bug 1662611
<ubottu> bug 1662611 in usd-importer "ntfs-3g failed to import (2017-02-02)" [Undecided,New] https://launchpad.net/bugs/1662611
<nacc> rbasak: appreciate it
<nacc> slangasek: re: the cloud-image change for open-iscsi initiator name. Do you have any suggestion for how to test my change locally?
<slangasek> nacc: to test that the image builds and boots the way you expect?
<nacc> slangasek: yeah
<nacc> slangasek: specifically generating a new initiator name
<slangasek> nacc: you might want https://github.com/OddBloke/ubuntu-standalone-builder
<slangasek> (not "local", it needs a cloud - but doesn't require special LP setup)
<nacc> slangasek: ok, thanks!
<rbasak> nacc: looks like phpunit-mock-object is a really minor merge left over from your work on the PHP transition. Would you like to take care of it?
<rbasak> cpaelzer: how do you feel about looking at the nis merge? That's from when you first started - remember? :-)
<nacc> rbasak: ack, i'll get the php one(s) done this week, ideally
<rbasak> doko: are you planning on merging ldb?
<nacc> rbasak: i'm doin git
<nacc> *doing it
<nacc> rbasak: in consultation with doko, as it's needed for samba
<rbasak> Ah, OK. I'll give you the work item then :)
<nacc> rbasak: ack
<rbasak> tjaalton: so the latest sssd in Debian requires src:http-parser which is in universe. Looks like the new "secrets" support?
<rbasak> For now, I can build without that it looks like, as there's a configuration flag for that. Or, do you want it MIR'd?
<rbasak> "http parser" sounds security sensitive. Especially for the "secrets" feature.
<rbasak> So maybe it'll have to be next cycle?
<sbeattie> rbasak: there's a MIR request for http-parser already.
<sbeattie> https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957
<ubottu> Launchpad bug 1638957 in http-parser (Ubuntu) "[MIR] http-parser, dependency of sssd" [High,Incomplete]
<tjaalton> yeah, the ball is on the security team now ;)
<rbasak> Oh. Thanks!
<rbasak> I just prepared an upload to disable the secrets service for now.
<rbasak> Should I upload that pending the MIR, and then we can revert and sync when appropriate?
<tjaalton> I'm fine either way
<rbasak> Then at least we'd get testing on the newer sssd, even if without the secrets service.
<tjaalton> it's in debian testing too
<rbasak> OK I'll upload for now. Then if the MIR doesn't get done in time at least we have something automatically.
<tjaalton> right
<rbasak> So dogtag is holding up nss migrating, which presumably is due to tomcat 8.5 too?
<rbasak> tjaalton: are we certain that tomcat 8.5 needs removing?
<rbasak> It has made it to testing.
<tjaalton> rbasak: yes
<rbasak> Is there an ~ubuntu-archive bug on this?
<tjaalton> no
<rbasak> I'm not sure I follow the reasoning, so if not would you mind filing one with an explanation please?
<tjaalton> didn't think of that
<tjaalton> https://fedorahosted.org/pki/ticket/2560
<tjaalton> I'll file one
<rbasak> Thanks!
<tjaalton> did send an email to ubuntu-release, but a bug makes more sense
<rbasak> Then I can point people to the bug for current status and when explaining blockers :)
<tjaalton> the reason why 8.5 was "rushed" for stretch was that 8.0 will be EOL before stretch is
<tjaalton> but it's not an issue for 17.04
<rbasak> That makes sense.
<tjaalton> well, building reverse-depends would've shown that it was a bad decision.. though it makes my life easier not having to support freeipa on stretch :)
<tjaalton> so, a bug against tomcat with ubuntu-archive assigned?
<rbasak> Yes
 * rbasak EODs
<tjaalton> done, bug #1662654
<ubottu> bug 1662654 in tomcat8 (Ubuntu) "Please remove tomcat 8.5 from zesty-proposed" [Undecided,New] https://launchpad.net/bugs/1662654
<jgrimm> nacc, one thing noticed while getting powersj going on merges.. ubuntu-git-tools isn't documented there, tho the tools are part of the process.. always good having someone new go through documentation
<nacc> jgrimm: what's ubuntu-git-tools?
<nacc> jgrimm: oh, rbasak's old repo? they are all in the importer repo now
<jgrimm> nacc, oh, didn't realize they are in there too, i'm using from cloned repo
<nacc> jgrimm: yeah, we migrated it a while back
<nacc> the other repo is defunct at this point
<jgrimm> nacc, i see them there now. i only had ./bin in my path too, so i'll switch
<nacc> jgrimm: yeah, probably should move them now that we have a bin upstream
<nacc> jgrimm: please file a bug on that, it's probably a worthwhile cleanup
<jgrimm> nacc, cool cool. tx
#ubuntu-devel 2017-02-08
 * slangasek wonders if there's a reason not to use COMPRESS=xz by default in initramfs-tools these days
<Unit193> Last time I asked micahg, he said rsync/zsync'ability.
<Unit193> Takes longer, but better sizes.  I've messed around with it.
<slangasek> Unit193: that doesn't make sense.  Nobody cares about rsyncing of an initramfs by itself
<Unit193> slangasek: I read squashfs when you said initramfs, I'm now wondering why I did that. >_>
<slangasek> Unit193: to be clear, I'm talking about the initramfs generated on one's system in /boot
<slangasek> hah ok
<Unit193> So yes, sorry.  Nevermind.  That's supposed to be a "size vs speed" argument in the initramfs.
 * Unit193 shrugs.
<slangasek> the tradeoff of xz is that it takes longer to compress and uses more memory
<slangasek> which is more of an issue on end-user systems than it would be on the buildds
<sarnold> slangasek: fwiw zstandard is getting a lot of traction; if this image is to be trusted (ha) zstd should be significantly faster to decompress than xz (which is lzma-derived) https://raw.githubusercontent.com/facebook/zstd/master/doc/images/DCspeed5.png
<sarnold> of course some systems build initrds far more often than they use the initrds
<cjwatson> Oh joy another compression format
<sarnold> cjwatson: yay! just what the world needed!
<slangasek> sarnold: I'm not looking to adopt a fringe format, just musing over gzip vs. xz which we already support :)
<cjwatson> My cup overfloweth
<slangasek> sarnold: and faster decompress speed is not the interesting metric
<Unit193> https://xkcd.com/927/
<sarnold> it might be on those iot devices our parents keep buying
<cjwatson> Compression speed for initramfs used to be a pretty significant issue not that long ago, especially because the triggers for update-initramfs are often only partially effective
<cjwatson> I haven't measured it at all recently
<slangasek> sarnold: in this context, xz is already plenty fast, and generally pays for its own decompress speed with the disk read savings
<sarnold> it's still annoying :/
<slangasek> but the compressing is costly
<sarnold> if you just wanted fast you'd pick lz4
<slangasek> see also: "oh joy another compression format"
<sarnold> :)
<cjwatson> unscientific test with my ~2yo laptop's latest initramfs, 13.9s for gzip, 2m21s for xz, default compression levels in both cases
<cjwatson> this isn't my call any more thankfully, but I'd call that unacceptably slow for a default
<sarnold> holy cow
<sarnold> I already hate how long it takes to delete three kernels
<sarnold> it it turned into "come back in ten minutes"
<Unit193> sarnold: Enable lzop first, then purge 3 kernels, then flip back. >_>
<sarnold> oh joy another compression format
<slangasek> :D
<slangasek> yeah, here I'd like the smaller size because plymouth+cryptsetup, but that's not a sensible default
<sarnold> speed: lz4, lzop, zstd, gzip, xz   size: xz, gzip, zstd, lzop, lz4   http://pastebin.ubuntu.com/23951331/
<sarnold> I'm kind of feeling like lzop won this one. :) good call Unit193 :)
<Unit193> sarnold: Amusingly, I don't notice much of a difference when changing the initramfs-tools config.
<tsimonq2> So is MOTU a subset of Core Dev?
<tsimonq2> Little confused after reading this: https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Core_Developers
<tsimonq2> Or is Core Dev *just* Main and Restricted?
<Unit193> Oh speaking of which, I need to seek someone out about a free sync. >_>
<sarnold> tsimonq2: I don't think there's a formal relationship between motu and core-dev; motu can upload to universe and multiverse, core-dev can upload everywhere
<Unit193> sarnold: -backports?
<sarnold> Unit193: is that still alive?
<sarnold> I have no idea there..
<Unit193> Not really.
<Unit193> I think I have a few stale bugs there.
<Unit193> sarnold: If you're feeling very sync happy, synergy can be force sync'd from experimental.  If not, I'll poke Mirv. :3
<sarnold> Unit193: sorry, I can't do syncs, just -security pocket things; better poke Mirv (sorry Mirv)
<Unit193> Ah, I thought you had super powers.  Alrighty.
<tsimonq2> sarnold: Oh, so if one gets Core Dev, they inherit MOTU?
<Unit193> MOTU is basically a subset of Core.
<sarnold> hey, indeed, core-dev is a member of motu https://launchpad.net/~ubuntu-core-dev/+participation
<tsimonq2> Unit193: That was my question: tsimonq2> So is MOTU a subset of Core Dev?
<tsimonq2> Unit193, sarnold: Thanks :)
<psusi> so investigating a bug report has lead me to a regression in udev behavior that may be responsible for a few other bug reports I've seen: open a disk RW ( dd if=/dev/zero of=/dev/sda count=0 ), and udev deletes and recreates all partitions on that device
<psusi> this causes the read only flag to be reset on the partitions, as well as causing unity to re-add previously removed partitions to the launcher.. anyone have any idea why the heck udev would be doing this?
<psusi> i.e. is it something silly they built into udev or is it one of our event handling scripts?
<psusi> ( stopping udev prevents this from happening, and running it with --debug shows that it is deleting and recreating the partition dev nodes )
<sarnold> probably because detecting -actual- writes would be quite difficult
<psusi> write, no write.. open r/w... modified partitions, or not... udev has no buisiness deleting and recreating partitions
<sarnold> so detecting that it was opened for writing is the best that could be done, and they might assume that they'd then need to re-scan partition tables because _anything_ might have been done to it..
<psusi> *especially* if the partitions already match the partition table ( this is what parted has always done to avoid this: if it already agrees with the new partition table, leave it alone )
<psusi> the funny thing is that udev does not do this for loop devices, but does for scsi_debug
<psusi> guess I can try removing all of the scripts...
<psusi> looks like it's a rules script
<psusi> hrm.. apparently it is persistent-storage.rules
<Mirv> Unit193: done, please follow up that everything seems fine with it
<Unit193> Mirv: Danke.
<cpaelzer> rbasak: a lot depends on how kind or unkind the resolving of remaining qemu/dpdk issues goes
<cpaelzer> rbasak: but I'll at nis to my maybe this week note and we can re-check next tuesday (2 days before FF then oO)
<cpaelzer> we might even check on the Team hangout if I had a chance to start at least
<Mirv> Unit193: there are two failing tests on s390x and powerpc that don't happen on Debian. I've started a rebuild of both but if they persist they will block the package.
<Unit193> Mirv: I noticed, was going to ask about that because they were just fine: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/7468050/+listing-archive-extra
<Mirv> Unit193: heh, your build exactly lacks the powerpc (32-bit) and s390x ones :) so not sure.
<Mirv> or your PPA
<Unit193> Ah right, couldn't enable those.
<Mirv> because s390x and powerpc are not allowed in normal PPAs currently. so just bad luck of not being able to catch it.
<Mirv> yes
<Mirv> it's nice though that most archs are nowadays available
<Unit193> Yep, though I just use it for test builds, don't actually need 'em. :3
<Mirv> Unit193: ah, and my mistake, I checked the wrong logs, they also do fail on debian experimental so actually a rebuild won't help
<Mirv> Unit193: https://buildd.debian.org/status/package.php?p=synergy&suite=experimental
<Unit193> Nobody even really cares about ppc nor s390x anyway. :3
<Mirv> Unit193: don't say that when xnox listens ;)
<Unit193> Too late, you pinged him. :D
<Mirv> Unit193: anyway, the 32-bit powerpc and s390x desktop users are few enough so I think you could patch out the two clipboard tests for those archs temporarily..
<Mirv> s390x is a very important architecture, but not really on desktop, 32-bit powerpc starts to be not very important
<Mirv> Unit193: I filed bug #1662797 so that it can be tracked outside IRC
<ubottu> bug 1662797 in synergy (Ubuntu) "1.8.7-stable+dfsg.1-1 FTBFS on s390x and powerpc" [Critical,New] https://launchpad.net/bugs/1662797
<CRogers> Hey folks. When an application opens a file, the file browsing dialog > is that handled by nautilus in ubuntu based systems generally?
<sladen> CRogers: the "Open dialogue" comes from the Framework (Gtk, or Qt)
<sladen> CRogers: but the application is responsible for opening the named file itself
<sladen> CRogers: an alternative is to use eg. Nautilus (the file manager in Ubuntu) to pass a filename to an application
<CRogers> sladen: Okay, so if I wanted to be able to get the file-path from the bar with ctrl+l like in nautilus, I'd have to talk to the gtk3 folks?
<sladen> CRogers: https://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html
<CRogers> sladen: Awesome, thanks.
<sladen> CRogers: but Ctrl-l should work automatically...
<CRogers> ctrl+l opens an empty location box.
<CRogers> good for pasting, not for copying the current url in the open dialog.
<CRogers> Nautilus replaces the file folder buttons with the actual current file path, which is much more useful.
<sladen> CRogers: so you want the Nautilus file-open dialogue in your own application?
<CRogers> I want to be able to copy the current working directory to nautilus.
<CRogers> from the open dialog
<sladen> copy to where
<CRogers> Here's my use case:
<sladen> do you want to spawn a new copy of nautilus at some particular starting directory?
<CRogers> I'm opening or saving a file. I discover I need to edit something in that folder before uploading attachments, or saving something to that directory.
<CRogers> So I open nautilus, and I want to be in that same directory.
<CRogers> but the only way to get there is to navigate manually.
<CRogers> Which is bogus. :)
<CRogers> It's a complete waste of time.
<CRogers> So it would be cool if I could copy and paste the file path from the open dialog, as one can with almost any other modern file browser available today.
<sladen> or the opposite example: The image viewer 'eog' has "File->Open containing folder"  when all I really wanted was to copy-and-paste the path to a terminal
<CRogers> exactly.
<CRogers> It should be consistent.
<CRogers> There's no reason to hamper that ability, just fill the blank location box with the current location.
<CRogers> done deal.
<CRogers> So who do I bug? :)
<sladen> CRogers: file a bug on Launchpad!
<sladen> CRogers: so that it doesn't get lost
<CRogers> sladen: Will do. I want to get an idea of if the devs will consider it first, before I take the time.
<CRogers> Because my bug reports are awesome, and contain graphics, and other useful imput, and they take hours to prepare.
<CRogers> *input too. ;P
<sladen> CRogers: remember to link  https://irclogs.ubuntu.com/2017/02/08/%23ubuntu-devel.html#t08:44  in the bug report for context
<CRogers> sladen: Oh, okay, if you think that will help. I provide full context and graphics to illustrate with my bug reports in order to avoid making devs read through logs.
<sladen> CRogers: yes, diagrams help
<CRogers> sladen: thanks for your help.
<cult-> hello
<cult-> the maintainer of the package is not responding, but we have this issue, what else can be done? https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
<ubottu> Launchpad bug 1588330 in libodb (Ubuntu) "Incompatible builds of libodb and libodb-mysql" [Undecided,Confirmed]
<CRogers> sladen: So it seems no one is maintaining the filechooser dialog.
<CRogers> So I may have to submit a patch myself, or get someone outside to do it.
<CRogers> In this case, a bug report will do very little good it seems.
<rbasak> cpaelzer: that sounds fine, thanks.
<rbasak> tjaalton: so sssd-ad has grown a universe dependency on adcli. Any opinions on how to resolve this? Should we just move sssd-ad to universe?
<cpaelzer> infinity: doko: I beg a pardon (trying to not be annoying but getting attention can be hard) but if you could look at https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039664.html that would be great.
<tjaalton> rbasak: it was requested on a lp bug
<doko> cpaelzer: well, the ultimate test would be to cross build the package ... I didn't check if setting the CC is still necessary
<tjaalton> rbasak: sssd meta-pkg depends on sssd-ad
<rbasak> bug 1590471, thanks
<ubottu> bug 1590471 in sssd (Ubuntu) "add adcli as sssd dependency" [Medium,Fix released] https://launchpad.net/bugs/1590471
<rbasak> Looks like I didn't realise adcli was in universe at the time.
<cpaelzer> doko: if that is all, would any cross build do in your opinion?
 * cpaelzer is heading to try his first cross package build
<tjaalton> rbasak: :) it's hardly a huge burden to maintain if it's moved to main
<rbasak> tjaalton: it sounds like the dependency isn't needed to fix the reported problem, and it was a bug in sssd that having adcli installed happened to mitigate?
<doko> cpaelzer: any target arch? sure
<cpaelzer> ok, thank you doko
<tjaalton> rbasak: I need to think about it, after lunch
<rbasak> tjaalton: sure, thanks
<cpaelzer> doko: it builds fine following https://wiki.ubuntu.com/CrossBuilding
<cpaelzer> doko: but, the old one we've had since Trusty also builds fine when taken from Debian without the Ubuntu Delta
<cpaelzer> need to check the binaries
<cpaelzer> doko: ha got it
<cpaelzer> doko: without the fix the old cross build did not error out, but instead created x86_64 binaries in arm deb packages
<cpaelzer> doko: that is now correct in the new packaging
<cpaelzer> doko: thanks for your guidance
<jbicha> CRogers: it would be better if you would file that bug with gtk+ directly (not Launchpad)
<CRogers> jbicha: Yep, been talking with the #gtk+ devs
<CRogers> thanks. :)
<CRogers> It seems no one is maintaining that package at the minute.
<CRogers> (gtk open dialog package)
<CRogers> So I'll likely need to patch it myself.
<CRogers> Or get someone tremendously cool to do it.
<cult-> if there's no package for a standard architecture such as amd64, can I do anything else than filing a bugreport or contact the maintainer?
<cult-> can somebody here trigger the build for it?
<ginggs> cult: you could attach 'no-change rebuild' debdiffs for each package you want rebuilt to the bug, and then subscribe ubuntu-sponsors (see LP: #1515031 for an example)
<ubottu> Launchpad bug 1515031 in llvm-toolchain-3.6 (Ubuntu) "Release no-change rebuild for ocaml transition" [Medium,Fix released] https://launchpad.net/bugs/1515031
<ginggs> cult- ^^
<cult-> i sent a letter to mailing list, will see if someone do it
<Laney> wow, some old stuff
<Laney> thanks to whoever did a moderation run on -devel@
<cjwatson> yw
<Laney> I used to do it when I got moderation email from DMB lists
<cjwatson> cult-: not seeing your mail on any mailing list I've checked.  where did you send it?
<mapreri> jbicha: It seems to me you discarded all the past liferea merges entries in the changelog in your last upload.  Please don't do that.
<cpaelzer> pitti: you might still remember bug 1630909 - that now haunts me in similar fashion on ppc64el as well
<ubottu> bug 1630909 in autopkgtest (Ubuntu) "failing console access on s390x" [Undecided,New] https://launchpad.net/bugs/1630909
<cpaelzer> pitti: I was able to reconfig the system to spawn actual consoles on the ttyS provided (no root console, nomal ones)
<cpaelzer> pitti: but when using user/password it gets over the first steps but then fails http://paste.ubuntu.com/23953966/
<cpaelzer> pitti: I go for lunch now and will try to make the S1 a root console to avoid needing the user/pass logic
<xnox> cpaelzer, you can't create extra consoles like that
<xnox> cpaelzer, you should use -no-defaults such that slcp console is not configured by default
<cpaelzer> xnox: ppc
<xnox> and such that you can define slcp console by hand, and redirect it to where you want.
<cpaelzer> xnox: ppc
<xnox> right, but report is about s390x =)
<xnox> fair enough
<cpaelzer> sure, there we went the way you describe
<jbicha> mapreri: Ubuntu-specific changelog entries get discarded when packages are synced, if you want to see the full changelog I think you really ought to visit https://launchpad.net/ubuntu/+source/liferea/+changelog
<cpaelzer> xnox: but we didn't get a login either back then - I just referred to the bux as it is simewhat related - clearly not the same one
<cpaelzer> xnox: and I agree, with defaults you always will have the special sclp one
<cpaelzer> xnox: have you ever tried to get a totally sclp free guest - I'm not even sure that is supposed to work
<mapreri> jbicha: from what I see on https://launchpad.net/ubuntu/+source/liferea/+publishinghistory it hasn't been synced in a looooong time; like last time has been gutsy
<cpaelzer> pitti: if you have any extra info what it is really waiting on in the pastebin let me know
<cult-> cjwatson: ubuntu-app-devel@lists.ubuntu.com
<cult-> Your mail to 'Ubuntu-app-devel' with the subject ...  Is being held until the list moderator can review it for approval.
<mapreri> jbicha: (+ I find that web page collecting changelog entries awful to read, I really prefer to see a plain text thing)
<jbicha> mapreri: keeping old (duplicate or obsolete) Ubuntu-specific changelog entries makes the diff more cluttered when looking at new Debian versions
<mapreri> how so?
<mapreri> the changelog is the one thing that merge-o-matic manages to merges correctly...
<mapreri> And it's nice to be able who introduced a particular change in debian
<mapreri> err
<mapreri> s/debian/ubuntu/
<cjwatson> cult-: might be better to just say here what the package is
<cult-> Bug report: https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330 Launchpad: https://launchpad.net/ubuntu/+source/libodb/2.4.0-1
<ubottu> Launchpad bug 1588330 in libodb (Ubuntu) "Incompatible builds of libodb and libodb-mysql" [Undecided,Confirmed]
<cult-> Apparently the library doesn't support other architectures than s390x or the GCC dual ABI fiasco is the issue?
<cult-> issue under xenial, but i see s390x only for all above.
<xnox> cult-, libodb was build in wily (old abi) everywhere, and in xenial (new abi; on s390x only)
<xnox> because that's when s390x was added.
<xnox> cult-, rebuilding libodb may be required.
<cult-> but how about amd64 and the others for the new abi? either way libodb and libodb-* connectors are not compatible
<cult-> need rebuild for sure, but when it'll happen?
<jbicha> mapreri: I don't use merge-o-matic for diffs, I usually do it manually but sometimes I'll use the patches.ubuntu.com link on tracker.debian.org
<jbicha> so the Ubuntu-specific changelog entries are not reliable if a package is ever synced, and if the package is not syncable it can be a very large amount of duplication
<jbicha> I think the important part is that d/changelog lists the remaining Ubuntu diff
<jbicha> if there's an issue or interest in old Ubuntu versions, you'll probably need to pull from Launchpad anyway
<seb128> some people like to keep all the old changelog entries in the changelog when merging
<rbasak> seb128: AIUI, that's the normal case. As a sponsor that's what I expect.
<seb128> rbasak, dunno about "normal", I never understood why people were bothering and personally never did it
<rbasak> I did it because my sponsors told me to :)
<seb128> right, as said I can't explain why I never understood but some people seem attached to it
<rbasak> The problem is that debian/changelog is linear. With Ubuntu being effectively a branch of Debian, merges aren't linear.
<seb128> though if a package get in sync and go back to have a diff those people don't go to dig and merge back the old changelogs
<rbasak> Our git workflow tooling assumes you will do it. I wrote a git-merge-changelogs tool that does the same thing as dpkg-merge-changelogs but using tree-ishs.
<seb128> how do you handle packages that managed to be in sync for some time and diverge again?
<rbasak> Yeah. That's just part of the broken-ness of an enforced-linear changelog.
<seb128> I just consider my merges as a sync with a new delta :p
<seb128> the changelog summarize the delta
<seb128> so all good ;-)
<rbasak> That's fine. But for sponsoring, I will require the merged changelog I think.
<rbasak> It's very difficult for sponsorees otherwise. They never know what to do.
<cjwatson> I find it a bit surprising when people drop the old changelog entries on a merge, but it doesn't really bother me either way.
<rbasak> And it seems to be consensus to do it this way, even if you disagree and I don't object to that particularly.
<seb128> yeah, fair enough
<cjwatson> I agree consistency for sponsored uploaders is good though.
<seb128> it makes the merge a bit more difficult and the diff a bit bigger
<seb128> but as said I don't care much either way either
<rbasak> Tooling FTW. Not an issue with our git workflow  :-)
<seb128> what git workflow?
<seb128> I though the current recommended way to submit changes was debdiffs
<rbasak> Dates back to https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038418.html
<seb128> did we go back to some UDD based on git without me noticing?
<rbasak> https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
<rbasak> nacc and I are working on reintroducing UDD-like stuff with git.
<rbasak> It's working pretty well ATM.
<rbasak> Makes merges much easier.
<seb128> +1 from me
<seb128> I just though we were not there yet
<rbasak> https://code.launchpad.net/~usd-import-team/+git are our imported branches.
<seb128> do we have auto import from all uploads to git now?
<rbasak> For a server-focused subset ATM, while we flush out issues.
<rbasak> But nacc or I are happy to import anything else manually on request.
<seb128> nice
<rbasak> I also have Launchpad queue processing for new and unapproved working in a branch.
<rbasak> For SRU reviews.
<seb128> rbasak, somebody should probably update http://packaging.ubuntu.com/html/udd-intro.html
<rbasak> Yeah, there's plenty of outstanding stuff to sort out still.
<rbasak> It is usable for anyone who's prepared to deal with the shortcomings/lack of documentation. I don't think we're ready for everyone yet.
<seb128> k
<seb128> rbasak, thanks for the info, it's good to read that there is some ongoing work on that, I didn't see any recent activity on ubuntu-devel@ or IRC that hinted that was the case so it's a nice surprise ;-)
<xnox> cpaelzer, i wonder if the kvm virtual machines should have network interfaces mac address named or not by default.
<cpaelzer> xnox: s390 network devices you mean?
<cpaelzer> xnox: I prefer to have virtual naming the same as HW does - so based on the subchannel id
<xnox> cpaelzer, no, any virtio net devices. e.g. currently they end up as eth0, but imho emx5254003c4ea3 is better (mac address 52:54:00:3c:4e:a3)
<cpaelzer> xnox: I havent checked in a while what the naming atm actually is
<cpaelzer> I'd expect enps# things
<xnox> not in qemu-kvm vms it seems
<cpaelzer> xnox: ens3, enp0s0, ... those are the ones I found
<xnox> huh
<cpaelzer> the first on my local x86 and the second on ppc
<cpaelzer> just checking on the guests I have open atm
<cpaelzer> xnox: I agree that on s390 we have the old style naming of ethX
<cpaelzer> xnox: I'd personally prefer encXXXX to match the host there
<cpaelzer> just as we do on other architectures
<xnox> cpaelzer, can we do encXXXX for virtio though?
<cpaelzer> yes
<cpaelzer> virtio effectively is a special subchannel
<cpaelzer> type
<xnox> why is not happening though?
<cpaelzer> they all have IDs and new definitions of contril units for (virtio)
<cpaelzer> xnox: I must admit I don't know why it isn't done yet
<cpaelzer> xnox: maybe the enXXXX rule only applies to OSA?
<cpaelzer> but should in a virt env to virtio-net as well on s390
<xnox> indeed it is ens3 on x86_64
<xnox> let me check what's going on in qemu case, and why it's not enc =(
<cpaelzer> xnox: http://paste.ubuntu.com/23954180/
<cpaelzer> xnox: one of them is the net devices, I can't remember which of the numbers withotu checking
<xnox> cpaelzer, yeah i digged into /sys/devices/css0/0.0.0002/0.0.0001 ends up being the virtio device.
<cult-> xnox: cjwatson: fedora had the same issue with libodb, they rebuilt it and all is fine.
<xnox> cult-, i will rebuild it all, and SRU as well.
<xnox> in a moment.
 * cult- is excited
<caribou> dosaboy_: niedbalski: doko: barry: Here are the results of th python/gcc perf comparaison : https://goo.gl/0BIsBu
<cult-> xnox: how often launchpad content is updated?
<cult-> is it instant
<xnox> cult-, yes... however SRU takes about 1-3 weeks to complete.
<xnox> there is paperwork, and multiple eyeballs to review everything =)
<cult-> uh
<xnox> cult-, what are you after?
<cult-> i m just bored to always build it bymself
<andyrock> fossfreedom_: ping
<caribou> seb128: who's looking after gtk+3.0 aside from Laney who's apparently not here ?
<caribou> seb128: I'm about to sponsor LP: #1550983 for Y & X
<ubottu> Launchpad bug 1550983 in One Hundred Papercuts "Fails to start with "Couldn't open libGL.so.1" (missing dependency?)" [High,Confirmed] https://launchpad.net/bugs/1550983
<seb128> caribou, Laney is here, what do you mean? (he might be at lunch though)
<caribou> seb128: his status was /away
<seb128> caribou, jbicha is sponsoring uploads sometime and a few other desktopers, including me do as well
<seb128> caribou, but sure, please go ahead and sponsor those changes
<caribou> seb128: no big deal, just want to check before sponsoring the SRU
<seb128> thanks
<caribou> np
<Laney> caribou: I was at lunch - you can't expect to find somebody at their screen all the time :-)
<caribou> Laney: orly ? :-p
<Laney> The normal procedure would be for you to ask your question, and then for me to reply when I get back
<caribou> Laney: I try to avoid asking directly to people when I suspect that other might know (seb in that caseÃ 
<seb128> caribou, you should just ask on the channel ;-)
<seb128> so whoever you ping has the msg and others can also reply
<Laney> anyway
<Laney> thanks for uploading
<cult-> xnox: is the process visible somewhere?
<nacc> seb128: thank you for reminding me, I need to send a follow-up e-mail to ubuntu-devel
<seb128> nacc, hey, yw! ;-)
<seb128> nacc, thanks for the work you put into that
<nacc> seb128: of course! it's all rbasak's idea(s) :) the big thing that is preventing (which is too strong of a word, really) from broad adoption is primarily the LP side of things. It needs some work on the server side; and additionally, we're still fleshing/testing out how to be fully dgit compatible, etc.
<seb128> it probably makes sense to polish a bit more and get feedback from early adopter before recommending it to contributors, but good to know that it's getting there
<nacc> seb128: agreed :)
<xnox> cult-, subscribe to the bug report in question on launchpad, and you will get email notifications when it is progressing as people update the bug report as it goes through the SRU process. you can read about SRU process at http://wiki.ubuntu.com/StableReleaseUpdate
<phunyguy> hey guys... can anyone in here tell me how Ubuntu's kernel modules are so small?  compiling a kernel manually in $another_distro, even with module compression turned on results in modules 3x the filesize of Ubuntu's....  Just curious really.
<phunyguy> I am compiling with the Ubuntu config btw.
<camako> tjaalton, ping
<camako> tjaalton, I am setting up my dev env to make changes for the new platform-mir in Mesa. I was told by RAOF to do 'debcheckout mesa' and use the ubuntu branch. I was expecting the platform-mir to be there but it's not. I have a copy of it, but is there a more authoritative way to get and apply it?
<tjaalton> camako: what does debcheckout do?
<tjaalton> camako: it's a quilt patch
<tjaalton> in debian/patches
<fossfreedom_> andyrock: hi!
<camako> tjaalton, I 'd like to know how we modify the mesa patch, send an MP against it, have it reviewed and merged?
<tjaalton> camako: just send me the new version ;)
<tjaalton> or put it somewhere
<camako> tjaalton, ok where do I get the mesa from?
<camako> I guess 'debcheckout mesa'?
<camako> it checks out a mesa tree
<tjaalton> maybe, does it clone the git repo
<camako> tjaalton, yes
<camako> I see your commits at the tip
<tjaalton> ok, so ubuntu branch
<camako> yep
<camako> tjaalton, so the patch is in the debian/patches directory of the mesa source tree in Zesty?
<tjaalton> yes
<tjaalton> that branch has 13.0.4, i have 17.0.0~rc2 locally
<tjaalton> rc3
<tjaalton> how quickly do you need it in zesty?
<tjaalton> wondering if you should prepare it for 17 instead
<tjaalton> final should arrive this friday
<camako> tjaalton, doesn't have to be that quickly... First Mir 0.26.1 needs to land (expected in the next day or two)... Then I drop my changes on it and test and have it reviewed by you and RAOf, etc
<camako> tjaalton, I don't mind moving it to 17
<tjaalton> ok, let me update the branch
<camako> tjaalton, it'd be good if my Zesty environement can support the dependencies... would like to avoid building newer versions of its dependencies
<tjaalton> done, pull the branch
<camako> tjaalton, last time I use tip of Mesa tree, it depended on a newer version of DRM
<camako> used*
<tjaalton> zesty should have latest libdrm
<camako> ok let me see
<tjaalton> proposed at least
<tjaalton> .75
<camako> tjaalton, ok I have the updated tree
<camako> conveniently platform-mir patch is in there :-)
<tjaalton> of course :)
<camako> tjaalton, I have my own way of building the mesa treee, but perhaps there is an easier way to apply the (set of) patch(es) and build it in one go?
<tjaalton> haven't used quilt before?
<camako> no I haven't
<camako> and I see that this tree is different
<tjaalton> just apply it directly, do your changes and send me the git diff
<camako> tjaalton, ok
<tjaalton> or better yet, git commit and format-patch -1
<camako> sure
<tjaalton> i need to run
<camako> tjaalton, thanks for the clarifications... goon night
<camako> good*
<robert_ancell> slangasek, I noticed you are assigned to follow up on the snapd-glib SRU exception request. Is there anything I need to do for this?
<acheronuk> juliank: hi. is that apt fix for hashsum mismatches on those icon tars likely to backported to xenial in any future update?
<juliank> acheronuk: yes.
<acheronuk> juliank: thnx. are you able to say if that may be soonish?
<juliank> acheronuk: Why do you ask?
<juliank> Are there any files in xenial with the same hashes?
<acheronuk> two reasons. (1) kubuntu may at some want to backport the plasma-discover taht triggers that with it's apt config file. (2) KDE Neon who build on xenial have just hit that bug
<juliank> I see.
<juliank> It will probably take a month or so, though.
<acheronuk> (1) is a maybe, possibly never (2) is not really ubuntu's problem, but I have some interest there
<juliank> First I gotta pick them into yakkety
<acheronuk> ok. was just asking for info. not requesting that it's done asap or anything
<acheronuk> thank you :)
<juliank> And there are multiple patches I want to pick, not just that one. A lot has been going on since 1.3.1
<juliank>  date -d "0-12-25" "+%Y-%m-%d" fails on armhf and i386, but works elsewhere?
<juliank> ah, ti's 36 bits large...
#ubuntu-devel 2017-02-09
<nacc> jbicha: are you going to followup on php-imagick failure in debian/ubuntu something about SVG i guess
<jbicha> nacc: it looks like Restriction: needs-recommends was accidentally dropped which is essential for the tests to pass, I'll contact the Debian maintainer
<nacc> jbicha: thanks
<jbicha> I'm curious about what changed in imagemagick recently so I looked at the git repository and there's all these commits where the commit message is just "..."
<jbicha> http://git.imagemagick.org/repos/ImageMagick/commits/ImageMagick-6
<nacc> jbicha: yeah ... upstream IM is terrible :)
<nacc> they use git like a stream of consciousness, often with reverts and fully undocumented sequences of changes as individual commits.
<sarnold> and unrelated changes checked in together
<sarnold> and related changes checked in apart
<mdeslaur> jbicha: you can go blind from looking at that, be careful
<nacc> heh
<jbicha> I started here: http://git.imagemagick.org/repos/ImageMagick/blob/ImageMagick-6/NEWS.txt
<nacc> heh
<mdeslaur> ARGH MY EYES
<sarnold> heh
<jbicha> but that was useless
<jbicha> nacc: anyway, Debian is up to 8:6.9.7.4+dfsg-1 but I've no idea whether 6.9.7.4 is better than 6.9.7.0
<mdeslaur> GIT revision what? http://git.imagemagick.org/repos/ImageMagick/commit/fc0fa2145cc6a4d3f4cf95b80ffcc1498eef4970
<sarnold> doko: ARGH MY EYES
<sarnold> doko: sorry, tab-misire. :(
<Unit193> ...They do git worse than I do.
<nacc> lol
<nacc> jbicha: ah thanks for pointing that out -- let me see if i can get IM to migrate tmrw and then I'll look if it's worth updating. Probably for security team's sake it will be :)
<krytarik> nacc: The newer one of those is supposed to also fix LP bug 1550210, btw.
<ubottu> Launchpad bug 1550210 in imagemagick (Ubuntu) "Desktop file does not open ImageMagick from the menu" [Medium,Triaged] https://launchpad.net/bugs/1550210
<nacc> krytarik: thanks
<rnetocombr> 16.04.2 will be delayed again ? i was scheduling a install party in my school today.
<Unit193> infinity: Hmm.  Did you not see the ping the other day?
<nacc> krytarik: jbicha: fyi, i think if we can get php-imagick migrated, it will let imagemagick through (that's at least one of the blockers)
<rbasak> tjaalton: did you conclude anything wrt. adcli?
<tjaalton> rbasak: feel free to drop it
<tjaalton> or demote to suggests
<tjaalton> that's what I committed to debian git
<fossfreedom_> andyrock: just returning your ping from yesterday
<seb128> fossfreedom, I think he wanted to discuss the gnome-menus patch
<fossfreedom_> seb128: ah - yes - we had a quick conversation last week - andyrock mentioned you were in fosdem - hope you enjoyed that!
<seb128> I did thanks
<andyrock> hey
<andyrock> fossfreedom_: seb128 wanted to know which series you want to target
<fossfreedom_> andyrock: patch is for zesty.  For our 16.04 and 16.10 users we are managing this via PPA
<jbicha> nacc: php-imagick's autopkgtest fails on armhf :(
<xnox> jbicha, kenvandine - could you please explain "* Have libgtk-3-dev depend on libcontent-hub-glib-dev, thanks Ken VanDine!" it makes no sense to me...
<jbicha> xnox: the previous gtk3 update introduced a build-dependency on the content-hub, kenvandine reported that without adding that as a dependency of libgtk-3-dev, gtk3 apps were FTBFS
<xnox> ah
<xnox> ok
<jbicha> gtk3 is stuck in zesty-proposed because content-hub isn't available on s390x and I'm not sure how that's going to be handled
<infinity> Why isn't it?  Haven't we unwound the upstart mess yet?
<xnox> infinity, in progress.
<infinity> (And if not, ffs, why not?)
<jbicha> content-hub > ubuntu-app-launch > upstart
<xnox> tedg_, we need to build src:ubuntu-app-launch sans libupstart. or build gtk+3 sans mir.
<xnox> tedg_, but i think having compile time conditionals "without upstart" is overdue for ubuntu-app-launch now.
<infinity> xnox: The first half please.
<infinity> On all arches.
<infinity> I thought you were like two steps from removing upstart at the sprint. :P
<infinity> Two very large steps, I guess.
<xnox> infinity, we got closer at fosdem.
<infinity> Speaking of touch things, who do I yell at for libhybris creeping its way onto every desktop?
<infinity> Last I checked, about 0% of our users are on Android.
<cult-> xnox: i added you to the bugreport
<infinity> Aaaaand, today's update wants to pull in a bunch of -dev packages?
<jbicha> infinity: bug 1662608, I think someone just needs to push the qtmir update through bileto
<ubottu> bug 1662608 in qtmir (Ubuntu) "unity8 should not depend on unity8-tests" [Undecided,Triaged] https://launchpad.net/bugs/1662608
<infinity> jbicha: Looks plausible indeed.
<seb128> fossfreedom, andyrock, didn't you say that the new codebase that's going to be used in zesty isn't impacted by that bug though?
<seb128> fossfreedom, andyrock, in any case I'm voting against a hack that's desktop specific, if there is a ref bug in the code that ought to be fixed, not workaround with a getenv hack
<fossfreedom_> seb128: I honestly dont have any other way forward to fix this issue :(
<seb128> fossfreedom, it's a bug, just needs somebody to look at it and fix it
<fossfreedom_> to answer your previous question - zesty is affected in the same way as yakkety and xenial - gnome-menus code base looks to be virtually the same between the three series
<fossfreedom_> seb128: I have no one in my team that can fix this.  I have called out previously to the community for programmers - but no joy
<seb128> fossfreedom, the bug comments state "17.04 Ubuntu Budgie is going to be using v10.2.9 of budgie-desktop and hence will be affected by the issues raised."
<seb128> so I missread
<seb128> fossfreedom, in any case the workaround is wrong so need to keep looking for somebody who wants to fix the issue
<fossfreedom_> andyrock: do you any bandwidth to help please?
<andyrock> i'm pretty busy
<andyrock> and without a bt I can't really see the issue
<fossfreedom_> andyrock: this is an earlier backtrace when I was looking at this with upstream: http://paste.ubuntu.com/23346077/
<fossfreedom_> the problem seem to wander around - memory corruption issues probably http://paste.ubuntu.com/23345306/ and http://paste.ubuntu.com/23345313/
<fossfreedom_> andyrock: I know I am grasping at straws here ... could some-sort of lock be added at the beginning of the function that is only released once the 2 second delay function has finished ... maybe a re-entrant type issue where the function is called repeatedly very quickly?
<andyrock> i don't think that's the problem
<andyrock> but if you can try
<rbasak> cpaelzer: I agree about changing the NEWS section, but I'm not sure how I should fix it since that is now published in Xenial.
<rbasak> I suppose it's the same mess that we get from the changelog like the discussion the other day. By nature of being a derivative, the concept of a linear log no longer works :-/
<cpaelzer> ack
<cpaelzer> I'd keep Xenial as-is and only care for your upload now
<cpaelzer> and there you could add a new NEWS section for the new content and leave the Debian NEWS untouched
<rbasak> But that'll change the previous NEWS entry. I don't know how tooling like apt-listchanges will deal with that.
<cpaelzer> oh, right :-/
<rbasak> And do I even have any new news? The migration already happened on the upgrade to Xenial!
<cpaelzer> But this was only a review/process finding - it is clearly not worth spending more than 15 minutes on it if it gets complex
<rbasak> Yeah. I'm sort of stuck. I don't feel like there's any good answer, so I'll leave it.
<cpaelzer> You can only fix the future, not the past
<rbasak> I did fix the attribution only because I thought it was grossly wrong not to do so.
<cpaelzer> BUT
<cpaelzer> that means you change the section anyway
<rbasak> Yeah
<cpaelzer> then make it an appendix in the section
<cpaelzer> with no lines being removed
<rbasak> That's reasonable.
<rbasak> OK, I'll do that. Thanks!
<cpaelzer> yw
<tedg_> xnox: It is definitely on the TODO list, biggest issue is that half the test suite works against an Upstart mock, so need to move those tests over to the systemd mock. But no every user should be *using* systemd just need to drop old code.
<xnox> can you please rephrase "But no every user should be *using* systemd just need to drop old code." i fail at english =/
<infinity> xnox: He failed at typing.
<infinity> xnox: s/But no/But now/ might clear it up.
<xnox> tedg_, at least building without src:upstart should be possible; and would be nice to start doing on s390x, even without the tests.
<xnox> infinity, ah, thanks.
<xnox> well, if everyone is using systemd code, the upstart tests are pointless no?! =)
<infinity> tedg_: If runtime is upstart free, omg please please please make build-time/tests upstart-free as a priority.  WE'RE SO CLOSE.
<infinity> xnox: The point is that the tests for the project are against an upstart mock.  They're not useless tests, just using an outdated framework.
<xnox> true.
<infinity> xnox: The tests should still exist, but need to be moved to a systemd framework, then we all win.
<tedg_> Yeah, they're testing other things, just need that as a backstop.
<infinity> (I'd like to win soon please)
<tedg_> Obviously the ones that are testing just the Upstart features can go away.
<tedg_> So, honestly, it's not the highest priority right now, but I'm 99.9% sure we'll get it for zesty.
<infinity> tedg_: I know we're super naggy about it, and it's not always been high on your TODO, but we should realistically have dropped upstart last cycle (or even in 16.04, if we could have found the time), doing it this cycle is really really something we need to do so we can move on with life. :P
<tedg_> Yes, I understand. I want to drop it too.
<nacc> jbicha: ok, I can try and reproduce that today and look into it
<nacc> jbicha: the others pass though?
<jbicha> nacc: yes
<nacc> jbicha: sigh, ok
<jbicha> I can just drop debian/gnome-settings-daemon.user-session.upstart now, right?
<gQuigs> jbicha: re:bug 1540461, so I don't need to do a big debdiff of all the changes between 3.22.0 and 3.22.4?
<ubottu> bug 1540461 in evolution-ews (Ubuntu Xenial) "Recurring events not displayed" [Medium,In progress] https://launchpad.net/bugs/1540461
<gQuigs> jbicha: figured it made more sense to talk on IRC, rather than back and forth on the bug
<jbicha> gQuigs: right, all the new changes are likely outside of the debian/ directory
 * gQuigs has only done patches so far, but happy to learn more
<gQuigs> jbicha: do I need to make a new orig tarball for 3.22.4 or something?
<jbicha> gQuigs: I generally use packaging-only bzr branches to do most of my packaging which makes it easy once you figure out how to do it
<gQuigs> jbicha: so then where do the new 3.22.4 bits come from in that?
<jbicha> my workflow is because I learned from the desktop team packaging, this wiki might be a bit confusing
<jbicha> https://wiki.ubuntu.com/DesktopTeam/Bzr
<jbicha> the important part is  mkdir .bzr-builddeb; echo -e '[BUILDDEB]\nmerge = True' > .bzr-builddeb/default.conf
<jbicha> add your debian/ directory and then bzr init; bzr add; bzr commit -m "init"
<nacc> i'm assuming you'd need a new .orig tarball and then a bumped version in d/changelog to know that it's a new upstream
<jbicha> to look at the source code, you can use bzr bd-do
<nacc> (the .orig tarball would be necessary to, e.g., build a new source pacakge anyways)
<jbicha> and to build you use bzr bd --builder="sbuild -d zesty" or whatever you use to build
<jbicha> for gnome-ish packages, bzr should fetch the original tarball once you use bzr bd or bd-do based on whatever version you have set in the top debian/changelog entry
<nacc> jbicha: ah that makes sense
<jbicha> the setup is confusing but once you figure that out, it is fairly convenient
<jbicha> git-buildpackage works for git stuff but it offers more flexibility and room for complexity
<gQuigs> jbicha: thanks!
<gQuigs> yea, git-buildpackage is what I have a bit more exp. with.. but msotly doing things manually
<gQuigs> where does the orig tarball actually go after this process?  or does something in the archive know to download it in the same way?
<jbicha> with gbp, you have to get the original tarball (maybe something like uscan -dd ?) then gbp import-orig (assuming you're using full source git and not just packaging only)
<nacc> jbicha: yeah, i usually use uscan & uupdate
<jbicha> when you upload to Debian/Ubuntu, you need to upload the original tarball unless that tarball already exists in the archive from a previous build
<nacc> gQuigs: at least in my process, you end up passing -sa to dpkg-buildpackage when you buid the source package and that means it will include the orig. Note that the only caution here is we want the same orig everywhere for that upstream
<jbicha> (in other words, you're doing like a -0ubuntu2 instead of a -0ubuntu1)
<gQuigs> k, thanks both!  will see if I can get it built in a PPA
<nacc> gQuigs: feel free to ask more questions here, of course
<seb128> fossfreedom, having a valgrind log (with ddebs installed) would probably be more useful than a bt for a refcounting issue
<nacc> jbicha: hrm, i think something got messed up in these php-imagick uploads
<nacc> jbicha: the *reason* our d/t/control looked different was that we patched php-imagick to be single-threaded
<nacc> jbicha: i believe that was lost in the sync of 3.4.3~rc2-1-build1, which should have been a merge, afaict
<nacc> jbicha: that was needed because of segfaults in the testsuite (iirc)
<fossfreedom_> seb128: I've tried running under valgrind - the problem doesnt occur.  Weird ... it must be a timing issue.
<nacc> jbicha: i'm not 100% sure it would fix armhf, but it's not mentioned in that upload
<jbicha> nacc: yes, I saw there were 2 changes that were dropped, I decided to try just the needs-recommends change first, do you want to do the upload now?
<nacc> jbicha: let me see if i can get on a porter box and test it first
<nacc> jbicha: but yeah, i'll handle it today
<nacc> jbicha: just wanted to sync with you first
<phunyguy> hey guys... can anyone in here tell me how Ubuntu's kernel modules are so small?  compiling a kernel manually in $another_distro, even with module compression turned on results in modules 3x the filesize of Ubuntu's....  Just curious really.
<nacc> jbicha: my suspicion is that will fix it, though, given that 3.4.3~rc1-4ubuntu4 passed on armhf, but all the 3.4.3~rc2-1* have failed
<ChrisTownsend> seb128: Hey!  Would you have any time to look over the binNEW introduced in https://bileto.ubuntu.com/#/ticket/2452 ?
<Laney> jbicha and nacc: The autopkgtest lxd runner is good enough for testing this even on amd64, btw
<dannf> cyphermox, cjwatson : i was looking to sync the last grub2 debian upload to zesty today, let me know if you have any changes to add in there
<cjwatson> dannf: do you mean merge?  there are two changes in the Ubuntu history not yet in Debian
<dannf> cjwatson: yes, sorry - merge
<cjwatson> fine by me
<nacc> jbicha: cross-arch testing?
<cyphermox> dannf: go ahead
<dannf> cyphermox, cjwatson: cool, thx
<rbasak> cpaelzer: how about http://paste.ubuntu.com/23961330/ as the debian/NEWS.debian change in my squid3 merge?
<Laney> nacc: you meant to hilight me?
<Laney> If so - no, just amd64 on amd64
<nacc> Laney: was just in response, was debugging an armhf failure only
<Laney> I know
<Laney> But you can make the same one happen in that way
<Laney> On amd64.
<nacc> I can? autopkgtest is passing on amd64?
<Laney> Use the lxd runner
<nacc> Laney: no, i understand, but it's not failing on amd64
<Laney> It is if you use that runner
<Laney> Production doesn't use it, so you don't see it there
<Laney> Does for armhf though
<nacc> Laney: oh i see, then yes, this isthe same bug i know the fix for, probably :)
<nacc> Laney: thanks, will verify it locally then on amd64
<Laney> nacc: good, just wanted to share a way to test the fix easily, hope it works!
<rbasak> cpaelzer: complete diff against what you previously reviewed: http://paste.ubuntu.com/23961353/
<nacc> Laney: thanks, sorry for my density
<seb128> fossfreedom_, often segfault stop happening under valgrind but it doesn't mean the error isn't in the log
<seb128> fossfreedom_, get a log anyway, there is a good chance it has the info you need even if it didn't segfault
<seb128> ChrisTownsend, sorry but the changelog doesn't explain enough the diff for me to ack it, like the gobject bindings got removed but without mention nor "why"
<ChrisTownsend> seb128: Ok.  It was removed because it is deprecated and nothing used it.
<seb128> ChrisTownsend, same about why was python3-apt removed from the depends
<seb128> ChrisTownsend, it's good taste to summarize the changes in the changelog for futur uploads
<ChrisTownsend> seb128: The python3-apt depends is not removed, just moved to the libertined package.
<ChrisTownsend> seb128: Ok, will do that next time when deprecating a package.  I can add it now if you'd like since this is still in lander testing.
<Laney> mapreri: seems like the skip_unless_module_exists thing in diffoscope is busted
<seb128> ChrisTownsend, not sure it's worth making you go through another silo round and restarting testing, looks fine but please next time explain the packaging changes in the changelog so we know if they are errors or wanted
<ChrisTownsend> seb128: Ok, will do and thanks for the feedback.
<seb128> ChrisTownsend, yw!
<Laney> mapreri: oho, I see #854670
<gQuigs> jbicha: lol, I've been mostly playing with the tools.. and missed the basics..
<gQuigs> jbicha: Requested 'evolution-data-server-1.2 >= 3.22.4' but version of evolution-data-server is 3.22.3,  it would need a bump of the data-server for me to bring in .4 of ews
<gQuigs> could just likely go for ews 3.22.3
<jbicha> yes, that's fine
<fossfreedom_> seb128: will rerun under valgrind and grab a log.  thanks.
<seb128> fossfreedom_, thanks
<ChrisTownsend> seb128: Oh, one other thing...a couple of libertine related packages in universe will need to be promoted to main when this landing hits -proposed.  The libertine source package is already in main, so do I just create a bug at that time asking for those binary packages to be promoted?
<seb128> ChrisTownsend, no, binaries are semi-automatically handled, they are going to show on the component mismatch report and an archive admin needs to promote them then
<ChrisTownsend> seb128: Ok, thanks
<mapreri> Laney: yeah, I already reported a bug in Debian
<mapreri> .. which you found few minutes after the first msg :)
<mapreri> I have a feeling lamby is not running autopkgtest before uploading, or something :(
<nacc> Laney: thanks again for the guidance (and patience) -- I forget that nuance about the autotpkgtest runners. Reproduced the failure locally and testing the fix now.
<Laney> nacc: Nice
<Laney> mapreri: enjoy a patch
<mapreri> Laney: thank you!  (I'm in exam season, so I'm not doing much of Debian work these weeks)
<mapreri> Laney: btw, "BTW, maybe it would be nice if the 'debian' tests were run in autopkgtest; add a test-dep on python3-debian?" - they are run, on the other test; the failing autopkgtest is the run without any optioanl package installed to test fallbacks, etc.
<mapreri> see d/tests/control
<Laney> oh ok
<Laney> that makes sense, thanks
<nacc> jbicha: verified, tests pass again now -- probably should send this to Debian? (both bits of delta)
<mapreri> Laney: that's weird btw:
<mapreri> In [12]: importlib.util.find_spec('this module is not there') is None
<mapreri> Out[12]: True
<mapreri> it doesn't rise any exception, as documented
<Laney> mapreri: try foo.bar
<mapreri> oh, right "If name is for a submodule (contains a dot), the parent module is automatically imported."   ....
<mapreri> pity
<Laney> you could probably split or something
<mapreri> but then your patch makes the function wrong for modules without dot
<mapreri> yeah, I got the problem now
<Laney> did you see the second version?
<Laney> oh, I typed my passphrase wrong :|
<mapreri> Hence, I haven't :)
<Laney> k, night night
<mapreri> Laney: thanks, that looks nicer indeed :)  I'll leave it there for lamby to pick it up; if he won't by tomorrow, I'll upload it tomorrow evening or so.
<Laney> might want to re-word the commit msg a bit
<Laney> see you!
<nacc> anyone know enough about locales to know if the following is expected? http://paste.ubuntu.com/23962998/
<nacc> it's the root cause for the phpmyadmin build failure in z-p (which is a build-time test failure)
<nacc> it didn't show up in my lxd z-p, because the locale is set to POSIX, so I tried `export LC_ALL=C.UTF-8` and the test failed
<nacc> interesting (to me, because it's confusing), running with LC_ALL=C also produces "This is the Euro symbol 'EUR'"
<nacc> so it's only C.UTF-8 that has issues, which is unfortunately the sbuild default
<nacc> infinity: --^ maybe you'd have a suggestion here (if you're busy, totally fine)
<sarnold> heh, pasting that command line into a bash with en_US.UTF-8 works fine; start LANG=POSIX bash and the paste is all screwed up
<nacc> yeah, the C&P might be funky as it tends to do something wonky with the multibyte characters
<nacc> sarnold: agreed, though en_US.UTF-8 also does work
<sarnold> I sort of expected the terminal's environment to control it thuogh, not some random child process of the shell in the terminal, heh
<sarnold> I -still- don't know how these things work. sobering though.
<sarnold> s/though/thought/
<cyphermox> dannf: don't forget grub2-signed :)
<dannf> cyphermox: ack, in progress :) thanks for the reminder!
<cyphermox> (if you don't have the time, then I'll do it)
<nacc> sarnold: at first, i thought maybe it was because ISO-8859-1 technically doesn't have the euro symbol, but ISO-8859-15 does. And in fact, specifying -15 with LC_ALL=C.UTF-8 does work (although it does not translit it, as I guess iconv successfully converted it)
<nacc> and it was added (I think) in -9, which again works (and translits) with en_US.UTF-8, but not C.UTF-8
<casa> hi everyone I'm using Lubuntu I want to meet a OS programmer (not only Unix and Linux), I want to collaborate with programmer for make original sounds, I compose and produce somethings for opensource programs, but I want to know a programmer for OS...maybe here there aren't OS programmer?!? btw I really love Lubuntu and I'm trying to install to every friend I have xD it is difficult but slowly everyone will use Lubuntu or
<casa> Ubuntu OS, I hope I find someone interested in this way..for music and original sound design, I'm always here...my email is jacopotore@gmail.com  , on skype: jacopotore  , hope to find someone...really love Art and Computer <3
<nacc> mdeslaur: fyi, sorry for the delay, uploading 7.0.15 for SRU now
<mdeslaur> nacc: np, thanks! :)
#ubuntu-devel 2017-02-10
<cpaelzer> good morning
<Unit193> Howdy.
<rbasak> mysql++ fails due to -fPIE, according to Skuggen, and this comes from dpkg-buildflags. Is there documentation around this?
<rbasak> I know about https://wiki.ubuntu.com/Security/Features#pie, but that suggests a whitelist only.
<rbasak> <Skuggen>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie fixes it
<rbasak> So what's our rationale, and how should we approach this?
<rbasak> In a Zesty container, "dpkg-buildflags" doesn't give me -fPIE. Is this a mismatch against the whitelist?
<Skuggen> I haven't tracked exactly where it comes from (but it's from /usr/share/dpkg/buildflags.mk and the package's own libtools file)
<tsdgeos> seb128: ping re https://code.launchpad.net/~aacid/geonames/more_liberal_city_search/+merge/316102
<seb128> tsdgeos, oh right, going to try to do that today, thanks for the reminder
<jbicha> nacc: I forwarded the php-imagick changes to Debian, I see imagemagick is still stuck because of emacs :(
<infinity> rbasak: PIE has been on by default (in the compiler itself, not in buildflags) for a couple of releases now.
<infinity> rbasak: That wiki page is hopelessly out of date.
<infinity> rbasak: Oh, except it's not.  See the end of the bit you referenced:
<infinity> rbasak: "PIE on 64-bit architectures do not have the same penalties, and will eventually be made the default (as of 16.10, it is the default on amd64, ppc64el and s390x)."
<Unit193> Could always do something like parole does, export DEB_LDFLAGS_MAINT_STRIP=-Wl,-Bsymbolic-functions  though changing it to suit.
<rbasak> infinity: ah. Thanks.
<rbasak> infinity: I'm not sure how to resolve this though. Mind glancing at http://paste.ubuntu.com/23965945/ please?
<rbasak> Skuggen reports that a main function is declared, which seems odd for a shared library.
<jbicha> there's some pie weirdness I think is related to Ubuntu having an older dpkg than Debian
 * rbasak wonders if that's a "don't export a main symbol then".
<rbasak> cpaelzer: are you planning to glance again at my squid3 merge, or should I just upload it?
<cpaelzer> rbasak: the findings I had were all of a kind that I don't tihnk I need to re-evaluate
<cpaelzer> I read the diff now
<cpaelzer> thanks for adding
<rbasak> cpaelzer: OK thanks! I'll upload.
<cpaelzer> rbasak: read and acked on th MP now
<rbasak> cpaelzer: I forgot to mention, nis import complete. I guess you knew that :)
 * rbasak just found that window
<mardy> Mirv: hi! :-) https://github.com/tjyrinki/qt58/issues/1
<mardy> first! :-p
<cpaelzer> rbasak: thanks, yes I see it in proposed atm
<rbasak> cpaelzer: does grep-merges work for you? If not, fancy fixing it for more of that core dev experience? :-) I have a patch, just needs landing :-)
<rbasak> http://paste.ubuntu.com/23966354/
<cpaelzer> I nack that on this special Friday
<rbasak> OK :)
<fossfreedom_> andyrock: I've got a valgrind trace (attached to the bug report) for the gnome-menus issue.  I think it is saying that there is a weak-pointer deallocation issue - any chance you can have a quick squint at the log please? https://launchpadlibrarian.net/305825578/valgrind.log bottom of the trace
<andyrock> sure
<andyrock> not at home right now
<andyrock> but will be soon
<fossfreedom_> many thanks
<Mirv> mardy: yes, replied there :)
<mardy> Mirv: any reason why that qmake plugin is not the default one?
<Mirv> mardy: well the qmake plugin is required to find the dev sources when building the app itself. the autotools plugin override is then for the actual Qt configure.
<Mirv> so, overriding things
<sil2100> rbasak: hey! I have a question regarding SRUs to -backports - I see in yakkety a new pbuilder targetting yakkety-backports, is that bypassing proposed then and going straight to -backports?
<sil2100> rbasak: I must say I have no experience with -backports so I don't know the rules regarding those
<rbasak> sil2100: AFAIK, that's not a job for ~ubuntu-sru, so you can ignore it.
<rbasak> There's a separate backporters team.
<sil2100> Oh!
<sil2100> Ok
<sil2100> Thanks
<Laney> does anyone know anything about the emacs25 ftbfs on arm64/zesty?
<rbasak> So grep-merges appears completely broken. I filed bug 1663601. I would just upload a fix, but I can't upload to ubuntu-dev-tools in Debian and the package is in sync.
<ubottu> bug 1663601 in ubuntu-dev-tools (Ubuntu) ""grep-merges" fails with "TypeError: sequence item 0: expected string, NoneType found"" [Medium,Triaged] https://launchpad.net/bugs/1663601
<rbasak> tumbleweed: ^ or should I just throw in a delta?
<cult-> xnox: how's the process going on with the ubuntu releases of the bugfix?
<xnox> cult-, all status is up to date on launchpad.... all done in zesty. haven't looked at stable releases yet, busy with 16.04.2.
<cult-> is it going to be included in 16.04.2 the fix i mean?
<cult-> xnox: no worries,i'm waiting for the launchpad notifications everyday :)
<xnox> cult-, did you not get a tonne of updates yesterday? are you subscribed to the bug report?
<cult-> xnox: i got all of them, i am just waiting for it to be done in 16.04 hence i was asking if its included in 16.04.2 ?
<xnox> cult-, there is no such thing as 16.04.2.... point release is install media only.
<cult-> ah, ok
<xnox> cult-, the update to that package, when it happens, will land in xenial-updates, which is were all the updates land for all of xenial, for all of its lifetime.
<xnox> 16.04.2 install media, is important as it comes with newer kernel; such that one can boot the installer media on newer hardware. Otherwise, installed systems look the same for the updates point of view.
<cult-> ok, but when you done the changes, what other things have to be done?
<cult-> i choosed ubuntu because it has the correct balance between stability(LTS releases) and repository updates. fedora's lifecycle is too short, redhat repos are ancient.
<andyrock> https://www.irccloud.com/pastebin/asXsO3un/
<andyrock> so try to add the g_object_remove_weak_pointer line
<cult-> but unfortunately the library software in question is completely unusable
<andyrock> can you test this?
<andyrock> fossfreedom_:
<andyrock> ^^^
<fossfreedom_> andyrock: yes - will do.  Thanks.
<andyrock> let me know
<fossfreedom_> andyrock: I was just now wandering through gobject documentation about weak-pointers - https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#GWeakRef  was wandering if this was a threading issue.  But yeah - force unallocation is the right was to go.
<andyrock> i don't think it's a threading issue
<fossfreedom_> * wandering wondering
<andyrock> let's test this otherwise will make it thread safe too
<andyrock> the problem is that when menu_monitor->monitor is freed
<andyrock> the weak ptr system will try to nullify a ptr that is no longer valid
<andyrock> because already freed
<seb128> fossfreedom_, see, valgrind gave you the error :-)
<fossfreedom_> seb128: :)  cross-fingers
<seb128> fossfreedom_, well, not saying you have the right fix yet but the log has a clear invalid memory usage error which leads to your segfault
<andyrock> fossfreedom_: any news?
<fossfreedom_> andyrock: ah - should have clarified ... at work for the next couple of hours
<andyrock> np
<andyrock> :D
<nacc> Laney: no, but as it's blocking imagemagick, I can try and reproduce and look around. Googling implies similar errors were reported in 2015, but not a segfault
<Laney> nacc: Ya, I found that
<nacc> sarnold: mdeslaur: to enable http2 on apache2, we'd need to MIR libnghttp2-14 (src:nghttp2). Given where we are in the cycle, would you suggest keeping the extension disabled and focusing on enabling it first thing in 17.10? It's enabled in Debian, and it was disabled in Ubuntu in 16.04 due to its newness & the LTS.
<mdeslaur> nacc: does upstream apache still consider it experimental?
<rbasak> It does seem that way: https://httpd.apache.org/docs/2.4/mod/mod_http2.html
<mdeslaur> if they don't consider it production quality, perhaps we should wait
<mdeslaur> but it would make sense to do it first thing in 17.10
<mdeslaur> in preparation for the next lts
<nacc> mdeslaur: ah ack, thanks! i'll fix up my merge in -proposed
<nacc> mdeslaur: and i'll make a note in the bug
<nacc> thank you both!
<nacc> jgrimm_: --^ that should on our z+1 blueprint :)
<infinity> rbasak: PIE for a library is redundant with PIC anyway.  No harm in just disabling the flag.
<jgrimm_> nacc, i'm not sure if we need anything explicit.. we've previously decided to carry delta to disable http2 in apache2 until it becomes non-expirimental
<jgrimm_> nacc, are you suggesting we want to reassess that position and enable it anyway?
<nacc> jgrimm_: in the interest of 17.10 being a precursor to 18.04 (where I think we'd want it available), we want to look at how stable it is in practice at that point
<rbasak> infinity: OK. Thanks!
<rbasak> Skuggen: ^ up a bit
<jgrimm_> nacc, sure. general task to just check where things are at
<nacc> jgrimm_: yeah
<jgrimm_> nacc, fwiw i've started using the blueprint whiteboard as place to just capture deferred/next-cycle/as time permits
<jgrimm_> nacc, and added apache http2 there
<nacc> jgrimm_: ah ok, thanks! was going to ask
<jgrimm_> nacc, mentioning in case you ever want to just add things yourself
<jgrimm_> col
<jgrimm_> cool
<mapreri> rbasak: that said, who/where is the backports team?
 * mapreri tries poking one name from https://launchpad.net/~ubuntu-backporters/+members
<rbasak> mapreri: I think that's the team, yeah.
<mapreri> I find the documentation in the wiki extremely confusing, or with many shortcomings.
<sarnold> nacc: thanks for thinking ahead on that one.
<sarnold> nacc: I think mdeslaur's suggestion is the way to go; I surely hope they consider it non-experimental before 17.10, it'd be nice to bake it in an interim release first.
<nacc> sarnold: ack
<nacc> rbasak: heh, I think I found a piece of missing delta in openldap since natty ...
<nacc> rbasak: that implies (I think), the apport hook hasn't been installed for openldap sinc then
<tarpman> oh, really
 * tarpman oops
<nacc> tarpman: yeah ... it got dropped by the 2.4.23-6ubuntu1 merge.
<nacc> sadly, it was only added in 2.4.23-0ubuntu1
<tarpman> ah, before my time. ok, I have an alibi :D
<nacc> :)
<nacc> and it's just been carreid forward semi-automatically ever since as being in the changelog, but not actually being in the package
<nacc> git ftw!
<tarpman> the delta could really use a going-over... is likewise even in ubuntu any more?
<nacc> tarpman: rebasing now, i'll show you the current delta to get your opinion
<nacc> tarpman: http://paste.ubuntu.com/23968631/
<nacc> tarpman: if you'd prefer a git tree, i can push it up for you to look at
<tarpman> nacc: pm
<nacc> ack
<nacc> Laney: I assume you saw dannf's bug? (LP: #1656474)
<ubottu> Launchpad bug 1656474 in emacs25 (Ubuntu) "FTBFS on arm64: make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)" [Undecided,Confirmed] https://launchpad.net/bugs/1656474
<nacc> dannf: had you made any progress on it?
<fossfreedom> andyrock: brilliant news - (with a small alteration) the suggested gnome-menus patch works!  Many thanks for all your help with this.  I have attached a debdiff for the patch to the bug report https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1631745
<ubottu> Launchpad bug 1631745 in gnome-menus "Ubuntu Budgie - panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress]
<andyrock> why the  event_info = g_new0 (MenuMonitorEventInfo, 1);
<andyrock> fossfreedom: ^^^
<fossfreedom> andyrock: hmm - let me rerun the debdiff again - I didnt intentionally make that change.  just a sec
<andyrock> ok so the only change is that you moved the line inside the if
<andyrock> right?
<fossfreedom> yep - exactly that
<andyrock> makes sense
<andyrock> fossfreedom: also the debdiff is ok
<andyrock> is a patch to a patch
<andyrock> so it's fine
<fossfreedom> ah - ok. cheers
<nacc> @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: nacc
<nacc> powersj: i'm assuming in LP: #1663329, you meant the delta was merged into Debian? (before [1])
<ubottu> Launchpad bug 1663329 in nagios-nrpe (Ubuntu) "[Sync Request] Sync nagios-nrpe (3.0.1-3) from Debian unstable (main)" [Medium,Confirmed] https://launchpad.net/bugs/1663329
<Unit193> Oh handy, I just filed a RFS in Ubuntu. \o/
<nacc> Unit193: bug #? I can close that one too
<Unit193> LP 1663754
<ubottu> Launchpad bug 1663754 in deluge (Ubuntu) "Please merge from Debian" [Undecided,New] https://launchpad.net/bugs/1663754
<nacc> Unit193: thanks
<Unit193> Thank you.
<nacc> Unit193: just threw a comment in the bug asking for one small tweak
<Unit193> Ah right, sure.  Notice how it has d/p/ubuntu.series?  I poked the Debian (and Ubuntu) maintainer once about https://anonscm.debian.org/cgit/users/unit193-guest/deluge.git/commit/?id=d65670c15990838b8b1b1447ac99ca5f5194fd23 but sadly didn't get anywhere.
<nacc> Unit193: yeah that seems like it would be cleaner, but it's also a relatively trivial delta to carry
<nacc> Unit193: did the Debian maintainer respond at all?
<Unit193> nacc: It was a memo, so I got notified he read it but nothing more.  And it's small, but so small and simple to fix.  Done on the bug.
<nacc> Unit193: yeah, that's frustrating.
<nacc> Unit193: thanks for the quick turnaround!
<Unit193> nacc: No, thank you!
<nacc> anyone able to see why https://launchpad.net/ubuntu/+source/libapache2-mod-perl2/2.0.10-2ubuntu1 is indicating failure only on some arches, due to missing dependency? Is it a timing thing? https://launchpad.net/ubuntu/+source/apache2/2.4.25-3ubuntu2 indicates it should be available for all architectures, iiuc?
<nacc> if an AA is around, could they approve the new openldap binary for zesty?
<Unit193> nacc: Huh, interesting bit about the sponsor tool not liking that dist, wondered why it was switched to zesty on my last sponsorship, guess that's likely why.
<nacc> Unit193: yeah, it offered to let me manually fix it (it might even have prompted for automatic, I don't recall). It's a small and easy thing, so no big deal.
<ilmaisin> xnox: what's the status of submitting the official sru to #1642966? is there anything that someone without advanced programming skills would be able to help with?
<nacc> as to my apache2 question earlier, i've answered it myself, apparently it's because my openldap version showed up in between and so the pending binaries need to be present for libldap-common to be available
<powersj> nacc: good catch yes I meant Debian, updated the bug
<nacc> powersj: np, figured as much
<nacc> @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:
#ubuntu-devel 2017-02-11
<Unit193> mitya57: Howdy.  So I'll flat out ask.  What's the current method in a GTK desktop to set Qt to not look 2002 (basic theme)?  It's starting to change more than the GTK3 for themes. :/
<mitya57> Unit193, are you on Yakkety or Zesty?
<Unit193> QT_STYLE_OVERRIDE=gtk was the way last cycle, there are indicators the styleplugin is the method but that just changes the application to black.  Another hint was that package plus an ENV var of one of a few choices, but again that either didn't change much or just flat out crashed.  This would be Zesty, I'm asking on behalf of myself and also a bit on Xubuntu's.
<mitya57> Then try installing qt5-style-plugins package, and exporting QT_QPA_PLATFORMTHEME=gtk2
<mitya57> (This will use GTK+ 2 for both style and native dialogs. If you specify QT_STYLE_OVERRIDE=gtk2 then you can get crashes because style will be GTK+ 2 and dialogs will be GTK+ 3.)
<Unit193> mitya57: Right, that's the one that got me the partially black application.
<Unit193> mitya57: That seemed to have been the issue then, having both.
<Unit193> (/etc/X11/Xsession.d/56xubuntu-session sets QT_STYLE_OVERRIDE=gtk)
<Unit193> Thanks.
<mitya57> Unit193, then just replace it with QT_QPA_PLATFORMTHEME=gtk2 and add the qt5-style-plugins dependency to some meta package
<mitya57> That used to be in qtbase, but has been split out into a separate source.
<Unit193> Right, really stinks the env var has changed, but oh well.  I had looked into it (and saw you did commits!) and saw it was split out, seems it's going to go away too..
<ilmaisin> some kind of outage on launchpad?
<ilmaisin> as i get "timeout error" when trying to change tags
<ilmaisin> but however, there: https://bugs.launchpad.net/ubuntu/zesty/+source/cups/+bug/1642966 xnox has submitted ppa patches, they now need a sponsor, right?
<ubottu> Launchpad bug 1642966 in cups (Ubuntu Yakkety) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,Triaged]
<cjwatson> ilmaisin: That happens every so often and goes away within 10 minutes or so.  We're hoping that upgrading from PostgreSQL 9.3 to 9.6 will either fix it or at least make it easier to debug.
#ubuntu-devel 2017-02-12
<wxl> cyphermox: thanks for looking at my konversation sru (LP#1635911). do you think it might be more reasonable to just make the change based solely on the bugfix? i.e. the debdiff would be little more than that and a additional changelog entry. i would have done this to begin with but it seems more like backporting than updating.
<Unit193> sarnold: Not busy and got a sec for PM?
<sarnold> sure
#ubuntu-devel 2018-02-05
<jamespage> cpaelzer: I have a 2.9 snapshot in a PPA
<jamespage> but its failing some tests on arm64 atm
<jamespage> https://launchpad.net/~james-page/+archive/ubuntu/bionic/+packages
<cpaelzer> ok, thanks for the info
<jamespage> first thing I normally do with a new release is re-enable all of the skipped tests and try them out again
<jamespage> anyone around who has some familiarity with debhelper, dpkg, debug symbols and how that works in PPA's which generate and publish them?
<jamespage> I'm endeavouring to backport debhelper >= 11 to xenial for the Ubuntu Cloud Archive, but I'm missing something in the dance between debhelper, pkgbinarymangler and pkg-create-dbgsym
<jamespage> I'm aware there are alot of dpkg changes between xenial and bionic including the one to support Package-Type overrides which debhelper uses at bionic but hoping to avoiding including dpkg in the backport...
<doko> cjwatson: man-db ftbfs on ppc64el
<jamespage> meh no worries - figured it out and have enough of a compat shim for the backport
<infinity> jamespage: Erm.
<infinity> jamespage: Backporting debhelper should revert the ddeb support.
<infinity> jamespage: Any other option will end in tears.
<jamespage> infinity: yeah I'd got that - the piece I'd missed was the change to dh_strip to stop debhelper building the debug packages
<jamespage> "+$dh{ENABLE_DBGSYM} = 0 if not $ENV{'DH_BUILD_DDEBS'};"
<jamespage> was my friend
<jamespage> infinity: I think this - http://paste.ubuntu.com/26524058/ does the trick
<infinity> jamespage: https://launchpad.net/ubuntu/+source/debhelper/10.2.5ubuntu2 was where I swapped methods.
<doko> mwhudson: golang-1.10 ftbfs on armhf
<infinity> jamespage: Yep, that looks like it should do it.
<jamespage> infinity: I'd generally got a bit confused as to which parts pkg-create-dbgsym, debhelper and pkgbinarymangler did
<jamespage> them diverts ...
<jamespage> anyway I now know (at least I think I do)
<infinity> jamespage: The pkgbinarymangler dpkg-deb divert is not one of my prouder moments.  Don't look at that postinst if you value your sanity.
<jamespage> lol
 * jamespage shuts his eyes and just holds on for a bit
<infinity> jamespage: (The part where there's a brief period on every single buildd build where dpkg-deb doesn't exist, in the middle of unpacking, is... Fun)
<jamespage> infinity: I also enjoyed the bit where pkgbinarymangler copies in part of debhelper as part of its build
<jamespage> coreycb: I think I have it nailed now - just working the updates into queens-staging to unbreak all the broken builds from friday...
<cjwatson> doko: already dealt with in Debian; it'll auto-sync
<coreycb> jamespage: great thanks. so will the ppa still be able to generate ddebs?
<jamespage> coreycb: yes
<coreycb> jamespage: ok cool
<GunnarHj> chrisccoulson: Have you seen that adobe-flashplugin is stuck in -proposed?
<GunnarHj> https://community.ubuntu.com/t/flash-version-in-xenial-partner-archive-canonical-com/3865
<ackk> cjwatson, hi, I have a refreshed patch for py-macaroon-bakery 1.1.0: https://pastebin.canonical.com/209182/ I can build the updated package with it. would it be possible for you to update it?
<mitya57> cyphermox, doko: do you have any status update on bug 1636666? can you please reply to my comment there?
<ubottu> bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,New] https://launchpad.net/bugs/1636666
<ackk> cjwatson, or, https://paste.ubuntu.com/26525107/
<cjwatson> ackk: Yeah, I guess I can just go with that, just a minute
<doko> mitya57: can it be built using pcre3?
<mitya57> No :(
<doko> and how much in main can be built using pcre2?
<cjwatson> ackk: (I had half of that but was missing the other half, it seems, not sure why)
<mitya57> http://doc.qt.io/qt-5/whatsnew59.html â âQRegularExpression now requires the PCRE2 library version 10.20, or later. Support for the PCRE1 library was dropped.â
<doko> so how much can we rebuild? http://people.canonical.com/~ubuntu-archive/transitions/html/pcre2.html
<mitya57> There is some estimate in https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1636666/comments/20
<ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,New]
<mitya57> That is at least half of the packages from that tracker
<doko> who is working on that to build packages with pcre2 if they can?
<mitya57> I can try to help with that, maybe jbicha and/or LocutusO- would be able to help too.
<mitya57> apache2 may be a problem though: https://bz.apache.org/bugzilla/show_bug.cgi?id=57471
<ubottu> bz.apache.org bug 57471 in Build "Apache 2.4.10 Compilation fails when compiling against pcre2-10.00" [Enhancement,New]
<cjwatson> ackk: Yep, thanks, that works, will upload
<ackk> cjwatson, thank you
<cjwatson> done
<mitya57> doko: I meant at least half of packages from *this* tracker: http://people.canonical.com/~ubuntu-archive/transitions/html/pcre2-main.html (your link includes also universe)
<doko> ahh, I see
<ackk> cjwatson, awesome, thanks
<mitya57> exim4 may be a problem too: https://bugs.exim.org/show_bug.cgi?id=1878
<ubottu> bugs.exim.org bug 1878 in Unfiled "add support for pcre2" [Wishlist,New]
<mitya57> I guess I should collect some bug links and add them to the description
<jbicha> no one is working on getting glib to not use pcre3
<jbicha> on the other hand, tilix and gnome-builder have missing features because Ubuntu's vte2.91 isn't allowed to use pcre2 yet
<doko> php7.2 is missing in this tracker
<doko> silly gnome
<jbicha> the main tracker is manually compiled so you're welcome to add php7.2 if you like :)
<mitya57> So we have two solutions here: 1) Have both pcre3 and pcre2 in main, with a goal of removing pcre3 in later release, 2) Have only pcre3, Qt using its own copy and GNOME missing some features
<chrisccoulson> GunnarHj, ah, crap. Thanks for that. sil2100, can you take care of that please? (I think you approved the upload originally)
<chrisccoulson> sil2100, if you can't see the scrollback:
<chrisccoulson> <GunnarHj> chrisccoulson: Have you seen that adobe-flashplugin is stuck in -proposed?
<chrisccoulson> <GunnarHj> https://community.ubuntu.com/t/flash-version-in-xenial-partner-archive-canonical-com/3865
<mitya57> Looks like php7.2 supports only pcre3 and php7.3 only supports pcre2
<jbicha> Qt is in main because of qtubuntu (kiosk project) and mozc (Japanese input method)
<mitya57> And php7.3 is not going to be released any time soonâ¦
<sil2100> chrisccoulson: hey, for this I think you'll need slangasek
<doko> jbicha, mitya57: I would like to avoid a situation where we have both in main, and everybody is comfortable with it
<mitya57> I understand, but the goal porting everything to pcre2 does not seem achievable in one release cycle
<jbicha> the current vte2.91 situation isn't comfortable :/
<mitya57> Even if we keep pcre2 in universe for this cycle, next time php7.3 will be released and we'll get in the same situation
<doko> so do the promotion after the bionic release?
<mitya57> I won't mind that, but we will technically have pcre2 in main as part of Qt anyway
<doko> or get some buy-in from the tech board and the security team
<mitya57> doko: I just added lists of good/bad packages to the description of bug 1636666
<ubottu> bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,New] https://launchpad.net/bugs/1636666
<mitya57> (It is worse than I thought, most of packages don't even have upstream bugs filed for pcre2 move)
<chrisccoulson> sil2100, you should be able to do it (https://wiki.ubuntu.com/ArchiveAdministration#Handling_updates_to_partner)
<bdmurray> Why does rmadison still show zesty information?
<cjwatson> bdmurray: needs manual editing of snakefruit:~ubuntu-archive/.madison-lite/config.  Fixed now
<nacc> (should that be added to the EOL checklist, if not already there?)
<bdmurray> cjwatson: thanks
<slangasek> chrisccoulson: "stuck in proposed" - so you're saying that the adobe-flashplugin versions in *-proposed are tested and ready to copy to release?
<chrisccoulson> slangasek, yeah
<doko> mitya57: thanks! so I'm still not sure if it's better to delay that promotion until after bionic
<bdmurray> nacc: Its not there https://wiki.ubuntu.com/EndOfLifeProcess
<nacc> bdmurray: ack; i feel like that's probably the release team's page to edit :)
<bdmurray> nacc: whatever, I'm gonna edit it
<slangasek> chrisccoulson: done
<chrisccoulson> slangasek, thanks
<nacc> bdmurray: :)
<cjwatson> bdmurray: process> good call, thanks
<coolfish> hi, approx. on Fri 26. January I asked on #ubuntu-devel, what I can do, to put the package ganeti on a list for 'big' packages for autopkgtest(-VMs). The reason is http://autopkgtest.ubuntu.com/packages/g/ganeti/bionic/amd64. I've verified, that autopkgtest passed with 4GB of RAM. The default of 1536MB is to small.
<coolfish> because I'm no dev (just a user), someone on this channel said, that he has done it for me. Now (2018-02-05 15:13:30 UTC) the test still fails, with the error message: Not enough memory on node node1 for creating instance instance1: needed 1024 MiB, available 810 MiB
<coolfish> so it seems, ganeti is still with default size autopkgtest-VM
<doko> nacc: I removed kopanocore, so zeroc-ice is the only one not building for php7.2. but mumble depends on that one
<acheronuk> nice. lintian in bionic proposed is uninstallable
<acheronuk> https://paste.ubuntu.com/26526608/
<sarnold> ssleay
<sarnold> oy
<nacc> doko: removed as in from the archive?
<nacc> doko: or in which sense? I have fixes for it pending (which I will send to Debian in the bug you filled), but it's segfaulting in my testing (not sure if it's related to PHP yet
<nacc> doko: i'm also workig onn zeroc-ice, which needs to be updated to 3.7.0 at lelast
#ubuntu-devel 2018-02-06
<nacc> doko: fyi, i'm going to try and get phpunit migrated, as i think that's going to let me retrigger a bunch of others easier
<doko> nacc_: yes, removed from the archive for now
<nacc_> doko: ok, thanks
<cpaelzer> wgrant: Laney: do you happen to know if there is some recycling on the builders going on atm?
<cpaelzer> I know officially we are still "limited"
<cpaelzer> but I see all arm boxes either building or in cleanup (since hours)
<cpaelzer> and ppc64el is all disabled except 3 in cleaning
<cpaelzer> so am I right to assume that this is some sort of maintenance going on again?
<wgrant> cpaelzer: Not maintenance, just breakage. Looking.
<cpaelzer> ok
<juliank> jibel: I have no luck reproducing https://launchpad.net/bugs/1744722 in my zesty container, maybe I'm missing something. I managed to reproduce this in my test case, but that's it. The autopkgtests are also screwed up and always test the source package, rather than the installed version. Deleted DistUpgrade/ from source tree now and re-running it
<ubottu> Launchpad bug 1744722 in ubuntu-release-upgrader (Ubuntu Artful) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [Critical,Fix committed]
<juliank> Verified it with some crazy stuff
<juliank> rbalint: We gotta fix the u-r-u autopkgtests to run against the system-installed version rather than the source tree. A simple solution would be to just mv everything somewhere, run the tests and mv back (or just delete the files)
<juliank> terrible. workarounds. required.
<jibel> juliank, i'll do the verification. IIRC you have to update the package cache beforehand
<juliank> jibel: Well, I did verify it now by running the autopkgtest I wrote against the old and new version. But if you want to verify some more, I won't stop you
<seb128> doko, hey, do you know if there is any reason https://bugs.launchpad.net/ubuntu/+source/chrome-gnome-shell/+bug/1695565 isn't getting reviewed (it has been sitting there since june) or if we can do anything to help getting it looked at?
<ubottu> Launchpad bug 1695565 in chrome-gnome-shell (Ubuntu) "[MIR] chrome-gnome-shell" [Undecided,Confirmed]
<rbalint> juliank: yes :-( (re: workarounds)
<seb128> doko, oh, also do you know what's the status of the libblockdev MIR, that's blocking the udisks update which other things are depwaiting on
<caribou> gcc-7
<caribou> oops, sorry
<caribou> and hello btw
 * crogers thinks of suggesting "curvaceous caribou" for 18.10
<Skuggen> cantankerous
 * crogers thinks they need to be positive adjectives to be considered.
<Skuggen> Ah :)
<crogers> Well, doesn't stop people from suggesting "Drowsy Donkey", though.
<crogers> Bionic Beaver is going to get an LTS style extended bit of innuendo treatment.
<GunnarHj> sil2100: How frequent do you plan to build new (delta) langpacks for bionics until final release?
<cpaelzer> since builders had some trouble today
<cpaelzer> and I'm puzzled about an armhf only "Bus error (core dumped)"
<cpaelzer> in https://launchpadlibrarian.net/355994048/buildlog_ubuntu-bionic-armhf.asyncpg_0.13.0-1ubuntu2_BUILDING.txt.gz
<cpaelzer> please tell me that the builders are still sort of broken and this might be a symptom that goes away when rebuilding at a later time
<cpaelzer> wgrant: ^^ ?
<xnox> cpaelzer, that sounds a lot more like unaligned access, which is enforced better on the arm64 kernel.
<xnox> one should not do unaligned memory access.
<cpaelzer> thanks xnox
<cpaelzer> I should be able to run a armhf lxd on arm64 host right?
<xnox> cpaelzer, totally can!
<persia> cpaelzer: You'll want to ensure that you crester the container with the correct personality flags, but it should work for most arm64 processors (there exist exceptions, but not in the more common hardware).
<xnox> cpaelzer, i do all the time, via the MAAS instance
<cpaelzer> xnox: how does MAAS help you with that?
<xnox> cpaelzer, deploying a fresh arm64 box for me to (ab)use =)
<cpaelzer> ok that I have already
<cpaelzer> xnox: persia: any lxd launch command / profiles I could copy ?
<xnox> you shouldn't need anything special. there is launchpad container setup stuff you could do, but i don't think that is necessory a simple $ lxc launch ubuntu-daily:bionic should be enough
<cpaelzer> I might miss the point but where in that do I "make it armhf" ?
<xnox> ah
<xnox> lxc launch ubuntu-daily:bionic/armhf
<xnox> cpaelzer, ^
<xnox> or you can do $ mk-sbuild --arch armhf bionic
<xnox> for sbuild experience.
<cpaelzer> so essentially the same as i386 on amd64 then
<cpaelzer> thanks trying that
<persia> Yep.  Precisely the same as i386 on amd64.
<cpaelzer> didn't want to work that easy http://paste.ubuntu.com/26530622/
<cpaelzer> stgraber: xnox: persia: ^^
<cpaelzer> in case this is one of the exceptions persia listed  "Cavium ThunderX CN88XX"
<persia> cpaelzer: You did hit the "failed to set personality" issue.  I don't know enough about lxd to help debug much, but my past experience with that error message indicated a need for a change to either util-linux or the kernel, to ensure the desired personality worked.  I don't have a comprehensive list of which specific processors support and don't support the armv7l personality.
<cpaelzer> ok - thanks persia
<cpaelzer> I think it needs stgraber ^^ if he is not in a plane atm
<xnox> cpaelzer, odd
<xnox> cpaelzer, mk-sbuild --arch armhf bionic it is, i guess.
<stgraber> cpaelzer: what arm64 host is that?
<stgraber> cpaelzer: not all arm64 machines support armhf
<cpaelzer> Cavium ThunderX CN88XX
<cpaelzer> stgraber: where could/should I check?
<stgraber> hmm, cavium should be fine I believe
<ahasenack> xnox: hi, your btrfs-progs upload to bionic caught my eye
<ahasenack> xnox: because I updated libzstd in bionic, and btrfs-progs got a build-dep on libzstd-dev. But libzstd is in universe
<ahasenack> should zstd be disabled, or were you planing on filing a mir for it?
<persia> xnox: Do I remember correctly that mk-sbuild first tries personality, and falls back to qemu-static if that doesn't work?
<stgraber> root@1ss-arm64:~# uname -m
<stgraber> aarch64
<stgraber> root@1ss-arm64:~# setarch linux32 -- uname -m
<stgraber> armv8l
<stgraber> ^ arm64 that can supports 32bit
<stgraber> root@c2400:~# uname -m
<stgraber> aarch64
<stgraber> root@c2400:~# setarch linux32 -- uname -m
<stgraber> aarch64
<stgraber> ^ arm64 that doesn't
<cpaelzer> stgraber: setarch: failed to set personality to linux32: Invalid argument
<cpaelzer> arm64 that want's to block me :-)
<cpaelzer> sbuild fails to exec through binfmt as well
<stgraber> cpaelzer: ok, so not a LXD issue, but either a hardware one (no 32bit support) or something odd with the kernel
<cpaelzer> yes unfortunately
<xnox> ahasenack, i will be filing MIR, yes, pending.
<ahasenack> oh, ok
<persia> stgraber: Can all arm64 that supoport armv8l also support armv7l?  I never understood if that was just a kernel trap or something in the hardware microarchitecture.
<stgraber> persia: I believe that part to be right, if you get armv8l you can run armv7l, at least that's been the case on all hardware I've seen
<persia> stgraber: It has also been my experience.  Thanks for the confirmation.  Someday I hope I'll understand whether it is true or just always seems true :)
<xnox> tsimonq2, mitya57 - will you please upload qt with openssl1.1 patches?
<tsimonq2> xnox: I have to look again but I thought the patch caused an FTBFSe
<tsimonq2> s/Se/S/
<xnox> tsimonq2, right, we are shipping both openssl1.0 and openssl1.1, so maybe we should only worry about that ftbfs in CC release.
<xnox> tsimonq2, do you have pointers somewhere? maybe I could take a look to fix it up?
<tsimonq2> xnox: Sorry, that was a good couple of weeks ago and I'm on mobile atm
<tsimonq2> I'll take a look a bit later
<xnox> tsimonq2, ack, chat later =)
<mwhudson> there are two instructions that have been removed in armv8 vs armv7 (swp and swpb)
<mwhudson> i assume they are extremely obscure
<sil2100> GunnarHj: hey! So the langpack updates are planned to happen every week, last week they didn't happen because I forgot to re-enable them after creating the base ones
<sil2100> GunnarHj: but this week they should build normally
#ubuntu-devel 2018-02-07
<GunnarHj> sil2100: Ok, thanks for letting me know.
<sil2100> GunnarHj: sorry about this anyway, I noticed it too late and didn't get to running it manually, maybe I should have
<sil2100> Anyway, I just thought we'll get a batch this week
<GunnarHj> sil2100: I thought there was some kind of manual intervention to build the packages, but you say it will happen automatically?
<GunnarHj> sil2100: Or are you talking about the tarballs?
<sil2100> GunnarHj: well, the delta langpacks are happening automatically, a day after tarball exports
<GunnarHj> sil2100: Ah, didn't know that.
<sil2100> GunnarHj: as per the schedule https://dev.launchpad.net/Translations/LanguagePackSchedule
<GunnarHj> sil2100: Right, so there are weekly updates all over (when it works), and while the builds for the stable releases goes to the PPA, the builds for the development release make it directly to the archive.
<nauticalnexus> lmao
<nauticalnexus> tfw openrct2 dev team says you can't build openrct2 for Ubuntu, and package in deb file
<nauticalnexus> tfw u literally JUST DID THAT
<didrocks> xnox: hey, you mentioned some xubuntu ubiquity plugin and such, I don't find them in the ubiquity source nor find other packages matching those descriptions
<doko> rbalint: https://launchpad.net/ubuntu/+source/mtd-utils/1:2.0.1-1ubuntu2 still ftbfs on ppc64el
<rbasak> When switching the one thing in main for a particular thing, what's the expected upgrade path for users usually? Leaving upgrading users with a packaging now in universe and release note it? Or something further?
<rbasak> When switching the one thing in main for a particular thing, what's the expected upgrade path for users usually? Leave upgrading users with a package now in universe and release note it? Or something further?
<xnox> didrocks, sigh, need to search for it again then. maybe it was somebody else, like edubuntu or mythbuntu
<xnox> rbasak, we do leave people with packages in universe typically.
<xnox> rbasak, sometimes we promote the new thing via upgrade-manager quirks, but we stopped doing that, as it is fragile. seeding new stuff into metapackage works fine, as long as there is a clear successor.
<didrocks> xnox: so, I guess there is nothing, I see no plugins at all
<cjwatson> I thought it was an ubuntustudio ubiquity plugin
<cjwatson> didrocks: https://launchpad.net/ubuntustudio-live ?
<cjwatson> https://launchpad.net/ubuntu/+source/ubuntustudio-live too
<didrocks> cjwatson: ah, thanks! the naming isn't the best. I'll check if there is the minimal install in it that xnox elluded to
<xnox> /o\ studio
<xnox> thanks colin!
<didrocks> yeah, it's not a minimal install checkbox, it's a view with checkbox to select/deselect installed packages
<cjwatson> there may be some other plugin that exists that I forgot about
<didrocks> or maybe xnox's memory is failing ;)
<cjwatson> grepping Contents also finds dell-recovery and edubuntu-live
<xnox> didrocks, they do wipe your memory upon leaving Intel...
<didrocks> xnox: ahah :)
<xnox> or so I was told.... I can't remember
<didrocks> thanks for the hints cjwatson :)
<cjwatson> mythbuntu-live-autostart also used to exist
<didrocks> the edubuntu one is unsurprinsgly very close to ubuntustudio (full list of packages to select/remove from)
 * didrocks looks at mythbuntu
<rbasak> xnox: thanks. In this case I don't think it's included in a metapackage (it's from server-supported)
<didrocks> ubiquity/plugins/myth-install-type.py, ah, promising :)
<xnox> rbasak, ah, well, we do drop things on the floor (main->universe) and that is it =)
<rbasak> OK
<xnox> rbasak, upon upgrade with like do-release-upgrade, it does mention that these are now community supported packages.
<rbasak> Good point
<xnox> rbasak, so people can read it, and forget that list of things =)
<didrocks> xnox: ok, I confirm that the list per install type is hardcoded in mythubuntu
<xnox> didrocks, lolz
<xnox> didrocks, slangasek was like "no i have not heard about didrocks adventures" and he was like "chat with him to align" and I'm like "i did", everyone likes everything =)
<xnox> didrocks, but need to do the actual coding with stacked squashfses....
<GunnarHj> cjwatson: Hi Colin! I'm investiging a translation issue for util-linux together with seb128. Translations haven't been imported to LP in a long time (7 years).
<GunnarHj> The latest bionic build log claims that the tarball util-linux_2.30.2-0.1ubuntu1_amd64_translations.tar.gz was created. I'd like to see what it contains. Do you possibly know how to find it?
<didrocks> xnox: yeah, we still need something for the LTS, so let's go with the easy option as a fallback in case you don't get the stacked squashfses work on time
<Unit193> * Ship ubuntu-dgbsym key
<didrocks> xnox: sounds like easy enough, not a lot would be lost
<Unit193> xnox: Thnak you!
<xnox> Unit193, your welcome. it is in a separate package though, just install that =)
<cjwatson> GunnarHj: You should be able to dig it out from the queue.  Let me see ...
<Unit193> Doesn't matter, it exists.  There's a bug that can be closed now too.
<cjwatson> GunnarHj: https://launchpad.net/ubuntu/bionic/+queue?queue_state=3&queue_text=util-linux
<GunnarHj> cjwatson: Thanks!
<seb128> cjwatson, doing something like "ubuntu.getSeries(name_or_version='bionic').getPackageUploads(name='util-linux', version='2.30.2-0.1ubuntu1 ', custom_type='raw-translations')" from a lp-shell used to work but it doesn't seem to do what I expect now ... did that change/stop working?
<cjwatson> seb128: That stray space in the version doesn't look likely to help.
<seb128> shrug, indeed
<seb128> cjwatson, thanks for spotting :)
<seb128> and sorry for the noise
<cjwatson> np
<cjwatson> I expect there's more debugging to do here, but I think the relevant logs have expired at our end by now since the last attempt was a while ago
<xnox> doko, on arm64, gcc: error: unrecognized command line option â-m64â -> i guess one should not use that option, ever, right?
<mdeslaur> cpaelzer: FWIW, virt-manager 1.4.3 ftbfs on bionic
<mdeslaur> cpaelzer: I can give you my debdiff if you feel like investigating
<mdeslaur> cpaelzer: this is what I'm hitting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888133
<ubottu> Debian bug 888133 in libvirt "virt-manager FTBFS: test failures" [Serious,Open]
<cpaelzer> mdeslaur: I was just starting a merge a few minutes ago
<cpaelzer> mdeslaur: did you already start one?
<mdeslaur> cpaelzer: yes, then hit all the test failures in the debian bug
<mdeslaur> one sec
<mdeslaur> let me retry building it to see if anything changed
<cpaelzer> mdeslaur: guido marked it as found in libvirt 4.0 - so likely a change in behavior in there
<cpaelzer> mdeslaur: I might abandon my just started merge and better help you to get over that FTBFS
<mdeslaur> yeah, that's what I suspected...I looked through the virt-manager tree to see if there seemed to be any commits to address that, but I had not found any
<mdeslaur> perhaps it's worthwhile to try 1.5
<mdeslaur> ok, still get the test failures...let me stick my source package somewhere for you
<cpaelzer> mdeslaur: 4224b092 or fe59c337 maybe
<cpaelzer> mdeslaur: FYI I can recreate the issue
 * mdeslaur looks
<mdeslaur> cpaelzer: I had tried 8b4befae602779cbef2d579e4c532b9cd0f1fee9
<mdeslaur> but yeah, perhaps combining them all
<mdeslaur> or just going to 1.5
<cpaelzer> I try that atm
<cpaelzer> rather brute force, just to know if it would work
<cpaelzer> already building ...
<cpaelzer> mdeslaur: 1.5 is failing as well, but differently
<mdeslaur> :(
<cpaelzer> now around "Size must be specified for non existent volume" and ....img' does not exist
<mdeslaur> how silly of me to think that they would test the latest virt-manager on the latest libvirt ;P
<pchamtaczke>  hi ubuntu devs. I need help with launchpadlib. I need to retrive package's dsc information sorted by publish date
<cpaelzer> mdeslaur: all remaining issue son 1.5 have "/tmp/__virtinst_cli_exist1.img" being missing as the issue
<cpaelzer> veen the messages with the size track down to the same thing
<mdeslaur> oh, interesting
<pchamtaczke> repositories are divided by main and contrib. Is there a way to retrive only from one repo?
<cjwatson> Ubuntu doesn't have a "contrib" component; its equivalents are main/restricted/universe/multiverse.  https://launchpad.net/+apidoc/devel.html#archive-getPublishedSources and similar calls can be given a component name to filter results.
<cjwatson> (And I think that should answer your other question too.)
<cpaelzer> mdeslaur: of the cdrom cases only the s390x cases fail
<xnox> cpaelzer, but s390x has no cdrom....
<xnox>  =)
<cpaelzer> well you can pass a virtual one
<mdeslaur> cpaelzer: kill it with fire
<cpaelzer> the others are all with virt-clone
<cpaelzer> not sure yet, but they all seem to have the same "signature" so I hope it is one or two fixes at most
<mdeslaur> cpaelzer: ProTip: I always write xnox's name in the changelog when I break s390x stuff ;)
<cpaelzer> real Pro :-)
<cpaelzer> it is not any s390x specific thing in this case (other than by accident of names)
<mdeslaur> hehehe
<cpaelzer> just the tests that refer to /tmp/__virtinst_cli_exist1.img in their test xml fail
<cpaelzer> I assume the setup of said file fails
<cpaelzer> but it hides from me atm
<cpaelzer> ah there is an exist_images in clitest.py - that looks good
<cpaelzer> mdeslaur: this is a file that the test entry is supposed to prepare
<cpaelzer> mdeslaur: and it does
<cpaelzer> mdeslaur: but as a link to a non existing file
<mdeslaur> hrm
<cpaelzer> mdeslaur: I'll go on debugging and let you know what I find or if I give up
<mdeslaur> ack, thanks
<pchamtaczke> cjwatson: ok i get it. It there a way to get history of package? I mean for example history of gimp package: what version was in 2014, what dependencies, what binaries had?
<pchamtaczke> i see that prints current packages
<cjwatson> pchamtaczke: That call returns publication records, which includes packages that have been superseded or deleted, so it's the basic building block for what you're asking for.
<pchamtaczke> thanks, its nice. This answer is sufficient for me ;)
<cjwatson> pchamtaczke: Though quite a bit of assembly will be required if you're trying to work out properties of binaries, and depending on what you're doing it may be easier to go through archive.getPublishedBinaries.
<cpaelzer> mdeslaur: ok, silly me
<cpaelzer> mdeslaur: that was actually an artifact of my "brute force 1.5"
<cpaelzer> mdeslaur: resolved the issue, well done 1.5 looks good now
<cpaelzer> inside my sbuild chroot
<cpaelzer> mdeslaur: if you'd go to a tarball of 1.5 it should be just good
<mdeslaur> cpaelzer: oh, awesome
<mdeslaur> cpaelzer: are you going to upoad it?
<cpaelzer> I'd need to clean up a lot
<cpaelzer> but yes I think I'll redo the merge you did and add 1.5 on top
<cpaelzer> unless you say it would be easy for you to add 1.5 on top of yours
<cpaelzer> reading your changelog it was just dropping upstrema changes on your rebase
<cpaelzer> I should be able to redo that quickly
<cpaelzer> mdeslaur: I'll set you as additional reviewer when I have something ok ?
<pchamtaczke> cjwatson: i need to build api that retrieve information about binaries from fixed time interval. I need follow properties from binaries: name, version, architecture and publication date. Every property i have from received objects from `getPublishedBinaries`. That intervals will be problematic but i invent something
<mdeslaur> cpaelzer: sure
<cpaelzer> mdeslaur: you dropped use_qxl_for_ubuntu.patch I don't see the upstream change for it
<cpaelzer> other reasons to drop ?
<cpaelzer> oh was this 15.04 only?
<mdeslaur> it was dropped upstream
<cpaelzer> not sure how _is_related_to is evaluated
<cpaelzer> was that  984ba6b33e80f9a91b93677b991fcd7ee4831218
<cpaelzer> yep
<cpaelzer> ok
<mdeslaur> yes
<doko> xnox: yes
<doko> GunnarHj: pkgbinarymangle's tests fail
<GunnarHj> doko: I know. seb128 will look at that.
<seb128> doko, do you have any idea what could be wrong? that doesn't look related to the change so was probably an existing issue in bionic
<cpaelzer> mdeslaur: 1.5 built fine now
<mdeslaur> cpaelzer: awesome
<cpaelzer> mdeslaur: I'll push a review as soon as calls leave me alone
<doko> seb128: sorry, no. just saw the ftbfs
<doko> maybe needs updates for new debhelper?
<seb128> could be, it seems to fail to unpack some source
<seb128> I don't know what changed in debhelper, need to have a look
<seb128> "AssertionError: b"no entry control.tar.gz in archive\n\ngz[179 chars]nd\n" != b'' : b"no entry control.tar.gz in archive\n\ngzip: stdin: unexpected end of file\ntar"
<cpaelzer> mdeslaur: please review https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/337287
<cpaelzer> mdeslaur: there is also a ppa building across arches to test, linked from the MP
<mdeslaur> ugh, how about a debdiff
<mdeslaur> cpaelzer: I'm in the middle of something, I'll pull it down in an hour and take a look
<cpaelzer> mdeslaur: due to timezones you'll have all of your day to do it
<mdeslaur> cool :)
<bdmurray> How does one suspend from gnome on bionic? The power button only offers shutdown.
<nacc> bdmurray: from the dropdown, hold Alt
<nacc> bdmurray: iirc, it toggles from power off to suspend
<nacc> super intuitive :)
<xnox> bdmurray, i wish that was fixed becuase the "just close the lid" does not work on the desktop
<bdmurray> that's crazy
<nacc> bdmurray: did it change to a 'pause' for you?
<bdmurray> nacc: yeah, hence my comment
<nacc> bdmurray: yeah :0
<nacc> bdmurray: there's also a screen rotation thing if you have that, and it's equally unintuitive (does the icon it show mean that's the current state or what it would go to??)
<nacc> it's *almost* like gnome doesn't care about users' sanity
<GunnarHj> seb128: I built pkgbinarymangler successfully on artful (locally). So there is indeed something with the builddep versions.
<jbicha> bdmurray: it's documented at https://help.ubuntu.com/stable/ubuntu-help/shell-exit.html#suspend :(
<bdmurray> jbicha: Do you know if there is a bug report about the issue?
<jbicha> lol
<jbicha> it's a Feature
<xnox> bdmurray, i think i made one.
<jbicha> you'd have to convince either GNOME Designers or the GNOME Shell developers of the behavior you want
<jbicha> or convince the Ubuntu Desktop team that it's worth diverging for
<xnox> bdmurray, i wonder if there is an extension we can ship, and/or some such
<jbicha> one issue with adding an extra Suspend button there is that 5 buttons makes it crowded at the bottom of the menu
<xnox> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1697143
<GunnarHj> bdmurray, jbicha: I got the same question in the Swedish loco, and provided the very same link to the docs.
<ubottu> Launchpad bug 1697143 in gnome-shell (Ubuntu) "GNOME Shell's Suspend feature is hidden in power menu" [Medium,Confirmed]
<nacc> there was a proposal at some point that they shouldl all be togglles
<jbicha> (the 4th button is the auto-rotate button that shows up on certain hardware)
<nacc> or something like that
<xnox> jbicha, 5? which five? I only have three
<nacc> xnox: i have 4
<nacc> xnox: and a suspend would be 5
<nacc> xnox: you only have 4 if you ahve a rotate-able screen
<xnox> nacc, i have system settings, lock, shutdown.
<jbicha> xnox: there's a screenshot of the auto-rotation button on the bug report
<xnox> nacc, that screen rotation button is well.... useless
<nacc> xnox: right
<nacc> xnox: it can be handy to have it disabled, fwiw
<xnox> a suspend one >>> screen rotation
<nacc> as otherwise your screen flickers a lot :)
<xnox> nacc, imho it should be disabled by default, and if you enable it in setting, get the lock rotation button.
<nacc> xnox: yes, that's basically how it works
<nacc> you have to (on my hardware) install iio-sensor-proxy and configure it properly to get rotation
<xnox> nacc, and imho settings button should be "System settings..." a line entry.
<jbicha> nacc: iio-sensor-proxy is installed by default
<nacc> jbicha: ah ok, it wasn't at the time i installed :)
<nacc> xnox: yes, the icons don't make anything clearer to me
<xnox> nacc, ok, when you click power button, it should have "suspend", "hybernate" test buttons options....
 * jbicha points xnox to #gnome-design on irc.gnome.org â¦
<nacc> heh
<xnox> https://extensions.gnome.org/extension/826/suspend-button/
<jbicha> but it's difficult getting change from GNOME Design, both because many of these issues have been presented many times
<jbicha> and because GNOME Design made all their radical changes for 3.0 and now are hesitant to make major changes ;)
<xnox> "or simply long-click the power off button." what the?!
<jbicha> it sort of makes sense except that I can't think of anywhere else in GNOME that uses long-click
<xnox> there is no indication that it is a long-clickble button
<xnox> it could have been a GIF that animates
#ubuntu-devel 2018-02-08
<sil2100> jibel: hey! How's the xenial dailies testing going? How bad is it? ;)
<cpaelzer> hi, I happened to hear that one can retrigger autopkgtests but group packages
<cpaelzer> like retry test on A, but only with this version of B
<cpaelzer> I need just that to resolve bug 1748135 that I just analyzed
<ubottu> bug 1748135 in vagrant-mutate (Ubuntu) "autopkgtests after shutdown of atlas depend on vagrant 2.x" [Undecided,New] https://launchpad.net/bugs/1748135
<cpaelzer> does anybody have link to a howto, scripts, or anything that I can use to learn how that is done?
<cpaelzer> pitti: sorry to bother, but you might know the answer to above ^^
<pitti> cpaelzer: yes, that can be done with specifying a set of "triggers" with appropriate versions; like, test package A with these three versions from -proposed
<pitti> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Test_request_format describes the syntax
<pitti> cpaelzer: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests gives the CLI for run-autopkgtest, but I think this is obsolete (nobody should have access to snakefruit any more)
<pitti> cpaelzer: but if you have a typical retry URL, you can just  append more &trigger=srcpkg/version arguments if you want to run it against more packages from -proposed
<cpaelzer> pitti: thanks, I'd construct one of those and ask you to review if that is ok
<cpaelzer> back in a few minutes
<pitti> sounds good
<cpaelzer> pitti: http://paste.ubuntu.com/26540222/ ok ?
<pitti> cpaelzer: LGTM! (corresponds to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vagrant)
<cpaelzer> thanks pitti!
<cpaelzer> I used an urlencoder actually and not copied from #vagrant, but as long as it works it is fine :-)
<pitti> cpaelzer: I meant I compared the version number
<cpaelzer> yeah I relaized that you did check there how the trigger for vagrant was
<cpaelzer> I just meant I didn't copy from there, but instead used an encoder to get the appendix needed
<cpaelzer> in any case it seems to work, which was the important part :-)
<pitti> ð
<cpaelzer> death by UTF
<pitti> cpaelzer: since these appear in full color and nicely rendered in plain terminals, I just like them even more
<pitti> that started in Fedora 27, supposedly there's a newer font; (haven't tried in Ubuntu yet)
<ginggs> tseliot: do you have an ETA for nvidia-graphics-drivers-390 ?
<tseliot> ginggs: in the next few days, at least in 18.04
<doko> xnox: we will have openssl1.0 for a while now? promote it? and subscribe foundations?
<tseliot> ginggs: it's going to be available in a PPA first, together with glvnd enabled mesa
<ginggs> tseliot: thanks, please don't forget to add libcuda-9.1-1 - needed for cuda 9.1 in debian experimental
<tseliot> ginggs: done
<ginggs> tseliot: ta!
<tseliot> thanks for reminding me ;)
<xnox> doko, yes, foundations should be subscribed; looking at componenets-mismatches, i am confused why only the udeb shows up without the main library.
 * xnox subscribes things
<xnox> doko, foundations bugs subscribed
<doko> jamespage: pysmi and pycryptodome need a MIR (dep of python-snmp4, openstack subscribed)
<jamespage> doko: ta - either coreycb or I will pick that up
<ginggs> tseliot: please ping me when it's in the PPA, I have a machine with two Titan X cards ready for testing!
<jbicha> pitti: color emoji works in Ubuntu 18.04 but not 17.10
<jbicha> it works in Debian GNOME Testing too
<jbicha> pitti : is it possible to push https://launchpad.net/ubuntu/+source/gvfs/1.20.1-1ubuntu3 to Debian?
<doko> xnox: did you find out where the -m64 on arm64 comes from?
<pitti> jbicha: not necessarily; Debian's LXC containers likely don't have sudo installed or configured
<pitti> the test could start out as root, depend on sudo, create a user, and drop privs maybe
<pitti> but this has always been a bit awkward
<jbicha> pitti: for ci.debian.net, it already has "SKIP Test requires machine-level isolation but testbed does not provide that"
<pitti> jbicha: ah, I see; it would still not work when running it with qemu against a bootstrapped VM, but then again maybe the current debian test version also doesn't
<pitti> so if that's the only remaining delta, I guess it doesn't hurt much to  commit that to debian
<jbicha> we have two MIRs we need too, at least the libnfs MIR would be nice to simplify allowing us to sync from Debian
<jbicha> if you have any idea about how the "create a user and drop privs" thing would work, that would be nice
<jbicha> but I guess there aren't many people in Debian running autopkgtests besides ci.debian.net
<pitti> (meeting, TTYL)
<cpaelzer> xnox: the nova autopkgtest is resolved, I kicked the one from the openssl upload again
<tseliot> ginggs: I will, thanks
<xnox> doko, no, not yet, will do.
<doko> xnox: if it was in kamailio, it's now fixed
<xnox> doko, yes, as that is part of ssl1.1 transition, green on all other arches. thanks!
<doko> seb128, didrocks, jbicha: how takes care about DX Packages, or Ubuntu Touch seeded packages these days? jbicha renamed d-conf to dconf, and it needs a new bug subscriber
<doko> who even ...
<seb128> doko, that's a desktop GNOME upstream package
<seb128> nothing to do with dx or touch
<seb128> but good point, we should unsubscribe ourselve from those if we are subscribe to any
<seb128> doko, I subscribed desktop-packages to dconf now, thanks for pointing it out
<doko> ta
<doko> jbicha: gtk-doc still ftbfs
<jbicha> doko: yes, I don't know how to fix gtk-doc
<doko> :-/
<seb128> doko, btw could you give another look to the libblockdev MIR, jbicha addressed your comments and it's blocked the udisks update which is blocking other things
<doko> seb128: ok
<seb128> doko, thanks
<seb128> doko, also any idea if something is not set up right on https://bugs.launchpad.net/ubuntu/+source/chrome-gnome-shell/+bug/1695565 , it has been sitting there since june, I know the MIR team is busy but that looks like it's too long and I wonder if it's not showing up on the review list for some reason?
<ubottu> Launchpad bug 1695565 in chrome-gnome-shell (Ubuntu) "[MIR] chrome-gnome-shell" [Undecided,Confirmed]
<dgadomski> hey seb128, fyi fix for bug #1644662 has been upstreamed, I've attached debdiffs with fixes for xenial-bionic
<ubottu> bug 1644662 in gnome-themes-standard (Ubuntu Bionic) "Icons missing when appearance setting is "high contrast"" [Undecided,New] https://launchpad.net/bugs/1644662
<seb128> dgadomski, yeah, nice, thanks
<seb128> I'm going to try to have a look
<pitti> jbicha: "there aren't many people in Debian running autopkgtests besides ci.d.n"> agreed, so commiting that wouldn't hurt too much
<pitti> and it's a rather nasty hack anyway - the test needs to set up something as root, but wants to run as user, and makes assumptions about sudo working (without password)
<doko> why are the python-gnupg tests hang on the buildds?  succeed locally
<seb128> hum, dpkg/bionic changed in a way that makes pkgbinarymangler tests unhappy
<seb128> ""no entry control.tar.gz in archive" hum
<smoser> ok... i'm trying to come up with the url to a .dsc file for a specific version of a source package.
<smoser> easiest way to get that ?
<rbasak> Go via "Publishing History"?
<rbasak> Or you mean automatically by API?
<smoser> rbasak: well, i was  meaning just through apt
<rbasak> I wonder if apt-get source foo=version works
<rbasak> Another might be to run chdist against /var/lib/apt/lists/something, but that is perhaps not using apt depending on your definition :)
<smoser> well, it would
<smoser> here. i'll describe :)
<rbasak> I'm pretty confident that the chdist would work
<rbasak> Ah
<rbasak> I mean
<rbasak> Uh
<rbasak> chdist?
<rbasak> I mean grep-dctrl
<xevious_> PHP dependencies are currently questionable in Bionic: `php-cli` pulls in PHP 7.1, but `php-xdebug` pulls in PHP 7.1.
<xevious_> hah
<xevious_> oops
<xevious_> Typo, clearly.
<rbasak> A PHP transition is still in progress.
<xevious_> Correction: PHP dependencies are currently questionable in Bionic: `php-cli` pulls in PHP 7.1, but `php-xdebug` pulls in PHP 7.2.
<smoser> grep-dctrl, maybe helpful.
<xevious_> rbasak: Is there a page or mailing list discussion that outlines the transition?
<xevious_> Also, is there anything I can do to help with the transition?
<rbasak> http://people.canonical.com/~ubuntu-archive/transitions/html/php7.2.html lists it as done, but I suspect that's only to -proposed rather than landed in the release pocket.
<rbasak> nacc has been working on the transition, but he's out until Monday now I think.
<rbasak> I wouldn't want to step on his toes.
<xevious_> Of course.
<xevious> Hopefully we can chat about it more on Monday when he's back. If there's any work that can be split up, I'm able to help and can rally at least one more.
<rbasak> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults is how it currently looks.
<rbasak> There are probably other packages caught up in it as well.
<rbasak> xevious: thank you for the offer. Let's see what nacc says on Monday (or feel free to ping him directly here)
<smoser> rbasak: http://paste.ubuntu.com/26542394/
<Pharaoh_Atem> rbasak: the php-libvirt-php import from Debian is crashing on php7.2
<Pharaoh_Atem> which is weird, because in Fedora, my php-libvirt package built just fine with php7.2
<Pharaoh_Atem> rbasak: that is, it's crashing on attempting to build against php7.2
<Pharaoh_Atem> rbasak: has nacc been away for a while? I've been trying to get in touch with him...
<rbasak> smoser: another approach I've seen done in quite a few packages is to generate another binary package for test purposes that contains what you need. Eg. "curtin-vmtest".
<rbasak> That would depend on curtin. Then for your test run, just enable the PPA (or whatever your binary package source is) and install curtin-vmtest, and you have what you needed from the source tree.
<smoser> rbasak: i had thought about that.
<rbasak> Pharaoh_Atem: I'm not sure. He's got very little overlap with my timezone, so I tend not to notice.
<Pharaoh_Atem> :/
<smoser> that m ight be the easiest path forward.
<smoser> or even just curtin-source
<rbasak> smoser: reasons in favour: I've seen it done that way in various places; you don't have to rely on an out-of-band connection between the two things.
<rbasak> A recent example I used is openscad-testing
<rbasak> mysql has something similar too IIRC.
<rbasak> I'm not so sure about curtin-source. A -test package has a specific user purpose. A -source package sounds like a corruption of what binary packages are meant to be.
<rbasak> I accept there's not much difference :)
<rbasak> OTOH you could in theory put packaging assistance into a -test package.
<rbasak> (to run the test suite, etc)
<smoser> yeah, -source just seemed a better name, because it is easier if i just grab all of source.
<smoser> than try to pick out vmtest/ portion or something.
<smoser> where woul dyou suggest it installing files to ?
<rbasak> /usr/share/curtin-vmtest/
<rbasak> Or /usr/share/curtin/vmtest/
<rbasak> Assuming that they're not architecture-specific, etc.
<jbicha> infinity: could you explain https://launchpad.net/ubuntu/+source/gvfs/1.34.1-1ubuntu3 ?
<infinity> jbicha: Seems pretty self-explanatory?  /etc/init doesn't exist on all Ubuntu systems.
<infinity> jbicha: It was fixing this: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/g/gvfs/20171028_074316_b5c74@/log.gz
<infinity> jbicha: It would be failing in Debian the same way, except that Debian doesn't run the tests at all because they require isolation.
<jbicha> ok, the file name was confusing though (upstart)
<infinity> jbicha: Because "/etc/init" is a path specific to upstart.
<infinity> jbicha: Hence that test started failing when we switched to systemd and removed upstart scripts from the testbed.
<cjwatson> smoser: If you literally just want a URL, I thought I mentioned that on #launchpad the other day?  https://launchpad.net/~OWNER/+archive/ubuntu/PPANAME/+files/PACKAGE_VERSION.dsc always works as long as the source package hasn't been removed for long enough that it's been garbage-collected.
<cjwatson> (lp.soyuz.browser.archive.ArchiveNavigation -> lp.services.librarian.browser.FileNavigationMixin -> lp.soyuz.model.archive.Archive.getFileByName)
<smoser> cjwatson: well that works if i know it came from a ppa. but this doesnt  just test ppa. also tests proposed or archive.
<smoser> so i wanted to find where it comes from and go off that.
<smoser> https://code.launchpad.net/~smoser/curtin/+git/curtin/+merge/337388 is what i have
#ubuntu-devel 2018-02-09
<tjaalton> I'm lost with lxc (again). created a container for bionic with "lxc-create -t ubuntu-cloud -n autopkgtest-bionic -- -r bionic -d daily" and it worked, but the container is not listed in 'lxc list' and 'lxc info autopkgtest-bionic' just says "error: not found"
<tjaalton> running autopkgtest of course fails with "Error: container autopkgtest-bionic is not defined"
<tjaalton> it fails even with containers that lxc info does list
<tjaalton> this is on a xenial box
<cjwatson> tjaalton: you're mixing the lxc and lxd tools; generally speaking lxc-* and 'lxc *' don't mix
<tjaalton> mixing how? these are from the manpages
<cjwatson> tjaalton: well, it's wrong.  what manpages?
<cjwatson> tjaalton: I mean, if you want to use lxc-* then you need to do that throughout, so you need to say lxc-ls -f rather than lxc list, etc.
<tjaalton> autopkg-virt-lxc and autopkgtest
<cjwatson> tjaalton: consider using the new world instead though as it's generally a lot easier to use; so 'adt-build-lxd ubuntu:bionic' to build the image and then it'll be a lxd image and show up in 'lxc list'
<tjaalton> I've probably done that before
<tjaalton> because lxc list does show two instances (for sid and zesty) but using them is the problem now :)
<cjwatson> right, adt-virt-lxc(1) has the creation instructions you give but it certainly doesn't recommend using 'lxc list' afterwards.  try adt-virt-lxd(1) instead
<cjwatson> ah, that actually recommends 'adt-build-lxd images:ubuntu/bionic/amd64' instead (ubuntu:... and images:ubuntu/... are built in somewhat different ways)
<tjaalton> ok, I'll start from there and write this down somewhere..
<tjaalton> too many ways to do something
<tjaalton> autopkgtest in xenial is too old, doesn't have manpages for adt-virt-*
<tjaalton> guess it's time to upgrade anyway
<tjaalton> mine is from backports
<cjwatson> I'm running xenial and have manpages for adt-virt-*.
<tjaalton> huh
<cjwatson> So ITYM too new.
<cjwatson> They probably refactored something between 3.20.4 and 4.3 ...
<tjaalton> why of course.. :)
<tjaalton> it's autopkgtest-virt-* now
<Mirv> everyone with lxc/lxd gets to the 'lxc' command confusion zone before learning the lxc=lxd lxc-=lxc truths :)
<Mirv> recently I was doing lxc inside lxd and got somewhat even more confused
<vila> Mirv: :)
<tjaalton> well, creating a bionic container doesn't seem to work, networking fails
<tjaalton> dns to be exact
<Mirv> you can try creating /run/resolvconf/resolv.conf manually with nameserver 8.8.8.8
<ogra_> on bionic rather /run/systemd/resolve/resolv.conf i
<ogra_> i guess
<tjaalton> how exactly, I'm just running autopkgtest-build-lxd
<tarzeau> if i would like to get a package into 18.04, and something is stuck in new queue, any chance to speed it up?
<tarzeau> the freeze is around end of february right?
<jbicha> tarzeau: it's stuck in Debian's NEW queue, right?
<tjaalton> I mean, the dns failure is in the container itself, it can't resolve archive.ubuntu.com...
<tjaalton> huh, looks like the host is affected too, wth
<tjaalton> nope, was just slow
<Unit193> So you're just having a bad day..
<Unit193> tjaalton: Oh, any chance -ati will be patched in bionic?
<tjaalton> patched for what?
<Unit193> freedesktop bug 102948
<ubottu> Freedesktop bug 102948 in Driver/Radeon "xf86-driver-ati can not let me visit tty1 to tty6" [Normal,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=102948
<Unit193> Switching TTYs doesn't work out so well.
<tjaalton> there will usually be new releases of ati & amdgpu before our FF
<tjaalton> I'll poke MrCooper about it
<Unit193> Thanks, and sounds good (looks like a few memleak fixes too.)
<tarzeau> jbicha: yes, the font and colmap
<tarzeau> jbicha: but i also plan to finish up cool-retro-term before march
<jbicha> tarzeau: you could try asking #debian-ftp and explain why you think you need it processed sooner
<jbicha> new packages can still be accepted into Ubuntu after Debian Import Freeze, but it's a manual process and not guaranteed
<tarzeau> jbicha: it's not like we don't have an own repo at work. it'd just make it easier, and thinking globally, i'm sure there's a few people having fun at the colmap fonts-league-spartan packages
<tarzeau> we haven't decided at work yet whether we stay with ubuntu 18.04 or go back to debian for the future...
<pisi> hello, i'm curious, when will be released gnome 3.27 packages for ubuntu 18.04
<juliank> pisi: Historically speaking it seems it started with the .9X series
<juliank> that is, 3.27.91
<juliank> merging the early alphas does not seem like a particularly good idea IMO
<juliank> but I'm not a desktop guy :D
<pisi> juliank: make sense, i heard theme and icon theme will change with 18.04. what about plymouth theme do you know?
<juliank> nothing
<pisi> this is bad i think plymouth theme too old
<juliank> I don't care much what I see in these 5 seconds :D
<juliank> but I'm pretty sure it's kept consistent with other stuff
<juliank> hmm, it seems to me the theme has not changed since at least 2015
<juliank> but then I don't think it looks a lot different from other UI elements
<xnox> pisi, there was chatter about community engaged redesign of plymouth theme, but not sure if anything has happened yet. at least we do have new plymouth merged, and have high-dpi plymouth by default now.
<pisi> xnox: Is there a link to this?
<doko> cjwatson: fyi, https://launchpadlibrarian.net/355902779/buildlog_ubuntu-bionic-amd64.py-macaroon-bakery_1.1.0-1_BUILDING.txt.gz
<cjwatson> doko: drat, thanks
<wxl> i can confirm the installer does not have an SMP kernel, at least in that `uname -a` does not report SMP and CONFIG_SMP is not set in /boot/config*
<wxl> oops wrong channel hah!
<cjwatson> doko: py-macaroon-bakery fix uploaded to unstable
#ubuntu-devel 2018-02-10
<Unit193> Heh, so the certbot backport/SRU never made it after all.
<doko> rbalint: I see you are uploader for ruby-gsl ... could you have a look at https://bugs.debian.org/889023 ?
<ubottu> Debian bug 889023 in src:ruby-gsl "ruby-gsl: FTBFS with ruby2.5: 'rb_cFixnum' undeclared" [Serious,Open]
#ubuntu-devel 2019-02-04
<alkisg> vorlon: great, except that... then all shims need to add the distro name in the paths that they use, otherwise they end up in the same grub name. They don't currently do that, afaik.
<alkisg> So it would be: UEFI > ubuntu shim > ubuntu grub > fedora shim > meh, ubuntu grub again, as the shimx64.efi name is hardcoded for all distros, with no distro name in their paths
<alkisg> (same for dhcp/tftp too)
<vorlon> alkisg: oboting ubuntu grub -> fedora shim means booting the fedora shim by its full path; and shim loads grub from the same directory
<vorlon> booting
<alkisg> vorlon: ah, thanks; I'll run some tests, as I think that many paths there were hardcoded, but I'm not sure if it was in the pxe or the local disk case. Merci!
<voltagex> Hi, does anyone know what the performance impacts of ZFS on kernel  5.0 will be? Looks like a pretty major patch. I'm on an Atom 2758 box with 32TB of disks and I don't see another way of testing this short of running a full scrub (20 hours or so)
<Skuggen> ahasenack: my_load_defaults should be there, but not load_defaults
<Skuggen> The net-snmp package I tested with some time back was patched to add the my_
<ahasenack> Skuggen: yeah, but it didn't find my_load_defaults. I wonder if it's related to the missing my_global.h header file
<ahasenack> Skuggen: net-snmp upstream has basically an if/then/else now. It tries load_defaults, then my_load_defaults, and if neither exist, uses mysql_options()
<ahasenack> Skuggen: line 450: https://sourceforge.net/p/net-snmp/code/ci/master/tree/apps/snmptrapd_sql.c
<ahasenack> it calls mysql_options (if conditions are met) in line 565
<ahasenack> I'm trying to backport that
<Skuggen> ahasenack: my_global (and my_sys) have been removed from 8.0. Should only need mysql.h
<ahasenack> Skuggen: and my_load_defaults? A grep for it in /usr/include -r doesn't find it
<Skuggen> Hm, maybe I was wrong
<ahasenack> it looks like mysql_options() can be used to load ~/.my.cnf
<ahasenack> I'll keep on that path
<Skuggen> Yeah, looks like that's the intended way now https://dev.mysql.com/doc/refman/8.0/en/mysql-options.html
<ahasenack> k
<Skuggen> Talked with devs. my_load_defaults was added back to the export list when we did the 5.7 transition in 16.04, but it was only meant to be a temporary measure :)
<ahasenack> I see that kind of thing happening a lot
<ahasenack> found a bug in mysql8 where another name, that had been removed, was added back by mistake (in the 8 series)
<ahasenack> forgot what it was
<ahasenack> so the bug was to remove it again, for good :)
<rbasak> Has anyone successfully used "git ubuntu import-ppa" recently?
<ahasenack> for cacti-spine: https://bugs.launchpad.net/ubuntu/+source/cacti-spine/+bug/1814526
<ubottu> Launchpad bug 1814526 in cacti-spine (Ubuntu) "FTBFS mysql8: my_bool" [Undecided,New]
<ahasenack> rbasak: I didn't even know it existed
<ahasenack> rbasak: do you have a tag for mysql8 ftbfs?
<rbasak> ahasenack: I invented mysql-8.0-transition earlier. Perhaps use that and the ftbfs tag?
<rbasak> Skuggen: FYI ^
<Skuggen> ahasenack: I'm testing just putting my_bool back in now (it's a meaningless type, but at this stage it's better to patch mysql than the ~50 packages that use the type :))
<Skuggen> Can use cacti-spine to verify the fix
<ahasenack> ok
<ahasenack> we could still use the bugs, though, to slowly migrate the packages away from my_bool then
<Skuggen> Yeah. I sent in bug reports about this for all rdeps of libmysqlclient21 (or I thought I did, but maybe the commands I used to find them didn't list everything)
<ahasenack> bugs in ubuntu?
<ahasenack> any particular tag or pattern to search for?
<Skuggen> "FTBFS with MySQL 8.0"
<Skuggen> A few of them are for other things like my_sys.h and/or my_global.h, but the my_bool issue is the most common
<ahasenack> I hit 4 in net-snmp
<ahasenack> - my_bool
<ahasenack> - my_load_defaults
<ahasenack> - my_glpobal.h and my_sys.h
<ahasenack> - something with my_init, MY_INIT, but that might have changed in a later 5.7 already
<Skuggen> I got net-snmp to build by fixing the two headers and my_bool, I think
<ahasenack> my_load_defaults is gone, that needs fixing
<ahasenack> it's the last fix I need
<Skuggen> But net-snmp can use mysql_options, can't it?
<ahasenack> yes
<ahasenack> that is the fix
<ahasenack> it's just not in our package yet
<ahasenack> about init, it was "there is mysql_init(), MY_INIT(), and my_init()"
<ahasenack> if-defs all over the place
<Skuggen> Maybe my_load_defaults was still in there in earlier 8.0 versions (it was an "unofficial" export in 5.7) and only removed recently.
<Skuggen> https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mysql-8.0/+packages test of cacti-spine
 * apw just did a dist-upgrade in disco ... and grub-efi-amd64-signed and shim-signed failed to install
<apw> which seems to be stemming from grub-efi-amd64-signed complaining about 'db is empty' maybe
<apw> /usr/share/grub/grub-check-signatures <-- seems it is this which is failing
<apw> it seems this is because mokutil --export --db is saying db is empty; and this is fatal to bootloader installation
<ahasenack> hi, does anybody know what this means: ERROR: erroneous package: rules extract failed with exit code 1
<ahasenack> https://pastebin.ubuntu.com/p/JxJFfCVB24/ more context
<ahasenack> it's an autopkgtest run in disco, for freeipa
<ahasenack> freeipa is in disco-proposed
<ahasenack> but apparently was removed from disco, is that it?
<ahasenack> hm, looks like freeipa needs to be removed from disco-proposed then?
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/dogtag-pki/+bug/1813155
<ubottu> Launchpad bug 1813155 in freeipa (Ubuntu) "remove from disco-proposed, Dogtag doesn't support TLS 1.3/Java 11 yet" [Undecided,New]
<ahasenack> tjaalton: ^ ?
<tjaalton> ahasenack: I'll upload a client-only version soon
<tjaalton> to debian first
<LocutusOfBorg> tjaalton, hello, what is the rationale for this delta? https://launchpad.net/ubuntu/+source/httpcomponents-client/4.5.6-1ubuntu1 ? can it be syncd?
<tjaalton> LocutusOfBorg: yep
<LocutusOfBorg> tjaalton, can you please sync it, or should I do it?
<tjaalton> LocutusOfBorg: done
<jilocasin> evening all
<jilocasin> anyone have any idea why *the* default installer for 18.04.1 LTS Server is a subiquity based cloud one?
<rbasak> I answered you in #ubuntu-server.
<rbasak> !crosspost
<ubottu> Please don't ask the same question in multiple Ubuntu channels at the same time. Many helpers are in more than one channel and it's not fair to them or the other people seeking support.
<jilocasin> rbasak: thanks, I responded there as well.
<jilocasin> rbasak: sorry, I was told in #ubuntu to ask in #ubuntu-devel, #ubuntu-discuss, snd #ubuntu-server
<rbasak> Sorry you were misled. General consensus on Ubuntu IRC channels is what the bot says on that - please don't crosspost.
<krytarik> They didn't indicate to post it in all of them at once though.
#ubuntu-devel 2019-02-05
<mantas-baltix> Hi
<mantas-baltix> could someone tell why libreoffice 6.1.4 packages are only in ppa:libreoffice/ppa, but not in ppa:libreoffice/libreoffice-6-1 ?
<mantas-baltix> ricotz: it seems you built libreoffice 6.1.4 packages in ppa:libreoffice/ppa 4 weeks ago, are there any reasons why 6.1.4 isn't in ppa:libreoffice/libreoffice-6-1 ?
<ricotz> mantas-baltix, I meant to copy them a week later, but forgot
 * ricotz copied them now
<mantas-baltix> ricotz: :)
<mantas-baltix> thanks
<cpaelzer> does anyone know what the data source and/or update cycle of http://qa.ubuntuwire.org/rdepends is - it seems out of date ~6 hours after publish of a new binary to disco so I was wondering what the process behind updating it looks like?
<cpaelzer> dannf: would you mind looking to check the ppa for 1771662 or does that need Jason?
<xnox> coreycb, should horizon package drop python2 dependencies? specifically the openstack-dashboard appears to list "python2-thing | python3-thing" hence many of the python2-things are still pulled into main.
<xnox> hm
<xnox> or am i confused.
<xnox> ah, it's all done in proposed, and i am looking at the release pocket!
<xnox> nevermind, everything looks great.
<coreycb> xnox: ah great :)
<xnox> coreycb, retriggered adt tests with more &trigger= to get them green. Hopefully will pass, and migrate in a few hours ;-)
<coreycb> xnox: awesome, thanks!
<dannf> cpaelzer: i can do it
<cpaelzer> thanks
<rbasak> waveform: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
<bdmurray> simpoir: Could you provide some verification details in those landscape-client SRU bugs in addition to flipping the tags?
<simpoir> bdmurray: sure. I can add comments about the verifications. I simply went through all of those, one by one. For one of those I had to ad details to the reproducing instructions.
<bdmurray> simpoir: ideally we want something detailed like https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1795024/comments/13
<ubottu> Launchpad bug 1795024 in update-manager (Ubuntu Cosmic) "setting release-upgrades Prompt to never can cause confusing behavior" [Medium,Fix released]
<simpoir> bdmurray: ok, so ideally pasting of the results?
<bdmurray> simpoir: yep
<simpoir> bdmurray: sounds good
<rbasak> Skuggen: been talking to vorlon about the MySQL transition. We don't know how to proceed with it right now, and leaving it as it would entangle everything else into the transition. So given that we've barely started it, we'd like to delete src:mysql-8.0 and rebuild the rdeps that have already built against it, thus reverting back to where we were before I uploaded src:mysql-8.0. That's not to say
<rbasak> that we're not doing the transition this cycle, but just freeing up other work in the archive from getting entangled while we figure out what we're doing.
<rbasak> Skuggen: does that sound OK to you?
<Skuggen> Yeah. There are a lot of things blocked by it right now
<rbasak> OK, thanks.
<rbasak> vorlon: please go ahead and delete src:mysql-8.0 from disco-proposed.
<vorlon> ack
<ahasenack> what happens with the packages in proposed that already built against libmysqlclient21, aka, mysql8?
<vorlon> ahasenack: those which were no-change rebuilds only, I will delete.  Those which have sourceful changes, I will reupload.
<ahasenack> Skuggen: hi, need a bug about apparmor violations with mysql8?
<ahasenack> or are you aware of these: https://pastebin.ubuntu.com/p/cWq7ymJKBR/
<Skuggen> Hm, I've seen the sys/devices one before, but not the others
<ahasenack> yeah, the sys one I thought was sorted already
<Skuggen> Ah, our upstream profile is a bit different
<ahasenack> Skuggen: the mysqlx one matches an error in mysql's error log
<ahasenack> Skuggen:
<ahasenack> 2019-02-05T18:40:40.574659Z 0 [ERROR] [MY-011300] [Server] Plugin mysqlx reported: 'Setup of socket: '/var/run/mysqld/mysqlx.sock' failed, can't create lock file /var/run/mysqld/mysqlx.sock.lock'
<ahasenack> and ssl is probably because now it's being linked with openssl, whereas it wasn't before, or so I understood
<ahasenack> never really paid much attention to which ssl library it was linked
<Skuggen> Yeah, the mysqlx and sys/devices ones are fixed upstream, but don't see an entry for the openssl config
<Skuggen> Will need to fix that (and port over our updates). Thanks :)
<ahasenack> upstream ships with an apparmor profile? I thought it was our/debian's addition
<Skuggen> Our debian/ubuntu packaging is in packaging/deb-in (the files are generated by cmake)
<xnox> jamespage, coreycb - i think you did it =) this is so nice! http://people.canonical.com/~ubuntu-archive/component-mismatches.html has a long list of "Binary only movements to universe (ubuntu-openstack)"
<LocutusOfBorg> tjaalton, doko can we please remove freeipa from here? https://bugs.launchpad.net/ubuntu/+source/dogtag-pki/+bug/1813155
<ubottu> Launchpad bug 1813155 in freeipa (Ubuntu) "remove from disco-proposed, Dogtag doesn't support TLS 1.3/Java 11 yet" [Undecided,New]
<Skuggen> ahasenack: But I think our original Debian packaging (before my time) was made to mirror that of Debian's
<coreycb> xnox: ahh how nice is that :)
<vorlon> rbasak, ahasenack, Skuggen: deletions from -proposed done, I've only identified 6 that had sourceful changes in -proposed and need reuploading which I'll do once I confirm mysql-8.0 is unpublished from the archive
<xnox> freeradius is in NEW waiting for python2/3 split out.
<xnox> and then it will be just samba then
<ahasenack> vorlon: ok. I added patches to net-snmp so it builds with mysql-8, but they have a lot of #ifdefs so should continue building with 5.7
<ahasenack> haven't uploaded that yet
<ahasenack> so we will see soon
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1814270 was about that
<ubottu> Launchpad bug 1814270 in net-snmp (Ubuntu) "FTBFS with mysql 8: my_global.h: No such file or directory" [High,In progress]
<tjaalton>  LocutusOfBorg: done
<vorlon> rbasak, ahasenack, Skuggen: -proposed looks clean to me now wrt mysql-8.0 removal; let me know if you spot anything amiss
<ahasenack> confirmed
<LocutusOfBorg> tjaalton, unfortunately the testsuite still requires the server...
<tjaalton> ah damn
<LocutusOfBorg> :)
<GunnarHj> vorlon: Hi Steve, a few months ago you started a discussion about the bionic SRU at bug #1762889, but never followed up, so the thing is still in the queue. Can we please continue the talk, hopefully resulting in accepting the old style code for the SRU.
<ubottu> bug 1762889 in pkgbinarymangler (Ubuntu Bionic) "dh_translations doesn't strip .desktop files when more than 1 pot target with meson" [Medium,Triaged] https://launchpad.net/bugs/1762889
<rbasak> vorlon: thank you for your help!
#ubuntu-devel 2019-02-06
<Skuggen> vorlon: Thanks :)
<ahasenack> Skuggen: heh, net-snmp upstream decided to replace my_bool with a char, have you seen this before? https://sourceforge.net/p/net-snmp/code/ci/9f4af8c42d515e6b214738cc97212dfbe7f749cf
<ahasenack> what was my_bool before, in terms of size?
<ahasenack> I guess they want a byte
<Skuggen> ahasenack: Originally, my_bool was just a char
<ahasenack> ok
<Skuggen> Well, I'm not 100% sure about "originally" since it's old, but it was a char before :)
<doko> ahasenack, cpaelzer: do you plan with samba 4.10 for disco? looks like Python3 is making some progress there
<ricotz> doko, would you have time to put together a gcc-mozilla based on 8.2 in bionic?
<ahasenack> doko: yeah, it's the first one with py3 and py2
<ahasenack> doko: I wasn't planning on going ahead of debian
<doko> ricotz: there is a proper gcc-8.x in bionic, you don't need another build
<ricotz> doko, for xenial, trusty isn't worth it anymore, I guess
<ricotz> I meant to backport from bionic
<doko> ricotz: it's easy. just rename the package from gcc-8 and look what changes the existing gcc-mozilla has
<doko> wasn't chris ccoulson doing that?
<ricotz> doko, I know, I did so with 6.5.0 which is already required for the current firefox to fix armhf/arm64 -- but I ran into failures on trusty
<ricotz> I can try with 8.2 again though
<ricotz> doko, not sure what chris is doing these days
<ricotz> basically osomon has taken over the mozilla stuff
<doko> including the b-d's? ;p
<ricotz> mw_hudson is doing rustc/cargo
<ejat> hi .. is there ppa for gnome 3.32 available for testing?
<ricotz> doko, this is something which came up https://paste.debian.net/plain/1065702
<jbicha> ejat: GNOME 3.32 has not been released yet, but there (probably) won't be a PPA either
<ahasenack> has anybody written a sort of recursive check-mir script? To chase down all non-main deps and run it again on each, until there is none left?
<ejat> jbicha: ok thanks
<ejat> jbicha: can u advise on this => https://paste.ubuntu.com/p/sWqW2hWQZp/
<jbicha> that doesn't mean anything to me
<ejat> gnome-control-center crashed
<ejat> in disco -proposed
<jbicha> could you file a bug with apport
<jbicha> also: https://askubuntu.com/questions/785414/is-it-ok-to-enable-proposed-updates-during-ubuntus-development-cycle
<ejat> jbicha: bug 1814947
<ubottu> bug 1814947 in gnome-control-center (Ubuntu) "segmentation fault" [Undecided,New] https://launchpad.net/bugs/1814947
<jbicha> ejat: that still provides almost no info. I meant can you use Ubuntu's error reporter thing to report the crash with the debug info
<jbicha> but I'm too busy working on other stuff this week to be able to help you really. Sorry
<ejat> jbicha: okay ill try .. no worries .. sorry to take ya time
<ahasenack> is it possible to disable the universe component in a ppa, when building a source package there?
<tumbleweed> IIRC it's encforcing component separation is PPA configuration option
<ahasenack> I have "ï¿¼ Default (security dependencies and recommended updates)."
<ahasenack> and
<ahasenack> "Use the same components used for each source in the Ubuntu primary archive."
<ahasenack> the other option is " Use all Ubuntu components available.", which doesn't seem to be what I want
<infinity> ahasenack: What are you trying to accomplish, exactly?
<infinity> ahasenack: main can build-dep on universe (even in the primary archive) now.
<ahasenack> testing a mir
<ahasenack> it's a universe package, for which I'm listing all non-main build-deps
<infinity> ahasenack: main can't have runtime deps on universe, but PPAs don't have components, so everything in a PPA is in main.
<ahasenack> my plan was to upload said source package, have the build fail because of missing deps (which are in universe), and then start uploading the universe deps one by one
<infinity> Yeah, that's not going to work.
<ahasenack> ok, local lxd it is then
<ejat> seb128:  updated as your advise in bug 1814949
<ubottu> bug 1814949 in gnome-control-center (Ubuntu) "gnome-control-center crashed with SIGSEGV in __GI___libc_free()" [Undecided,New] https://launchpad.net/bugs/1814949
<seb128> ejat, thx
<ejat> thanks to you for the guide ..
<seb128> ejat, do you remember what panel you opened last?
<seb128> ejat, and do you have special discuss connected or specifc fs? (like zfs)
<jbicha> seb128: yeah the zfs in the original bug was the one thing that looked interesting :)
#ubuntu-devel 2019-02-07
<ejat> i dont have specific fs
<mwhudson> oh um i guess i should do some live server installer testing
<mwhudson> although some enterprising soul has apparently done it
<LocutusOfBorg> seb128, good morning, what do you think wrt merging alsa-utils? a crash fix is always nice :)
<seb128> LocutusOfBorg, I was waiting for them to upload 1.1.8, it's prepared in salsa for more than a week
<LocutusOfBorg> oh... I wondered if they were going, but freeze is coming
<LocutusOfBorg> so, they will probably not upload it
<LocutusOfBorg> (or not in unstable)
<seb128> k, well we want that version in disco
<seb128> I can do the merge/upload
<LocutusOfBorg> thanks for caring :)
<seb128> thx for pointing out why they are probably not uploading :)
<seb128> yw!
<LocutusOfBorg> right now the freeze for buster is ongoing, so the outstanding merges can be done easily
<LocutusOfBorg> I'm trying to clean up the 130 php merges
<LocutusOfBorg> :(
<kreyren> Need more info to https://pastebin.com/raw/LL4x817C (recompiling kernel with configuration grabbed from gentoo)
<vorlon> cjwatson: (repeating on more appropriate channel) peeked at your approach to the ucf change; AIUI the result of this is that if the user has tried to dpkg-reconfigure and change a setting through debconf, the new value will be ignored
<cjwatson> (answered on #ubuntu-meeting, didn't see this until later)
<vorlon> cjwatson: I don't have a script for it (is there any reusable code for a script-driven debconf frontend?), but I can confirm that with grub-pc 2.02+dfsg1-10, dpkg-reconfigure grub-pc, change the value of GRUB_CMDLINE_LINUX, there is no ucf prompt and also the change does not land in /etc/default/grub
<cjwatson> vorlon: OK.  I could try to do something about it, but I'm not very convinced that I care about supporting that method of changing the GRUB config; the filesystem has primacy.  Do you have a specific use case for doing that?
<cjwatson> Aside from preseeding, I think that anything that's trying to change the config that way has better and more robust alternatives available
<rbasak> I'm not sure what you're talking about exactly, but I'm hopeful you're talking about fixing bug 1747464 and bug 1812752 :)
<ubottu> bug 1747464 in cloud-images "Regression: users are prompted on upgrade of cloud images" [High,Triaged] https://launchpad.net/bugs/1747464
<ubottu> bug 1812752 in grub2 (Ubuntu) "UX: changing GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub has no effect in cloud images" [Undecided,New] https://launchpad.net/bugs/1812752
<cjwatson> rbasak: I already fixed the first in Debian and am trying to persuade vorlon to take my fix rather than doing other fragile stuff :)
<rbasak> Thanks :)
<cjwatson> rbasak: I'm not especially convinced about changing the latter - it could easily end up making the logic even more complicated and therefore worse
<rbasak> I admit I don't have any suggestions on how to actually fix the second one cleanly
<cjwatson> rbasak: Well, ifthis is specifically menu.lst, it's probably a variation of the same problem but not directly fixed by what I did in Debian
<cjwatson> (for the first one)
<cjwatson> Looks v similar though
<cjwatson> rbasak: maybe this cloudimg thing should just be appending to or otherwise modifying the variable rather than overwriting it wholesale?
<cjwatson> I haven't looked at exactly what it's changing
<rbasak> Would that work? Ie. can it realy on the previous definition?
<rbasak> Does /etc/default/grub need to define it by default?
#ubuntu-devel 2019-02-08
<rbasak> Could update-grub instead default to the default if unset?
<rbasak> IIRC the cloud image merely needs to add a console=ttyS0
<rbasak> But currently it redefines the entire thing.
<cjwatson> Err not sure that would help.
<cjwatson> The cloud image thing should just append then.  That's all you need to do.
<rbasak> I think the confusing thing is that there are two places to look - the top level _and_ .d/
<rbasak> And in cloud images we ship them already overriding each other in a (IMHO) not-obvious way.
<cjwatson> I think that's inevitable
<rbasak> Even if it only appended, it wouldn't be obvious after one spots the first definition in /etc/default/grub that it's being changed.
<cjwatson> Sorry
<cjwatson> It also seems not that non-obvious.  Main file read then .d fragments; it's common enough practice?
<cjwatson> And trying to unwind it now would be impossibly complex anyway IMO
<rbasak> Yeah I accept there isn't necessarily a better solution than what we have now.
<rbasak> common enough practice> yes, except that usually (IMHO) distro-shipped bits don't override each other
<rbasak> (by default)
<cjwatson> Fragments that override rather than appending are def a problem
<rbasak> Further than append, normally I'd expect, in the distro default, that each thing is only defined in one place.
<cjwatson> GRUB_CMDLINE_LINUX is in some ways a collection of little things rather than one thing, though
<cjwatson> It could be clearer if it weren't in shell  ..
<rbasak> That's true
<vorlon> cjwatson: "the filesystem has primacy" - then surely dpkg-reconfigure should not even show the prompts?
<cjwatson> That's allowed *during grub's own configuration process*
<xnox> rbasak, vorlon, cjwatson - i thought all cloudimages use grub.d/* snippets, not /etc/default/grub itself.
<vorlon> cjwatson: I guess I don't object to grub not being configurable through debconf, but I do object to debconf questions whose answers are ignored :)
<cjwatson> Are you saying they're ignored if you change them during dpkg-reconfigure grub-foo?
<vorlon> yes
<vorlon> that's what I was saying in the first place
<cjwatson> I thought you meant preseeding
<vorlon> no :)
<cjwatson> OK, then I agree that's a bug, would appreciate a Debian report
<vorlon> answers are accepted, postinst seds them into /tmp/grub.soandso, runs ucf with UCF_FORCE_CONFFOLD=1, ignores everything in the tmpfile
<vorlon> ok
<cjwatson> I'm fairly convinced the ucf forcing is necessary - I spent a long time tracing through ucf trying to find any viable alternative - but I could refine the conditions that lead to that maybe
<cjwatson> xnox: I don't think anyone is disagreeing with that
<vorlon> cjwatson: well, cough, if we wanted to catch all cases we could sed the debconf answers into each of /etc/default/grub, the tmpfile, and /var/lib/ucf/cache/:etc:default:grub
<vorlon> which would then be consistent with debconferry on non-ucf config files
<cjwatson> I'm happy to experiment with that but it trips my danger-will-robinson sense
<cjwatson> I would be very surprised if seddery on /etc/default/grub before invoking ucf didn't produce *some* kind of bug
<vorlon> hmm, I tested all the cases I could think of, and the only remaining issue was a subset of the previous misbehavior, and "fixable" by also mucking with /var/lib/ucf/cache
<cjwatson> I would prefer approaches like adding "have none of the relevant debconf options changed in this run?" to the condition that determines whether to set UCF_FORCE_CONFFOLD=1
 * vorlon nods
<cjwatson> but I'll have a play
<GunnarHj> vorlon: Did you see this question:
<GunnarHj> https://irclogs.ubuntu.com/2019/02/05/%23ubuntu-devel.html#t21:59
<vorlon> GunnarHj: I did, but didn't have a chance to swap back in the context, sorry.  So, tomorrow is my SRU day again, and I'll re-review it then in light of the answers on the ug
<vorlon> bug
<GunnarHj> vorlon: Ok, TIA.'
<GunnarHj> vorlon: I suspect that jbicha would like to add to the SRU some change from version 144, so a detailed review is probably not needed with the one currently in the queue. A conclusion on when to apply your proposed improvement would be highly desirable, though.
<LocutusOfBorg> seb128, I fixed gstreamer-vaapi, to avoid duplicated work :)
<LocutusOfBorg> (I forgot to tell you I was fixing it, I hope you didn't loose time)
<seb128> LocutusOfBorg, thx (and no, I didn't yet)
<LocutusOfBorg> nice, I hope to see it migrate in some minutes
<seb128> LocutusOfBorg, did migrate now :)
<LocutusOfBorg> yep :D
<ahasenack> doko: hi, I have a few questions about a MIR for a package that build-deps on universe golang packages
<ahasenack> doko: https://wiki.ubuntu.com/MIRTeam lists "Evaluating cost/benefits while considering the ABI instability of golang libraries during this period, the MIR team decided for 17.10 and later to allow static builds of golang packages in main, so long as the number of these packages remains low and they follow the guidelines below. The MIR team may reevaluate this in the future."
<ahasenack> doko: specifically i was asked to list the dependencies of runc (http://launchpad.net/ubuntu/+source/runc)
<ahasenack> doko: it has a long chain of golang builddeps that are in universe
<ahasenack> which are statically linked
<ahasenack> so they don't appear as runtime dependencies
<ahasenack> so how can I determine if it's suitable for a MIR from that perspective, aka, "dependencies in universe"?
<ahasenack> cyphermox: hi, do you have an opinion on my MIR questions above? The runtime deps of the package are ok in terms of only pulling in main, but the build time deps from universe are statically linked (golang)
<cyphermox> build deps aren't part of the MIR anymore, only binary deps.
<cyphermox> so we're looking at runc or something else?
<ahasenack> cyphermox: runc
<ahasenack> cyphermox: which has universe golang builddeps
<cyphermox> yup ok
<ahasenack> cyphermox: were it not golang, those deps would be runtime deps
<cyphermox> well, they aren't -- that's why there's that line about evaluating cost/benefit given ABI installability, etc. and we allow them as long as the number of packages is low
<cyphermox> is the MIR bug open yet
<ahasenack> the number of packages it builds with is low, or the number of packages in this situation in main is low?
<cyphermox> the number of packages in that situation in main :)
<ahasenack> cyphermox: no, no mir bug yet, I was evaluating the list of dependencies to see if we were going to need other MIRs for them
<ahasenack> cyphermox: so, in principle, no other dependencies need to be pulled in, but the mir team will evaluate the status of such packages in main, is that the tl;dr regarding this question of mine?
<cyphermox> correct, yes
<ahasenack> cyphermox: thanks!
<zimmerian> Hello - I am wondering if there's documentation around the distupgrade python module?
<zimmerian> I'd like to automate around it for say, disk free, obsolete kernels, etc rather than sift through main.log after do-release-upgrade runs
<zimmerian> it seems distupgradecache.py will get it done but when I launch it manually it doesn't find parent '' or something so guessing there's a different way to call it
<zimmerian> I can try and find my way around it but was hoping there'd be some docs maybe you all use to speed up progress - thank you!
<zimmerian> or thanks in advance :-)
<ahasenack> hi, anybody from foundations planning on merging isc-dhcp 4.4.x?
<infinity> vorlon: ^-- Last merge was by you in zesty.
<ahasenack> i started, but it's intimidating
<ahasenack> and many things depend on the dhcp server
<infinity> And the client!
<ahasenack> not to forget the client, yes
<infinity> I mean, if I were ranking for importance, I'd put the client first. :)
<infinity> "My dhcp server didn't come up" is something you can SSH in and fix.
<infinity> Anyhow...
<infinity> vorlon: I nominate you Foundations isc-dhcp TIL, but feel free to pass the buck? :P
<ahasenack> i don't understand the reason for the system-bind.patch, why it picks the libraries it picks
<ahasenack> there is no bug number, no reasoning
<ahasenack> in 4.3.x, debian removed a bunch of static libraries from linking, and added dns-export and isc-export
<ahasenack> ubuntu picked up on that and added a few more dynamic libraries to the mix: irs-export and isccfg-export
<ahasenack> I can do the same with 4.4
<ahasenack> but would like to know what it was fixing
<vorlon> infinity: I prefer the MoM rule that says ahasenack gets to do it ;)
<ahasenack> hah
<vorlon> ok I suppose I'll look... but not today
<ahasenack> there is an infiniband support patch who lists vorlon as one of the authors :)
<ahasenack> s/who/that/
<vorlon> lies
<ahasenack> LocutusOfBorg: do you know Ryan Tandy's irc nick? rtandy perhaps?
#ubuntu-devel 2019-02-09
<alkisg> In https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1815172, we went through the verification steps, the update was published, and now adconrad asks for verification again, could that be some script bug?
<ubottu> Launchpad bug 1815172 in linux (Ubuntu) "Black screen on skylake after 18.0 => 18.2 update" [Undecided,Confirmed]
<tsimonq2> alkisg: Those are two different releases.
<alkisg> tsimonq2: check bionic, it's already there
<tsimonq2> https://launchpad.net/ubuntu/+source/mesa/18.2.8-0ubuntu0~18.04.2 <-- no, it just landed in -proposed.
<alkisg> 18.2.2-0ubuntu1~18.04.2 500         500 http://gr.archive.ubuntu.com/ubuntu bionic-updates/main
<alkisg> Oh, let me see where apt changelog pulls from then, as the fix is there
<tsimonq2> It seems tjaalton kept those changelog entries.
<tsimonq2> Human error, not script error. :)
<tsimonq2> (If it's even a human error.)
<tsimonq2> Although Timo did forget an SRU bug for the backport...
<tsimonq2> hmm
<alkisg> So, in comment #13 they ask me to test 18.2.2-0ubuntu1~18.04.2) bionic
<alkisg> I do, it lands in -updates, everything fine
<alkisg> Then another release is made, and another request for verification is done,
<alkisg> ...but what does this new release address? It doesn't address my issue, which was already addressed...
<tsimonq2> infinity: ^ Shouldn't this have been accepted with a tracking bug for the backport, or are we missing something here?
<tsimonq2> alkisg: I would say ignore it for now, until Adam or Timo answers.
<alkisg> ty
<tsimonq2> Oh, it seems bug 1811225 does have the tracking for this release, so the only question here is what to do with the other bugs.
<ubottu> bug 1811225 in mesa (Ubuntu Cosmic) "Mesa 18.2.8 stable release" [Undecided,Fix committed] https://launchpad.net/bugs/1811225
<tsimonq2> alkisg: I'm willing to bet, after seeing that, that another round of testing will be needed to verify that the bugfix didn't regress between the upload currently in bionic-updates and bionic-proposed.
<tsimonq2> So while it was fixed, regression testing is needed here. That would make sense.
<alkisg> Yeah that makes sense, I hope that the fix wasn't overwritten by the larger update though
<tsimonq2> That's what someone has to find out. :)
<alkisg> No I mean dropped from debian/patches
<tsimonq2> Well, it's referenced in the changelog, so I'm guessing not.
<tsimonq2> It wouldn't hurt to grab the packaging and verify though.
<tsimonq2> (The patch itself might look different because of the new upstream release anyway, thus the need for another round of testing I think.)
<alkisg> It's a one-liner... thanks, I'll do a test when the it's built
<tsimonq2> Heh, I didn't know the context at all.
<infinity> tsimonq2: The backport bug is there in a previous changelog entry.
<tsimonq2> infinity: Yep, I realized that. :P
<tsimonq2> Thanks.
#ubuntu-devel 2020-02-03
<xnox> doko:  thanks!
<doko> gcc-9 builds still running ...
<doko> RikMills, xnox: ^^^
<jibel> doko, okay, I'll have a look at autopilot to remove the dep on qt4
<seb128> hum, a recent file-roller update fails to build on arm64/s390x with that error
<seb128>  /usr/bin/ld: cannot find -lgcc_s
<seb128> does anyone has an idea what than is about (https://launchpadlibrarian.net/463253875/buildlog_ubuntu-focal-arm64.file-roller_3.35.90-1_BUILDING.txt.gz)
<seb128> https://launchpad.net/ubuntu/+source/neon27/0.30.2-4 has the same problem
<seb128> I guess toolchain problem in focal-proposed?
<seb128> doko, ^ do you know about that?
<ricotz> https://launchpad.net/ubuntu/+source/gcc-9/9.2.1-26ubuntu3
<seb128> hey ricotz
<ricotz> seb128, hi
<seb128> ricotz, is that the version that breaks it or fix it? :)
<seb128> well it failed to build on those archs as well
<ricotz> seb128, I am sure he is aware, seems -26 is borked
<seb128> we should maybe just delete that version from proposed meanwhile?
<seb128> well, let's wait to see if doko is around and he prefer to try to fix it
<ricotz> not my call, but that would be reasonable
<ricotz> seb128, could you retry https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vala
<seb128> ricotz, retry isn't really working, see http://autopkgtest.ubuntu.com/packages/a/automake-1.16/focal/armhf
<seb128> but the issue is not due to vala, it failed its own trigger, so I think we should just ask to ubuntu-release to skip the automake-1.16/arhmf result to let vala be a candidate
<ricotz> seb128, I see, that would be nice
<RikMills> seb128: dok0 said last night he was building a fixed gcc, which I suspect is here: https://launchpad.net/~doko/+archive/ubuntu/bootstrap/+packages
<seb128> RikMills, ah, good to know, thx
<xnox> seb128:  read the overnight backlog
<doko> xnox, RikMills: fixed gcc-9 published. I would appreciate it if you could give back failed builds on arm64/s390x in proposed. currently at a workshop
<xnox> doko:  i did give back mine. they look ok now! thank you =)
<doko> that was not my question
<gpiccoli> o/ sil2100 - guess what I'm gonna talk? mdadm, of course ! heheh
<gpiccoli> The pkg is on -proposed for 2 weeks almost, and was tested/verified by me
<gpiccoli> Any chance we get that promoted to -updates? Tnx in advance
<sil2100> gpiccoli: hey! hm, I'm worried that comment #11 from LP: #1850540 is still valid? .4 is still in the works
<ubottu> Launchpad bug 1850540 in linux (Ubuntu Focal) "multi-zone raid0 corruption" [Undecided,Confirmed] https://launchpad.net/bugs/1850540
<gpiccoli> sil2100, this was dropped! heheh
<gpiccoli> We discussed with dannf, no work from his LP is in -proposed now
<cjwatson> xnox: One finishes the u-a-t porting work instead of asking passive-aggressive questions? ;-)
<cjwatson> It shouldn't be miles away
<gpiccoli> That was a factor of delaying in fact - because of regressions in that layout patches, it got my LP delayed hehe
<gpiccoli> So, dannf agreed we get mine released and then he'd re-add his work on mdadm, on top of mine =)
<xnox> cjwatson:  u-a-t? =)
<xnox> ah
<xnox> nice =)
<xnox> true
<xnox> i think the one script that I needed "just worked" wich a change of a shebang ;-)
<cjwatson> Some years back I did a bunch of anticipatory porting work but deliberately held off from changing the #! because at the time a lot of its users were on Ubuntu releases that didn't have a sufficiently py3-capable launchpadlib
<sil2100> gpiccoli: crap, so it's this darn bug again
<sil2100> gpiccoli: you are right, but the pending-sru page still displays the bug as being part of the upload - that's a bug that's happening from time to time there
<sil2100> And confusing everyone, eh
<gpiccoli> haha ok sil2100, no problem! Tnx for your attention
<sil2100> gpiccoli: ok, let me take a look then now!
<gpiccoli> Awesome =]
<gpiccoli> And I think the kernel part was reworked in the last cycle, so dannf likely will have the mdadm part soon to be merged, and finally get that LP resolved too
<ahasenack> hi, any idea why this package from debian isn't in ubuntu yet? https://launchpad.net/debian/+source/vmem
<Laney> ahasenack: https://people.canonical.com/~ubuntu-archive/auto-sync/current.log
<Laney> vmem_1.8-1 is trying to override modified binary libvmem1_1.7-1ubuntu1.  OK (y/N)?  n
<ahasenack> ah
<ahasenack> ok, I'm about to update pmdk (where that libvmem 1.7 comes from)
<ahasenack> then autosync will work I guess?
<ahasenack> pmdk 1.8 doesn't have vmem anymore
<Laney> looks like it indeed
<ahasenack> ok, thanks
<gpiccoli> Thanks a lot sil2100 =)
<sil2100> gpiccoli: yw! Sorry it took longer than expected, I blame the tooling for that!
<gpiccoli> hahaha no need to be sorry, you were quite helpful sil2100, appreciate a lot!
<gpiccoli> Tnx dannf also for letting me release my stuff before the layout work!
<jamespage> Laney: afternoon
<jamespage> Laney: I have a new upload of vaultlocker in bionic-backports/unapproved to fixup an SRU related issue
<jamespage> any chance that could be accepted? i got the bug reporter to validate the package backport via PPA as well
<Laney> jamespage: yup
<jamespage> Laney: ta
<sahid> coreycb: o/ python-ironic-lib needs a version bump of python3-zeroconf, could you clone the repo?
<jamespage> sahid: yep
<jamespage> although I'm not coreycb maybe he's already doing it :)
<sahid> :)
<sahid> jamespage, coreycb: it's python-zeroconf
<coreycb> sahid: that's pushed now
<sahid> thank you
<ahasenack> if I use sudo in a dep8 script, do I need to set the requirement root-required? I didn't want to run the test as root, though, it's just one setup command that has to
<joelkraehemann> hi all
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer
<joelkraehemann> ^^ do I need to fill a sync-request?
<cjwatson> joelkraehemann: Not as far as I can see.  Why do you think you might need to file one?
<cjwatson> (Maybe explain what problem you're trying to solve)
<joelkraehemann> version 3.0.3 is still proposed after 3 weeks
<joelkraehemann> ... version 3.0.0 introduced additional packages providing GObject-Introspection
<joelkraehemann> cjwatson: do you think it is going to focal?
<cjwatson> joelkraehemann: It's blocked due to test regressions.  See https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<cjwatson> (I know nothing more than that)
<joelkraehemann> But I do ...
<cjwatson> Sync requests are for copying source packages from Debian to focal-proposed; they would achieve nothing here
<joelkraehemann> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/g/gsequencer/20200118_155728_62a6c@/log.gz
<joelkraehemann> ^^ the test-bed provided wrong configure flags, I think
<joelkraehemann> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/g/gsequencer/20200116_193425_57c30@/log.gz
<joelkraehemann> ^^ the same here
<cjwatson> Configure flags are up to the package, not the testbed, I'm pretty sure
<cjwatson> The testbed doesn't concern itself with that sort of detail
<joelkraehemann> https://ci.debian.net/packages/g/gsequencer/
<joelkraehemann> cjwatson: I am thinking debhelper flags passed to autopkgtest
<joelkraehemann> ^^ of
<cjwatson> That's not very plausible
<cjwatson> I'm pretty certain that's not a thing
<cjwatson> I'd suggest diffing test logs to try to narrow things down, perhaps
<joelkraehemann> configure: WARNING: unrecognized options: --disable-maintainer-mode
<joelkraehemann> xvfb-run: error: Xvfb failed to start
<joelkraehemann> you are right, xvfb-run failed ...
<joelkraehemann> can you trigger autopkgtest to run again?
<cjwatson> xvfb-run is implicated in the ags-integration-functional-test failure (which is labelled "FLAKY"), but that doesn't explain the ags-integration-unit-test failure
<cjwatson> Have you investigated that part of the log at all?
<joelkraehemann> ags-integration-unit-test FAIL timed out
<joelkraehemann> ^^ this is not flaky
<joelkraehemann> there are 2 different tests
<cjwatson> I didn't say it was flaky :)
<cjwatson> I said that ags-integration-functional-test is the one that's flaky and is the one where xvfb-run failed.  Do you have an explanation for the ags-integration-unit-test failure?
<joelkraehemann> booth tests relay on xvfb-run
<joelkraehemann> ags-integration-unit-test FAIL timed out
<joelkraehemann> ^^ the build host didn't have enough computing power ...
<joelkraehemann> you are right we should update to latest version
<cjwatson> http://autopkgtest.ubuntu.com/packages/g/gsequencer/focal/arm64 shows a failure only 20 minutes ago
<cjwatson> So I'm reluctant to just bang retry on it
<joelkraehemann> ok
<joelkraehemann> it is fixed as of latest upstream
<joelkraehemann> ... it is really a unit-test problem
<cjwatson> But honestly I'm just giving pointers here, this is mostly not a thing I work with very much
<joelkraehemann> I have investigated the issue, the unit-tests timeout because the build host doesn't provide enough CPU power while doing realtime threads ...
<Darkchaos> doko: I'd love to fix two issues for openjdk-lts. One seems to be rather complicated but the other one is just a symlink to src.zip, which seems to be important, because IDEs rely on that to have javadoc for system classes.
<Darkchaos> Could you guide me through the process/have a look at these? (There also is 1826455) which can be marked as solved by now
<Darkchaos> okay, judging by https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/commit/?h=openjdk-11&id=3c36564cf4e6f17e1418332d4b977c8bad69cfa0 the symlink issues are already resolved, so we'd just need to close those two bugs
#ubuntu-devel 2020-02-04
<sahid> jamespage: o/ can I ask you to take care of this: https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/python-zeroconf/+git/python-zeroconf ?
<jamespage> sahid: looking now
<sahid> ack
<jamespage> sahid: done thankyou
<xnox> jamespage:  so v14 ceph is not happy with boost1.71, but v15 on paper will work fine. Whist v15 tags exist on github it's not out yet.
<jamespage> xnox: no its not
<xnox> v15.1.0 -> is that like an RC?
<jamespage> its a snapshot
<jamespage> kinda a point in time for upstream dev to measure things against only
<xnox> ok. when will it be out? / what is focal target version?
<xnox> cause should i revert ceph to build against boost1.67  + wait for next ceph, or like should I be cherrypicking patches to make ceph compatible with boost1.71.....
<xnox> note that boost-context & boost-coroutine is now available on s390x which might be of interest for ceph/s390x
<jamespage> kinda - we don't use the beast frontend for the radosgw so its not directly relevant
<jamespage> xnox: start of march is release date target
<jamespage> we could bump in 15.1.0 in preparation for that
<jamespage> yep - I'll do that makes freeze for ubuntu easier...
<Darkchaos> Any particular reasion, why #ubuntu-beginners-dev is now invite only?
<cpaelzer> rbasak: doko: I'm wondering about paths for cpython .so files - I'd need someone to tell me if this is ok
<cpaelzer> It has a buch of files all following the same pattern, just one as example
<cpaelzer> New upstream installs it already at: /usr/lib/python3.7/dist-packages/libvirtmod_lxc.cpython-37m-x86_64-linux-gnu.so
<cpaelzer> Files were formerly at: /usr/lib/python3/dist-packages/libvirtmod.cpython-37m-x86_64-linux-gnu.so
<cpaelzer> is the new path that it has right after build ok?
<cpaelzer> or do I have to mess around with it to get paths liek we had it in the past?
<doko> we don't use /usr/lib/python3.X
<doko> doesn't dh-python move files around?
<cpaelzer> I had another issue on build when handling dh_install
<cpaelzer> maybe dh_python would move it around later
<doko> yes, it's called after dh_install
<cpaelzer> ah ok, then I can recheck paths afer the other issue is out of the way
<cpaelzer> .install files had usr/lib/python3.? which didn't install anything on the old package either, but now the "fail to find" seem fatal
<cpaelzer> does that ring a bell doko?
<doko> hmm, no. I saw some .install files which hard-coded 3.7
<cpaelzer> I have removed it, now dh_install is happy and indeed (as you suggested) dh_python moved things around correctly
<cpaelzer> the list of files in the final .deb matches the old .deb
<cpaelzer> so I guess I'm good here
<cpaelzer> thanks doko for the hing of dh_python being after dh:install
<doko> sounds ok
<doko> when I close the lid, (supposed to suspend), and then re-open, nothing happens. and I have to force a power-off and restart (Carbon X1, current focal). Any idea which information to provide for a bug report?
<doko> xnox, apw: ^^^
<doko> xnox: this is the oem kernel, as suggested
<apw> doko, file a bug against linux-oem or -osp1 depending which it is, and the hwe peeps can have a look
<tjaalton> should be the same with master kernel
<tjaalton> there's no diff
<tjaalton> besides the fact that oem needs to rebase against -12
<apw> oh focal, ok then against linux and let us know the number
<doko> apw: LP: #1861837
<ubottu> Launchpad bug 1861837 in linux-oem (Ubuntu) "machine doesn't come up after suspend and re-opening the lid" [Undecided,New] https://launchpad.net/bugs/1861837
<tjaalton> doko: try latest master kernel
<tjaalton> I mean generic, distro kernel
<xnox> apw:  tjaalton: why use linux-5.4 when linux-oem-5.4 is available?
<tjaalton> xnox: it should be identical at this point
<apw> xnox, because oem-5.4 is a higher risk proposition (in principle)
<tjaalton> but isn't,
<xnox> ok
<tjaalton> because needs a rebase with the current master
<xnox> apw:  linux-oem-5.4 worked better for doko, than linux-5.4 =)
<tjaalton> then oem will regress very soon
<apw> xnox, that doens't change its risk envelope
<xnox> ack
<doko> apw, tjaalton: anyway, same behaviour
<apw> doko, if you could grab the info the bug is asking for that has the actual full hardware thing in it, we must have one of those -- i assume they have been enabled
<tjaalton> there are several generations of X1c
<tjaalton> we're at gen7 now I think
<apw> tjaalton, right, I asusme the apport info will tell us which of them it is, and whether we have one
<doko> apport-collect failed: module 'cgi' has no attribute 'parse_qs'
<apw> doko, :) it is going to be a long day
<juliank> To be fair, as mentioned before kernel 5.4 has completely buggy intel graphic support and will lock up your machine
<juliank> well any Intel graphic
<tjaalton> works here
<juliank> tjaalton: There's a massive issue, there are reports it got better in 5.5, but no fix for 5.4 yet
<juliank> It's tracked in https://gitlab.freedesktop.org/drm/intel/issues/673
<juliank> It only shows if there's quite a bit of activity on the screen
<juliank> I feel like 5.4-12 got slightly better than 5.4-9, but might be placebo
<juliank> Also, you can get a lot more hangs if you switch mesa driver from i915 to iris, it seems to trigger it more often
<juliank> Basically play video in Chrome, or have spotify snap running in foreground can trigger it because it seems to render a lot
<tjaalton> that was filed with 5.3
<tjaalton> and I've used chrome to watch the australian open (eurosportplayer.com), because firefox leaks memory. no hangs
<juliank> I can tell you that it hangs to 2-3 times a day last time I used it normally
<juliank> Requiring reboots
<tjaalton> then it should be bisectable?
<juliank> My bug report was closed as a duplicate of that one
<tjaalton> -13 had a backported patch for this
<tjaalton> which was sent to stable over a month ago but never applied
<juliank> -13?
<tjaalton> 5.4.0-13
<tjaalton> dunno if it's still in proposed
<juliank> 5.4.0-12 was the latest I saw
<tjaalton> kerneltoast is testing it as well, dunno how it's going
<juliank> tjaalton: Well, it's good to know people are aware of it, last time I asked nobody bothered replying
<tjaalton> I didn't notice it before late last week when it was assigned to me
<juliank> Wondering why I can't find 5.4.0-12 in launchpad publishing history or the git repo
<juliank> this is dod
<juliank> *odd
<ricotz> the last exiv2 0.27.2-8ubuntu1 upload dropped a CVE patch
<tjaalton> the tag is there
<tjaalton> it's just a rebuild for new binutils
<tjaalton> -13 has actual meat
<juliank> Am I looking at the wrong git repo? https://kernel.ubuntu.com/git/ubuntu/ubuntu-focal.git/
<tjaalton> I think that's a mirror?
<tjaalton> git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal
<seb128> ricotz, LocustusOfBorg isn't only atm but I was planning to point that out to him indeed
<juliank> tjaalton: ack
<tjaalton> and some browseable url somewhere
<juliank> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal
<tjaalton> ah
<juliank> just s/git:/http:/ :D
<tjaalton> right
<ricotz> seb128, thanks
<seb128> ricotz, np!
<juliank> tjaalton: Hah, I was asking about this in #kernel on Jan 21, should have just reported a bug but wanted to avoid pointless work if it's already been reported.
<juliank> tjaalton: Should have just reported directly then, or days earlier when it happened first time
<juliank> tjaalton: I reported it to Intel on Jan 11, Jan 21 is when they marked it as a duplicate (https://gitlab.freedesktop.org/drm/intel/issues/963)
<tjaalton> some say it was caused by the cve fixes
<tjaalton> which is why 5.3 would be affected as it seems to be for some
<juliank> People say it was introduced in 5.3.11
<juliank> and I'm on 5.3.9 atm
<tjaalton> so there are possibly two separate issues
<juliank> I should pick 5.3 from eoan instead of using the last one that was in focal
<juliank> or pick the 5.4 testing kernel
<tjaalton> 5.3.11 is where the cve fixes were included
<juliank> ah, ok
<tjaalton> compare eoan 5.3.0-24 and a later one, 5.3.11 was merged in -25
<tjaalton> I've asked the same on bug 1861294
<ubottu> bug 1861294 in linux (Ubuntu) "Gpu watchdog segfault and video+kbd+mouse freeze on optiplex 7060 intel gpu" [Undecided,Incomplete] https://launchpad.net/bugs/1861294
<cpaelzer> component mismatch proposed seems to update slower than usual - we are still on "Generated: Mon Feb 3 21:12:29 GMT 2020"
<cpaelzer> that is like 17h ago
<cpaelzer> is there anything ongoing that would stall this and/or does anything need to be restarted?
<cpaelzer> I hit all refresh buttons I had on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html - please don't tell me it is some cache that doesn't want to go away
<gaughen> Wimpress, juliank helped me get to the bottom of my upgrade issues - seems I'm stuck until libgl1-mesa-dri lands in focal
<juliank> tjaalton: sil2100 ^
<juliank> libgl1-mesa-dri now have higher versions in bionic-updates than in focal release, breaking upgrades
<sil2100> Ah, yeah, lovely
<sil2100> The new mesa is stuck in focal-proposed right now
<sil2100> Ok, and the openscad/s390x autopkgtest seems to fail always on every new mesa we had in -proposed
<sil2100> tjaalton: ^
<juliank> sil2100: also seems to depend on libglvnd, which is valid candidate
<juliank> probably something in update_output to look at
<Laney> It's a regression, I've been asking for investigation for a while now
<Laney> Timo said he had some trouble accessing an s390x machine
<sil2100> Yeah, looks like a regression
<Laney> Which I'm sure is a problem we can solve
<rbasak> cjwatson, wgrant: FYI, I've reopened the bug on removing python-tickcount entirely from the archive here: bug 1740160
<ubottu> bug 1740160 in tickcount (Ubuntu) "Please consider removing tickcount from Ubuntu" [Undecided,Triaged] https://launchpad.net/bugs/1740160
<juliank> Laney: It might be worth it to pull it, and replace it with another 1.9.2.8 for now, if this is going to take some time
<Laney> Probably sane
<Laney> Unless there are shlibs considerations
<cjwatson> rbasak: LP no longer uses it, so as you wish
<rbasak> Thanks!
<juliank> Laney: Nothing has Depends: mesa in britney excuses, so I guess should be good?
<juliank> Or we declare openscad/s390x as too boring to fix
<juliank> Who's running 3D CAD software on s390x anyway?
<Laney> It's clearly a regression in the new mesa, so I have been asking for some minimal investigation to determine whether we should care or not
<Laney> I'm not personally willing to hint it based on 's390x, nobody cares' alone
<juliank> Laney: I do have uploaded a fix for ubuntu-release-upgrader to not get into such situations anymore, and not upgrade instead, so it should not happen to anyone else anymore
<juliank> They'll just will be told they can't upgrade to focal yet
<Laney> cool
<Laney> I feel like an sru-release fix would be nice too
<juliank> I also feel like this should be part of SRU releasing checks, yes
<juliank> But some stuff gets SRUed first and then copied up, so does not always work
<Laney> yeah, I guess you'd need to be able to override it, but that's fine
<Darkchaos> Is there a specific policy/requirement to strip the versym/verneed tables from elf headers?
<Darkchaos> or put differently: Is this even "legal"? It seems in comparison to other binary distributions ubuntu has stripped quite a few tables (symtab), but the deletion of versym makes ld/glibc fail at an assertion, which is what I try to solve
<kerneltoast> tjaalton: i haven't had any gpu hangs with the 5.4 kernel you built
<kerneltoast> It's been a few days and i ran chromium+youtube for hours
<juliank> nice
<tjaalton> sil2100: all the more reason to badtest openscad/s390x for now :/
<tjaalton> kerneltoast: good to hear
<kerneltoast> tjaalton: people on the bug i filed are still complaining of hangs though o_O
<tjaalton> kerneltoast: probably not the same bug then
<joelkraehemann> hi all
<joelkraehemann> https://launchpadlibrarian.net/463439921/buildlog_ubuntu-focal-amd64.gsequencer_3.0.13-1_BUILDING.txt.gz
<joelkraehemann> howto fix this?
<joelkraehemann> E: Unable to correct problems, you have held broken packages.
<sarnold> joelkraehemann: I saw a similar problem debugged yesterday with the advice to create a bare build chroot and try installing the build dependncies one at a time until you find why they aren't installable
<joelkraehemann> just tried to search the packages on https://packages.ubuntu.com
<joelkraehemann> I get: Internal Server Error
<RikMills> Laney: openscad s390x test fails. I got the number of failing tests down from 839 to 14 at build time by extending this patch to cover s390x
<RikMills> vorlon: openscad s390x test fails. I got the number of failing tests down from 839 to 14 at build time by extending this patch to s390x
<RikMills> maybe that gives a clue
<RikMills> sorry, this patch https://salsa.debian.org/knielsen-guest/openscad/blob/master/debian/patches/Work-around-Mesa-llvmpipe-bug-on-MIPS-which-causes-crashe.patch
 * RikMills glares at copy/paste fail
 * sladen was just using openscad ... but not on s390x...
<tjaalton> Laney: build-logs with tests enabled show that s390x fails the same way as sparc64, both are big-endian, and the failures seem to point to this merge-request https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1899
<tjaalton> which can't be reverted
<tjaalton> I've poked anholt about it
<seb128> tumbleweed, thanks for the meson build fix! I meant to look at that bug kept being delayed by other things
<seb128> tumbleweed, did you plan to submit the patch upstream?
<tumbleweed> seb128: nope, but it should be forwardable
<mwhudson> blargh why is git tag -s not working on focal
<mwhudson> oh wait Author: Michael Hudson-Doyle <Michael Hudson-Doyle michael.hudson@ubuntu.com>
<tjaalton> RikMills: looks like the current version in the archive has the same 14 failures
<tjaalton> so wonder if the workaround itself helps any
<RikMills> tjaalton: when tested against mesa in release pocket, yes. against mesa in proposed, it failed 859 tests
<RikMills> also failed 836 tests when it build in proposed pocket
<RikMills> but yes, workaround seems likely it would at best give parity at ~14 fails.
<tjaalton> right
#ubuntu-devel 2020-02-05
<sahid> jamespage, coreycb, o/ anychance you provide repo for sqlalchemy-utils, cinder is needing the version 0.31.1?
<seb128> vorlon, should http://autopkgtest.ubuntu.com/packages/b/budgie-desktop/focal/i386 be flagged as badtest?
<RikMills> tjaalton: ran test against PPA package with all-proposed, and yes that workaround did reduce autotest fails from ~800 to 14
<RikMills> still meh though :(
<tjaalton> yep
<tjaalton> the bad mesa commit is found, but no fix yet
<RikMills> tjaalton: this? https://gitlab.freedesktop.org/mesa/mesa/issues/2472
<tjaalton> yep
<cpaelzer> jamespage: you said you expected masakari could pass without the need for security review
<cpaelzer> jamespage: but from my look at it while generally ok and well hadnled I think it needs one
<cpaelzer> jamespage: https://git.launchpad.net/~paelzer/+git/MIR/tree/MIR-1815991-masakari-and-masakari-monitors.txt#n37
<cpaelzer> would you mind explaining why you tinhk it would not need one before I post my answer to the MIR bug?
<jamespage> cpaelzer: mainly because it's patterned to every other openstack service in terms of API
<jamespage> that might make it an easy MIR review for the security team
<cpaelzer> yeah I agree that is will most likely be a very fast check as it follows the same patterns that were reviewed plenty of times already
<cpaelzer> but to have the checker tools run once to be sure I'd still mark it as needs-security now
<jamespage> ack - no problem with that approach :)
<cpaelzer> thanks jamespage
<cpaelzer> jamespage: wit hthat MIR review done, you might satrt to bother seucrity team to get it done in time
<cpaelzer> oO characters shift around again :-/
<jamespage> I'll ping joe
<Laney> tjaalton: ok, so if we hint it, can you track that it gets fixed for the release?
<tjaalton> Laney: this one yes, but bisecting mesa test failures on sparc I've noticed that there's always a bunch of big-endian-looking things that have failed at least since 19.0
<tjaalton> going further back results in build issues
<tjaalton> so I'm just assuming that these tests at least have always been broken on big-endian
<jamespage> sahid: doing that noe
<jamespage> sahid: er - python-sqlalchemy-utils
<jamespage> already exists lp:~ubuntu-server-dev/ubuntu/+source/python-sqlalchemy-utils
<jamespage> seems to be up-to-date
<jamespage> in distro as well
<juliank> Laney: Are we hopeful that mesa will migrate with the hint in place? It depends on libglvnd which is stuck in Valid Candidate phase
<juliank> And I can't read update_output.txt to figure out why it's in there, rather than migrating
<sahid> jamespage: thanks for the nova merge
<sahid> jamespage: hum... sorry about sqlachemy-utils, let me double check
<Laney> juliank: Not sure, I didn't look beyond mesa itself atm, let's see
<Laney> Looks like it may have something to do with qt / autopilot somehow
<sahid> jamespage: ok thanks we still need to bump th version to 0.31.1 I'm doing that and will ping you shortly
<Laney> actually it should work: https://paste.ubuntu.com/p/4p4pgV3F2j/
<Laney> if it doesn't find that hint by itself we can add it manually
<doko> if it's autopilot, then it's the qt4 removal
<jamespage> sahid: er its already 0.36.0
<juliank> Laney: ack
<sahid> jamespage: we want 0.36.*1*
<juliank> tjaalton: I'm on proposed kernel now, I did not see it earlier because I was looking at linux source package, and it is in linux-5.4 now
<juliank> Should probably remove linux source package from focal?
<juliank> Anyway happy to be on 5.4 again
<juliank> Being able to go to 95Â°C instead of 80Â°C makes stuff compile faster :)
<tjaalton> juliank: ah
<tjaalton> Laney: did libglvnd move as well?
<tjaalton> I assume it did
<juliank> Now I just need to get a usable s-tui again
<juliank> It started showing information per core, when previously it showed aggregate info
<juliank> It's basically useless now
<guysoft42>  hey all, I am the creator of CustomPiOS, which lets you build custom distros using a base image. I can see the raspberrypi image of ubuntu is creating the ubuntu user and password on boot, with the password expried. And I want to change that. However, I get: chage: user 'ubuntu' does not exist in /etc/passwd . How do I find someone who knows how this works and how to edit settings for the ubuntu user before creation?
<seb128> tjaalton, looks like libglvnd did migrate as well yes
<guysoft42> Also it seems like #ubuntu-arm is not responding. And I am not sure who to even ask about this
<tjaalton> seb128: right, it was synced so I didn't get an email about it
<juliank> guysoft42: lookup cloud-init
<juliank> guysoft42: The user is configured on images at first boot by cloud-init, also sets up mirrors and stuff
<sahid> jamespage, coreycb, when you have a moment to look at https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/python-sqlalchemy-utils/+git/python-sqlalchemy-utils
<cpaelzer> hiho, yesterday I asked why https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html is updating to slow (seems only at 9pm GMT once a day)
<cpaelzer> today I realized the report closes with "Over time" - not sure, it might indicate a timeut of some sort?
<guysoft42> juliank, Ok let me have a look, I added wpa-supplicant to my builds so didn't take a long glance there.
<cjwatson> "Over time" there refers to a graph of activity over time and does not refer to a timeout
<coreycb> sahid: seems like something changed in focal so gbp is failing for sqlalchemy-utils
<sahid> coreycb: what is the error?
<sahid> https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/focal-ussuri/+build/18661474
<coreycb> sahid: may just be me fiddling with python3 on my machine
<sahid> coreycb: can i help in any ways or i just have to wait?
<coreycb> sahid: it's all good, I've uploaded that. thanks.
<sahid> coreycb: great thanks, i think after that we will be good for cinder
<coreycb> sahid: can you take a look at openstacksdk? it failed to build.
<coreycb> sahid: great :)
<sahid> coreycb: is that related to a timeout?
<sahid> i had that when i was testing the buld in my PPA, i just pushed retry
<coreycb> sahid: yes
<sahid> coreycb: is that possible for you to make a retry?
<coreycb> sahid: seems to be a test failure - https://launchpadlibrarian.net/463528237/buildlog_ubuntu-focal-amd64.python-openstacksdk_0.39.0-0ubuntu1_BUILDING.txt.gz
<sahid> coreycb: yes, as mentioned i had similar issue - https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/focal-ussuri/+build/18623945
<sahid> coreycb: i still could disable the test
<Laney> tjaalton: yeh, looks like one required the other or something
<Laney> auto hinter figured it out
<coreycb> sahid: if it's an intermittent failure, we should get a bug open upstream with some details and we could skip it, or if time permits fix it and submit upstream
<sahid> coreycb: yes we could probbly open a bug upstream saying that the test is not passing on "slow" machines - i imagine upstream is running those tests each time a patch is submitted
<coreycb> sahid: let me retry it again. the one failure is a timeout but the other isn't so maybe the 2nd is a timeout in disguise.
<sahid> coreycb: sure that makes sense, please keep me posted
<guysoft42> juliank, ok got it, under /boot/firmware/user-data there is a cloud config file with the line chpasswd expire: true. Thanks!
<seb128> bdmurray, hey, https://launchpad.net/ubuntu/+source/automake-1.16/1:1.16.1-4ubuntu4 seems to be a wrong statement, see most recent log on http://autopkgtest.ubuntu.com/packages/a/automake-1.16/focal/armhf (and the one for ubuntu4)
<seb128> bdmurray, I'm reverting that change for now because the tests depend on 'python' and now fail due to that which I want to get fixed in focal
<juliank> Ugh I forgot to dump GPU state
<joelkraehemann> hi all
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer/3.0.13-1/+build/18653318
<joelkraehemann> ^^ could someone trigger a rebuild?
<cjwatson> joelkraehemann: done
<Laney> bdmurray: can you point me to the scripts that generate http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html etc please?
<vorlon> seb128: budgie-desktop> yes, hinted now
<seb128> vorlon, thx
<Laney> I'm in lp:ubuntu-reports but it doesn't appear to be any of those
<joelkraehemann> cjwatson: thank you
<smoser> cpaelzer: tych0 asks is there a ppa for newer qemus somewhere?
<smoser> hallyn: interested also ^
<hallyn> true story
 * hallyn awaits the reasonable "do it yourself" answer
<ahasenack> smoser: focal-proposed just got 4.2: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu
<ahasenack> well,almost :)
<smoser> ahasenack: thanks.
<smoser> oh... and the cloud archive too for older releases.
<ricotz> not so funny when running "requestsync" results in this https://paste.debian.net/plain/1129296
<Darkchaos> So building the same package on debian buster produces correct binaries where on Ubuntu (bionic, but also using disco with pbuilder), I get missing elf header parts. The code should be the same
<Darkchaos> can someone guide me there?
<tkamppeter> Any known problem with the buildds for ppv64el? I have uploaded/synced Ghostscript and it seems so slow that the build does not finish in 150 minutes: https://launchpad.net/ubuntu/+source/ghostscript/9.50~dfsg-5/+build/18661407
<tkamppeter> On my laptop it builds in 150 seconds ...
<cjwatson> Wouldn't it be more likely to be something to do with the architecture than something to do with the builders?
<cjwatson> Assuming your laptop isn't ppc64el, anyway :)
<cjwatson> Other packages seem to be building fine on ppc64el, in reasonable time
<blackboxsw> I
<blackboxsw> I'm seeing very sluggish ppa build queues for any architecture except powerpc as well for smallish projects.
<blackboxsw> ppa package build pages saying "in 2 hours (estimated)" for most platforms, i386 and amd64 a bit sooner, but those builds haven't happened yet. So I'm guessing the package build host machines are over subscribed at the moment
<cjwatson> blackboxsw: That'll be unrelated to tkamppeter's issue
<cjwatson> Only the arm* queues are particularly long at the moment
 * blackboxsw misread ppcv64el and build delay question and jumped on a band wagon :). thx cjwatson righto.
<blackboxsw> BTW cjwatson for my own info. is there a public site for viewing ppa build queues, or is that internal?
<cjwatson> https://launchpad.net/builders/
<cjwatson> Much better overview than looking at the (often terrible) estimates on a particular build page
<blackboxsw> excellent. that helps a lot thanks cjwatson
<blackboxsw> coincidental to this discussion all my current ppa builder jobs just dropped from 2 hrs estimate to to about 30 mins. confirming that build estimates on the PPA build pages are 'wild'
<tkamppeter> cjwatson, are there ppc64el laptops? Or is that a server-only architecture like s390x?
<cjwatson> I don't know of any
<cjwatson> Which is not to say there aren't
<cjwatson> blackboxsw: Well, I did do a few quick repairs in passing
<blackboxsw> repair: if user == blackboxsw: "make his builders happy"
<blackboxsw> heh
<tkamppeter> cjwatson, the strange thing of my isue is that there are some files compiled, without any errors or warnings and then suddenly the kill-after-15-min happens.
<cjwatson> tkamppeter: OK ... but it doesn't look like an infrastructure problem at present
<cjwatson> It looks more like the compiler just taking forever on a particular translation unit
<tkamppeter> cjwatson, would this mean that the compiler has a bug?
<cjwatson> Since as I say other packages are building fine on ppc64el, so it doesn't look like slow builders in general
<cjwatson> Well, only if my guess is correct
<cjwatson> All I can say is that I don't see an infrastructure problem here
<cjwatson> Have you even tried this more than once as yet?
<cjwatson> Or tried any debugging in a PPA?
<tkamppeter> cjwatson, I only did a retry of the build and got the same result.
<tkamppeter> cjwatson, if a compiler gets stuck (or extremely slow at least) without giving any error message then there must be a bug in the compiler. If there would be something not allowed on ppc64el in the code, there would be an error message.
<cjwatson> Well, I would presume so but I'm not a compiler engineer so I can't make any pronouncements about that
<tkamppeter> Perhaps best to report a bug on gcc then.
<tkamppeter> cjwatson, I reported bug 1862053 now. Thanks anyway.
<ubottu> bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [Undecided,New] https://launchpad.net/bugs/1862053
<cpaelzer> smoser: hallyn: for now either focal-proposed or https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3883/+packages
<cpaelzer> smoser: hallyn: we had https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream but it was absolutely ignored and a waste of time
<cpaelzer> so we abandoned it
<hallyn> haha, yes
<ricotz> LocutusOfBorg, https://bugs.launchpad.net/ubuntu/+source/exiv2/+bug/1715931/comments/12
<ubottu> Launchpad bug 1715931 in exiv2 (Ubuntu Focal) "Update to exiv2 version 0.27" [Wishlist,Fix committed]
#ubuntu-devel 2020-02-06
<xnox> doko:  you re-added python-minieigen can i drop it again? otherwise it ftbfs against the new boost
<cpaelzer> I was finding https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html update slowly the last few days
<cpaelzer> last 24 hours it didn't update at all
<cpaelzer> is anyone aware of details what might be going on ?
<cpaelzer> (I have pinged the last two days but I'm not sure who owns/manages this)
<JackFrost> Urgh, ruby-zip still hasn't migrated..
<cpaelzer> kanashiro: ^^ FYI
<JackFrost> I hit retest on yet another failing test, hopefully it'll work this time.
<JackFrost> Another == it didn't want to re-test with the "new" ruby-roo, so I had to manually kick them all off.
<Aliekezhi> hi, I'm trying to edit gnome css files but it doesn't seem to have any effect. modifying all of .css files /usr/share/gnome-shell/theme$
<Aliekezhi> is there another file used by default on ubuntu ?
<jamespage> xnox: I'm having trouble with boost-context on s390x  - https://launchpadlibrarian.net/463652248/buildlog_ubuntu-focal-s390x.ceph_15.1.0-0ubuntu1~ubuntu20.04.1~ppa202002051350_BUILDING.txt.gz
<jamespage> for the time being I'm going to disable use on s390x to allow your boost transition to proceed
<ogra> waveform, sil2100 the new flash-kernel breaks all my lxd containers on my pi's ... could we add a runtime test if the environment is a container ?
<doko> tkamppeter: th ghostscript sync without the completed MIR makes a lot of packages now ftbfs
<kanashiro> JackFrost, re ruby-zip: did you do any investigation on s390 autopkgtest failure?
<jamespage> hmm is there something up with the launchpad builders? I swear I just saw a load of active builds for a PPA disappear and restart?
<seb128> jamespage, probably more a question for #launchpad, but I saw some weird thing happening to one of my ppa builds as well
<sahid> jamespage, coreycb, cinder is ready https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/cinder/+git/cinder
<ogra> waveform, sil2100 seems FLASH_KERNEL_SKIP also became a no-op now ? (at least exporting it doesnt stop f-k from running here)
<waveform> ogra, which version?
<ogra> waveform, https://paste.ubuntu.com/p/xcG6gQkFnc/
<ogra> thats a freshly pulled bionic container simply running apt update/upgrade
<ogra> (this run with FLASH_KERNEL_SKIP set ... but it doesnt seem to make any difference)
<waveform> ogra, that looks like it can't determine the kernel version (judging by the search paths); FLASH_KERNEL_SKIP *should* still work ... let me check the postinst in the bionic branch
<waveform> ogra, FLASH_KERNEL_SKIP looks like it should still work: https://git.launchpad.net/ubuntu/+source/flash-kernel/tree/debian/flash-kernel.postinst?h=ubuntu/bionic-devel&id=b2fbda45824cfdd2950349979b1cfda52fa86d9d#n48
<ogra> yeah, that seems to be an issue with the way i execute apt in a non-interactive shell ...
<ogra> yet it would still be cool if it simply detected that it runs inside a contrainer ... that will likely also break armhf docker images on upgrade
<xnox> jamespage:  ack and thank you. I will escalate this back to IBM they had students port boost context for ceph specifically, as nothing else important uses it pretty much =)
<tkamppeter> doko, how? Are they using libgs?
<xnox> jamespage:  i wonder if i missbuilt it
<waveform> ogra, wouldn't it be better not to have flash-kernel installed at all? I've just tried firing up a bionic container on a pi to see what "linux-version list" returns (nothing, which explains why flash-kernel's getting confused about its search paths), and I note u-boot isn't installed, /lib/firmware doesn't exist, etc. so it seems a bit odd that flash-kernel is there at all?
<ogra> waveform, well, some seed or taks pulls it in for whatever reason ... i agree it should probably not be there
<ogra> *task
<waveform> ogra, that would seem the preferable course of action here - rather than adding logic for detecting various containers to flash-kernel - especially when we've apparently managed to exclude stuff like u-boot and the linux firmware from the image
<ogra> well, it would protect people that accidentially get it pulled in through a dependency
<ogra> (or explicitly install it but then they should perhaps know about FLASH_KERNEL_SKIP)
<ogra> ... though it might make F_K_S unnecessary completely
<waveform> F_K_S seems to be used by the packaging system too (judging from the comments) so I suspect it has some other uses which would keep it around; I'm sure I recall *some* detection code somewhere already but I can't remember where I saw it
<waveform> still, for now I'm definitely leaning toward ensuring our images simply don't include f-k - it's a cleaner solution
<waveform> oh, the initramfs hooks it installs ... that's where the detection is
<jamespage> xnox: its odd because the unit that fails lists boost_context in the list of things to link with
<jamespage> and I only see this on s390x - other archs that have previously built with boost-context continue todo so
<jamespage> sahid: sorry missed your ping - looking now
<xnox> jamespage:  i do wonder if some included copies of code leaked into the build. cause there is a copy of boost in ceph, and a system one, which are out of sync on s390x now.
<xnox> (only on s390x they are out of sync)
<jamespage> hmm
<xnox> minor for now, will play with it when everything else is more in shape
<jamespage> yah
<tkamppeter> doko, the openjpeg2 MIR finished finally after 9 years, otherwise I had not done the sync, the urw-fonts MIR should go quickly, as it has no executable code, only data.
<tkamppeter> bug 1862048
<ubottu> bug 1862048 in fonts-urw-base35 (Ubuntu) "[MIR] fonts-urw-base35" [Undecided,New] https://launchpad.net/bugs/1862048
<mdeslaur> tjaalton: how do I install the hwe stack on bionic? I tried the instructions here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack but it didn't pull in xorg-server-hwe-18.04...
<mdeslaur> tjaalton: ah, never mind, I fat-fingered it
<tjaalton> :)
<mdeslaur> -ENEEDCOFFEE
<ahasenack> cpaelzer: +1ed https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+merge/378436
<ahasenack> rafaeldtinoco: hi, could you perhaps pick this one up? It's related to the i386 work you did in samba:
<ahasenack>  LP: #1861316 - (New)            [samba]          - ubuntu 20.04: libnss-winbind:386 should remain
<ubottu> Launchpad bug 1861316 in samba (Ubuntu) "ubuntu 20.04: libnss-winbind:386 should remain" [High,Triaged] https://launchpad.net/bugs/1861316
<rafaeldtinoco> ahasenack: I'll get it
<rafaeldtinoco> if its just adding them back it will be easy
<rafaeldtinoco> based on what steve has replied
<ahasenack> yep
<ahasenack> thanks
<RikMills> marcustomlinson: smoketest, test-extension & odk-build-examples fail with badpgk as they depend on the nogui packages, which don't seem to exist on armhf
<marcustomlinson> RikMills: interesting, thanks I'll have a look
<cpaelzer> ahasenack: thanks pushing ndctl change
<cpaelzer> cjwatson: also did fix up the report generation \o/
<cpaelzer> ahasenack: so in a bit we can try to grab an AA and get things moved
<ahasenack> ok
<JackFrost> kanashiro: ZipFileExtractTest#test_extract_incorrect_size was the test failure, wanted to see if it'd fix on re-try.
<tkamppeter> doko, could you help on a gcc problem with ppc64: bug 1862053?
<ubottu> bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [High,New] https://launchpad.net/bugs/1862053
<juliank> tjaalton: OK, got a soft hang with -13 now, while running hangout meet
<juliank> but I mean, hangouts is crazy
<juliank> without iris now, default mesa i915 driver again
<juliank> this is likely a different issue
<tjaalton> check dmesg
<juliank> dmesg just says
<juliank> [10161.268097] i915 0000:00:02.0: GPU HANG: ecode 9:1:0x00000000, hang on rcs0
<juliank> and then two reset messages
<tjaalton> ok
<tjaalton> file a new bug upstream I guess, saying that the fix from the other one is already included
<juliank> yup
<tjaalton> grab /sys/class/drm/card0/error
<juliank> tjaalton: Yes, sure, I did. I'd love to reboot with drm debug, but I don't want to spam my journal with huge kernel logs :/
<juliank> Then I can keep a window with netflix running while working and if it hangs we get a lot of nice debug
<juliank> or a hangout meet, but needs lot of people
<tjaalton> you don't need drm debug, it should always save the error state there
<tjaalton> drm debug only shows what the driver is doing, mostly helpful with modesetting issues
<juliank> intel wants that, though, they say
<tjaalton> for hangs?
<tjaalton> it does say things about the hw though
<juliank> tjaalton: forwarded to https://gitlab.freedesktop.org/drm/intel/issues/1150
<juliank> tjaalton: It's just in their generic bug reporting guidelines
<juliank> aka https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
<juliank> ah it says and/or a crash dump
<juliank> missed the and/or :D
<tjaalton> ok
<tjaalton> juliank: are you able to modify the mimetype of the attachments of your bug? the error state shows as octet-stream and not text/plain
<juliank> hmm
<tjaalton> oh, I have the same laptop :P
<tjaalton> time to upgrade to focal
<juliank> tjaalton: I re-uploaded it as error.txt, but that did not seem to help
<juliank> in any case it downloads
<juliank> other people simply embed ``` the dump, but that's too much text for me to be comfortable embedding
<juliank> but it should respond text/plain now
<tjaalton> probably just a feature of gitlab, I prefer to open them on the browser
<tjaalton> and a regression compared to bugzilla
<juliank> they're stored in storage.googleapis.com
<juliank> But it redirects with response-content-disposition=attachment
<juliank> it could probably redirect with response-content-disposition=inline or something set
<juliank> you can grab it like this:
<juliank> https://storage.googleapis.com/fdo-gitlab-uploads/%40hashed/f3/6e/f36e412aea00d7c622f3d331c5ceec42eaf18bda2d0374971a09fc79d7d9f293/8dfdebf043239f6d2e192c7826638e99/error.txt?response-content-disposition=inline%3B%20filename%3D%22error.txt%22%3B%20filename%2A%3DUTF-8%27%27error.txt&amp;response-content-type=text%2Fplain&amp;GoogleAccessId=GOOGOEXJKVLVDILPMJ5V2WSY&amp;Signature=kuzMpvRKv0nLaTY7
<juliank> Cb8b%2F%2BzYsKc%3D&amp;Expires=1581009795
<juliank> Or you could write a browser extension that rewrites the urls for you
<tjaalton> well, error.txt is at least being opened in an editor, instead of just saving to disk
<juliank> that's good
<tjaalton> but it is what it is :)
<juliank> hmm there's a weird bug in nautilus
<juliank> when you have a video in a directory it has padding at the top of the item grid
<juliank> it's not normally there
<juliank> If you do it with a picture it's at the left
<didrocks> doko: it seems that grub2 is blocked as build-dep on python, should it only bump the build-dep to mention "python2"?
<cjwatson> didrocks: I fixed that to use python3 in Debian some time back
<cjwatson> Like August
<cjwatson> Somebody should merge it
<didrocks> cjwatson: ack, thanks!
<cjwatson> https://salsa.debian.org/grub-team/grub/commit/615a8893413f85c58e59a99948f97ceb9ab5dc16
<didrocks> cjwatson: I was just looking. I think Iâll cherry-pick to unblock the package. Thanks :)
<mitya57> xnox, Trevinho: hi, do you know whether we still need the window-mocker package? It is the last package that depends on python-qt4, which I want to remove.
<mitya57> Its reverse dependencies are python3-autopilot-tests and unity-autopilot and you touched these packages last, that's why I'm asking you.
<Trevinho> mitya57: not that I know
<Trevinho> I suppose we can also get rid of the unity-autopilot one
<mitya57> If you could do a MP that would be nice.
<mitya57> Hmm, I think python3-autopilot-tests should depend on python3-windowmocker instead of python-windowmocker. Its other dependencies are already python3-*.
<mitya57> xnox: ^^^
<mitya57> This way we will be able to drop at least the Python 2 version of window-mocker (and python-qt4).
<ahasenack> hi, the package src:vmem was not being synced from debian because it had binaries conflicting with pmdk <= 1.7. I now updated pmdk in focal, it migrated, and was wondering if I need to sync vmem manually, or if a cron job somehwere will take another shot at it
<ahasenack> OK (Y/n)?  y
<ahasenack>  * Trying to add vmem ...
<ahasenack> vmem_1.8-1 is trying to override modified binary libvmem1_1.7-1ubuntu1.  OK (y/N)?  n
<ahasenack> let me see when that ran
<ahasenack> hm, looks like 3 times a day
<ahasenack> I'll check again tomorrow
<ahasenack> Skuggen: hi, around? Sorry, I don't know your tz
<xnox> mitya57:  ideally i want to drop all of autopilot but i fear it is still used in places - like ubiquity ui tests
<xnox> seb128:  Laney: jibel:  do we still run the autopilot ubiquity tests? any others?
<xnox> mitya57:  and what is python3-windowmocker written in? Imho we should only really need gtk3 python3 portions of autopilot, but i am not sure how to untangle it all
#ubuntu-devel 2020-02-07
<RAOF> Argh! Why don't I get any email for Mir build failures?!
<Skuggen> ahasenack: Hi! (it's early morning here now)
<jibel> xnox, yes we still use autopilot for UI tests of ubiquity
<RAOF> xnox: I've uploaded Mir 1.7.0 with all the build-fixes I know about; assuming ppc64el and s390x aren't more than usually hateful that should build everywhere and be migrateable.
<doko> xnox: dropping python2 stuff is ok, I probably just needed it for the python removal, which likely isn't necessary anymore
<tkamppeter> doko, could you help on a gcc problem with ppc64: bug 1862053?
<ubottu> bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [High,New] https://launchpad.net/bugs/1862053
<doko> tkamppeter: could you attach the preprocessed source of that file, including the command line options to build it?
<tarzeau> i guess that's still valid? https://www.phoronix.com/scan.php?page=news_item&px=No-Wayland-Default-20.04-LTS
<tkamppeter> doko, the command line options to compile it are in the log right before the line telling that the build process got terminated.
<doko> but not the preprocessed source
<tkamppeter> doko, but how does one obtain a pre-processed source?
<doko> tkamppeter: build the file with -save-temps and look for .i or .ii file
<tkamppeter> doko, will try.
<doko> ta
<doko> on ppc64el of course
<tkamppeter> doko, could you not do this step also?
<doko> tkamppeter: I can try, but not my priority for next week
<tkamppeter> doko, OK.
<doko> tkamppeter: but everybody has access to ppc64el boxes
<LocutusOfBorg> doko, python-importlib-metadata syncd, it doesn't FTBFS anymore
<doko> Mario Limonciello here?
<Laney> doko: that is superm1, but not often on IRC - email works better ime
<doko> yep, sent it
<mitya57> xnox: python3-windowmocker uses Qt 4, unfortunately. But at least it's Python 3.
<mitya57> If you could remove autopilot's dependency on any window-mocker, that would be ideal of course.
<doko> jibel: ^^^
<xnox> jibel:  i think ubiquity needs to declare an build-depends on autopilot, such that automated tools don't forget that it is used there!
<cpaelzer> I might need soem foreign/mutliarch help - http://paste.ubuntu.com/p/8DYhgMRstF/
<cpaelzer> I don't see what would be missing, other tests worked that way but here it just says no without further details
<cpaelzer> well - it didn't build i386 binaries - as it isn't in the whitelist I guess https://launchpad.net/ubuntu/+source/strongswan/5.8.2-1ubuntu1
<cpaelzer> but then why doe it trigger the i386 test http://autopkgtest.ubuntu.com/packages/s/strongswan/focal/i386
<cpaelzer> Hmm, I'll file a badtest but I must admit I seem to miss a piece of the i386-puzzle on this one
<xnox> cpaelzer:  we have bugs that things get triggered on i386 when it shouldn't
<xnox> vorlon:  has been managing these; after the first time, britney does finally forget about i386 for them.
<jibel> xnox, it could but autopilot is not really a build-dep of ubiquity.
<cpaelzer> thanks xnox
<cpaelzer> I'll file a force-badtest MP and explain why - if the solution is different than the force-badtest that can be done in response to the MP instead of merging it
<cpaelzer> but knowing that there were some odd cases makes me feel better
<xnox> jibel:  i know, but just to highlight it purely as documentation, even if it's not in fact used.
<RikMills> mitya57 jibel: just drop the qt4 plugin of windowmocker? the changelog and file lists say there is a Qt5 one shipped
<mitya57> +1. I think we should switch python3-autopilot-tests to python3-windowmocker and then drop the Python 2 and Qt 4 parts of window-mocker.
<jibel> xnox, did you upload the changes you did yesterday to the vcs?
<jibel> can someone file a bug against autopilot, i'll have a look next week.
<Laney> now what's happened to seeded-in-ubuntu
<jibel> unless someone want to to it
<xnox> jibel:  for which package? =)
<xnox> jibel:  the previous autopilot upload into the archive was from me in 2017, and it was on top of last CI-train release from march that year
<Laney> ah, we lost tab completion in lp-shell at some point :(
<jibel> xnox, for autopilot
<xnox> jibel:  should we vendorise autopilot in ubiquity?! =)
<ahasenack> rbalint: I wanted to probe your memory of https://git.launchpad.net/~usd-import-team/ubuntu/+source/isc-kea/tree/debian/patches/mysql-8.0
<ahasenack> rbalint: sorry
<ahasenack> rbasak: I wanted to probe your memory of https://git.launchpad.net/~usd-import-team/ubuntu/+source/isc-kea/tree/debian/patches/mysql-8.0
<ahasenack> rbasak: in particular, the "Instead we drop the test" bit of the description, which doesn't seem to be part of the patch
<rbasak> Looking
<doko> bryce: your spammassassin upload still requires python (unversioned) in the autopkg tests
<mitya57> jibel: filed bug 1862344. I tried to fix it myself, but the package FTBFS locally for some reason, so I gave up.
<ubottu> bug 1862344 in autopilot (Ubuntu) "Please switch from python-windowmocker to python3-windowmocker" [Undecided,New] https://launchpad.net/bugs/1862344
<rbasak> ahasenack: I think "the test" was this, or similar: https://gitlab.isc.org/isc-projects/kea/commit/ef559d3c3881dafd527b43ac3fc6e771091d6198#7e2229fde9f8ea99bd48e7fb735236b2ddbd1aec_19_19
<rbasak> ahasenack: by "drop the test", I meant we're altering the commit from upstream
<ahasenack> rbasak: there is a configure check for my_bool, it finds it, because of our workaround in mysql-8 I believe
<ahasenack> but then makes wrong assumptions, thinking it's NOT mysql-8 that it's dealing with
<rbasak> That's sort of correct
<rbasak> This is a mess :(
<ahasenack> rbasak: will we be keeping the workaround for 20.04?
<rbasak> MySQL 8 dropped my_bool
<rbasak> Favouring bool instead
<rbasak> We re-added it because it broke too many reverse deps
<ahasenack> but now they will never be fixed
<ahasenack> well, "never" is a strong word
<rbasak> But upstreams that do version testing, rather than feature testing, are now assuming the wrong thing
<ahasenack> and it's perhaps starting to introduce other sorts of problems, like the one I described
<rbasak> We were hoping it'd be fixed by upstreams building from not-Ubuntu
<rbasak> They all need to be using bools and stop using my_bool
<rbasak> IIRC, we still haven't finished sending all the patches upstream yet
<rbasak> It needs yet more effort to resolve properly, I agree
<rbasak> I'd like to chat about this at our next sprint
<rbasak> The other problem with all of this is that C++ has a specialist implementation of std::vector<bool> that uses bitfields
<rbasak> And when that is done, you can no longer take an address of an element inside the vector
<ahasenack> Skuggen: hi :) That's what my ping from yesterday was about, fyi ^
<rbasak> C++ programs that did this with std::vector<my_bool> break when my_bool is typedeffed to a bool
<ahasenack> yeah, that's the build error I got
<ahasenack> because it detected my_bool
<rbasak> Are you sure?
<ahasenack> ~50%
<ahasenack> this beast takes 30min to build
<ahasenack> and fails with parallel building
<rbasak> One way around it is to put the my_bool in a single-element struct and change all the code to indirect through it.
<ahasenack> damn, I overwrote those logs
<rbasak> That's the only real long term fix for the C++ vector of my_bool pattern for results AFAIK
<ahasenack> I'm going to tell it to not find my_bool
<ahasenack> the code has ifdefs for that already
<ahasenack> and uses <char> in that vector thing, if that makes any sense
<rbasak> I'm not sure that the behaviour is properly defined to use a char instead
<rbasak> But that's what upstream did and it seemed to work
<rbasak> What change has caused this to be an issue again?
<ahasenack> new upstream version, which ironically has the patch you backported above
<rbasak> Ah, I see
<rbasak> So you want to apply just my backport as a patch to it
<ahasenack> and I was looking for the "disabled test"
<ahasenack> your patch is there, just surrounded by ifdefs
<ahasenack> which trigger on my_bool being found, because we still define it
<rbasak> Yeah
<rbasak> So I pulled out the ifdefs
<ahasenack> and gcc picks the wrong ifdef result
<rbasak> If you apply an equivalent patch to the modification I made, the result should be the same
<ddstreet> Laney i'll have seeded-in-ubuntu MP ready shortly, btw
<ahasenack> or, I remove the configure test for my_bool so it doesn't find it, and takes the other path
<ahasenack> assuming correctly it's mysql8
<rbasak> I think that would be more confusing
<Laney> ddstreet: ah ok, I just fixed it too
<rbasak> Because there are two "mysql8"s
<Laney> but you can do it
<rbasak> One with the typedef, and one without
<Laney> why did it just break, do you know?
<rbasak> That's why I did it the other way
<Laney> Looks like it came from a quite old commit
<ahasenack> you mean the real one, and ubuntu's hack
<rbasak> Right
<ddstreet> Laney i rewrote most of ubuntutools
<Laney> or did that only just get merged?
<ahasenack> I'm surprised upstream is ok with us doing that
<rbasak> And the presence or absence of my_bool now gives you an inconclusive result
<ddstreet> yes just merged for focal
<Laney> nod
<rbasak> I patched it that way because I figured that in an Ubuntu-specific patch, the answer is known and no configure test is not required
<rbasak> So it's clearer in a quilt patch to drop the #if directives in the direction that we know to be correct in our case
<rbasak> no configure test is required
<ahasenack> don't we still have time to fix this for 20.04?
<ahasenack> this was in eoan, right?
<ahasenack> cpaelzer: I got a file conflict updating qemu-system-common, on /usr/bin/ivshmem-client, is that known/expected?
<rbasak> We could, if we want to take that work on right now
<rbasak> It is true that users might get upset at us for the patch during the 20.04 lifetime when they try to build things against our MySQL
<ahasenack> rbasak: does debian have that change too?
<cpaelzer> ahasenack: yes it is known and the fix alread yuploaded
<rbasak> Debian doesn't have 8.0 yet
<ahasenack> cpaelzer: ok
<ahasenack> rbasak: so they likely won't have that patch
<rbasak> Also, Debian builds against MariaDB
<ahasenack> ah, right
<rbasak> However this all affects configure scripts only
<rbasak> Since really an upstream project wanting to support a build against MySQL 8.0 should be avoiding use of the my_bool typedef
<cpaelzer> ahasenack: 1862287 if you want to look
<rbasak> Our patch makes the decision making process in the configure script a little more complicated
<ahasenack> rbasak: we all know checking for versions can be brittle, it's always best to check for features
<ahasenack> and my_bool is a "feature"
<rbasak> Unfortunately we introduced "my_bool might be a real bool, rather than an int"
<rbasak> Which it turns out in C++ breaks std::vector
<ahasenack> "do we have my_bool?" "is it mysql8?" "is it ubuntu's mysql8?"
<rbasak> However the point of the typedef is that we should be able to change its definition without breaking the API
<rbasak> So someone wanting to support all three needs to do "do we have my_bool? If so support it being either an int or a bool. If not, use a bool"
<rbasak> Perhaps it would suffice if we (I?) wrote that up somewhere for affected users to find.
<ahasenack> I'd prefer if we didn't have to carry that workaround :)
<Skuggen> Hm, I wonder where I put the work I did related to this (list of upstreams with bugs reported for it, scripts to do reverse-dep builds in the ppa, etc)
<Skuggen> We could do a set of ppa builds with an 8.0 without the patch to see how many still haven't been updated?
<rbasak> Sure - that'd be a good first step
<ahasenack> and how about adding the typedef just to the affected apps, instead of mysql as a whole?
<ahasenack> 1 vs N problem?
<ahasenack> at least we would have a known set of affected apps, and could revisit each one everytime it's updated
<ahasenack> instead of leaving it in mysql and wondering when it could be dropped
<tkamppeter> doko, I am trying to get a ppc64el machine on juju, but it seems to take ages until it is ready.
<ahasenack> tkamppeter: canonistack?
<tkamppeter> ahasenack, yes
<ahasenack> it usually work. I don't use juju for that, though
<tkamppeter> ahasenack, how do you access?
<ahasenack> tkamppeter: let me give you a one liner
<ahasenack> tkamppeter: focal ppc64el?
<tkamppeter> ahasenack, where do I have to enter it?
<ahasenack> tkamppeter: your shell, after having sourced the credentials file for canonistack
<ahasenack> tkamppeter: openstack server create --key-name andreas_canonistack-bos01 --flavor cpu1-ram2-disk20 --image 108d7998-a3a7-44ed-b43d-82c30634f976 focal-ppc64el
<ahasenack> that will give you a focal ppc64 instance with 1 core, 2G of ram, 20G of disk, called focal-ppc64el (visible with "nova list" after the launch)
<ahasenack> tkamppeter: ah, well, details
<ahasenack> the ssh key
<ahasenack> (--key-name)
<ahasenack> do you know how to create one for openstack?
<Laney> dunno, it's taking ages to schedule for me, might actually be a problem there
<ahasenack> could be too
<Laney> I asked the sysadmins if they could take a look
<tkamppeter> ahasenack, no, I do not know how to create that key
<ahasenack> doko: hi, I was replacing python 3.7 with 3.8 in a lxd container to rebuild something with py3.8, and then ran autoremove, but it failed like this: https://pastebin.ubuntu.com/p/KGJNsy8xNm/
<cjwatson> tkamppeter: https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01#Non-Juju
<Laney> TIL about the Juju workflow
<cjwatson> (With ahasenack's adjustments for getting a ppc64el instance specifically)
<doko> Unlinking and removing bytecode for runtime python3.7
<doko> update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/python3.7 for writing: Permission denied
<doko> update-binfmts: warning: unable to disable binary format python3.7
<doko> update-binfmts: exiting due to previous errors
<ahasenack> yep
<doko> a warning, and then exiting with an error? maybe ask the update-binfmts maintainer ;p
<cjwatson> please file a bug?
<cjwatson> I do binfmt-support in my free time
<ahasenack> yeah, was just looking what the src package was
<cjwatson> It would help if python* updated to use --unimport though
<cjwatson> See /usr/share/doc/binfmt-support/README.Debian
<cjwatson> That would make it not be a fatal error here
<ahasenack> I used ubuntu-bug, waiting for launchpad while it does the refresh every 10s thingy
<ahasenack> ok, almost there
<ahasenack> cjwatson: doko https://bugs.launchpad.net/ubuntu/+source/binfmt-support/+bug/1862347
<ahasenack> thx
<ubottu> Launchpad bug 1862347 in binfmt-support (Ubuntu) "apparmor error while removing python3.7 in lxd" [Undecided,New]
<cjwatson> thanks
<tkamppeter> ahasenack, I succeeded creating this server now, at openstack they are much faster going to the attic, getting an old ppc64el server, undusting it, putting it into a rack, installing focal, and then assigning it to me than at juju.
<tkamppeter> ahasenack, now I need somehow to SSH into it.
<ahasenack> you didn't create an ssh key before?
<tkamppeter> Yes, I created it now with the commands on  https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01#Non-Juju
<tkamppeter> Without I was not able to create the server.
<tkamppeter> Now I have the server and it is "active".
<ahasenack> rbasak: cpaelzer: hah, similar case to ethtool iirc: #1862302
<ahasenack> new hwe kernel requires new userland tools
<Skuggen> ahasenack: Yeah, we added it to MySQL because there were quite a few reverse-deps that needed it
<tkamppeter> ahasenack, I succeeded now, folloeing all the instructions.
<ahasenack> nice
<tkamppeter> ahasenack, thank you very much.
<ahasenack> good luck in your debugging :)
<tkamppeter> doko, I succeeded to generate this pre-processed file. It is attached to bug 1862053 now.
<ubottu> bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [High,New] https://launchpad.net/bugs/1862053
<tkamppeter> Also the manual initiation of the package build on the ppc64el server hung at the same point and the command line for the pre-processing also, but the hang seems after the pre-processing, as the *.i file looks complete.
<ahasenack> rbasak: +1 to add to the whitelist? https://paste.ubuntu.com/p/nwnqwx3ctj/
<ahasenack> oh, one more, vmvm
<ahasenack> 1s
<ahasenack> rbasak: https://paste.ubuntu.com/p/KYcM5ZQwYs/
<rbasak> ahasenack: +1
<ahasenack> rhx
<ahasenack> rbasak: I'll import them manually next, ok?
<rbasak> Sure
<rbasak> In a screen please
<rbasak> (just so others can find it if it errors, etc)
<ahasenack> sure
<ahasenack> rbasak: ok, all 3 imported
<juliank> tjaalton: to reduce the risk of forgetting: 2nd hang fix just pushed by Chris Wilson in https://gitlab.freedesktop.org/drm/intel/issues/1164 -
<juliank> Funnily he closed my 1150 as duplicate of 1164, not sure why, but as long as it's getting fixed, I can't complain ...
#ubuntu-devel 2020-02-08
<bdmurray> sarnold: quite the prolific bug reporter you are
 * sarnold bows
<bdmurray> that would be a lot of champagne
<sarnold> bdmurray: I've got some small fixes for the ubuntu-qa-tools/responses/security/ directory for python3 in focal.. do you want to see those before I check them in?
<bdmurray> sarnold: I trust you man
<sarnold> bdmurray: cool, thanks
<tjaalton> juliank: oh, good to hear
<RikMills> doko: I have 80 KDE frameworks source packages built and ready to upload later today. I see you are doing rebuild for binutils. I hope is is ok if I don't sync your changelog and remake my sources?
<doko> RikMills: sure, just ignore
<RikMills> doko: thanks
<RikMills> uploaded, in slight hope that might cut down the amount of triggered tests
<RikMills> that is anything ever builds on x86. the builders look quite broken
<doko> yes, just reported it
<LocutusOfBorg> mitya57, hello, qtwebengine-opensource-src sync/merge? (CVE fixes)
<mitya57> LocutusOfBorg: feel free to merge it
<mitya57> It won't help much anyway, as Chromium gets new CVEs every month (or even week).
<RikMills> lol
<Eickmeyer[m]> Eeeeeew.... why is ubuntu-manual-tests still using bzr and not migrated to git?? ð©
<LocutusOfBorg> mitya57, can you please commit a patch to the debian packaging so we drop the delta?
<mitya57> LocutusOfBorg: this change was never needed in Debian, and I do not want to make builds there slower.
<mitya57> (In Ubuntu with the patch it can take more than a day.)
<LocutusOfBorg> mitya57, I'm sending you a patch that enables it only in Ubuntu bulds
<mitya57> Ah, I didn't think about that. Ok, will apply.
<LocutusOfBorg> one sec and I'll give it you :)
<LocutusOfBorg> dpkg-source is slooooooooooow
<mitya57> No dpkg-source, webengine code is huuuuuuuuuuuuge :)
<LocutusOfBorg> :)
<LocutusOfBorg> mitya57, http://launchpadlibrarian.net/464141806/qtwebengine-opensource-src_5.12.5+dfsg-6_5.12.5+dfsg-6ubuntu1.diff.gz
<LocutusOfBorg> it might be a good patch
<mitya57> Thanks
<mitya57> I'm not sure upstream code doesn't rely on /usr/bin/python, though.
<Darkchaos> I can't easily override pbuilder's binutils version, I guess? Specifically using a version that ubuntu never had as .deb makes things problematic as I need to build them manually, I guess?
#ubuntu-devel 2020-02-09
<The_LoudSpeaker> whats the name of the captive portal detection software in ubuntu? The one that pops up if I connect to a public wifi? and where do I get its source?
<joel2001k> hi all
<joel2001k> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<joel2001k> ^^ does it require any action?
<cjwatson> vorlon: ^- how do you normally deal with the sort of thing in joel2001k's case above?  The root problem is "missing build on i386: libinstpatch-doc (from 1.0.0-7)" which is an arch-all package that isn't in the i386 allowlist
<cjwatson> I could remove it from the release pocket just on i386, which would probably deal with it; but not sure what your usual practice is
